Board index FlightGear Development

Integration of Flight Illusion simgauges

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Tue Apr 15, 2014 4:48 pm

Hooray wrote in Sun Apr 13, 2014 12:50 pm:EDIT: Referring to those feature requests you filed: Good thinking, but also a bit short-sighted: Asking explicitly for Nasal-level access to do serial I/O is kinda limited, and even if we were to implement that within the 3.2 time frame, someone (probably very much like you) would all of a sudden show up and (rightly) say "this is very inconsistent... why can't I do sockets/fifos that way??". So technically, it would be much better to either expose the FGProtocol stuff, or extend the generic protocol such that it supports what's needed, without being specific to Nasal, and without being specific to serial I/O. Even a pub/sub mechanism would not be very difficult: https://en.wikipedia.org/wiki/Publish%E ... be_pattern

I thought, Nasal does have file I/O? Anyways, I'm a pragmatist and I don't give a **** about consistency if consistency means, stuff is 5+ times more complicated than it needs to be :). And, let's face it - the "classic" serial-I/O is MUCH easier for people who aren't involved in FG coding and the respective philosophy for years already :). So, it would not only be easier for me - all the Arduino-tinkerers out there would probably love it too because they could easily have FG talking to their projects without having to blow up their brains at least 5 or 6 times to figure out how to implement an - otherwise simple to write with 2 or 3 lines of code - stream communication through the GP.

Different topic... I think, I'm getting somewhere here. I'm just looking at atc-chatter/atc-chatter.nas and I actually can make some sense of it.
Now about the properties...
  1. Is there some kind of policy where in the tree those kind of properties should be hooked?
  2. Do I have to predefine the properties or can I just start using them and they appear, like setprop() in the init function of my script?
  3. If I can just start using them... Do I need to make somehow sure that they get initialized before GP tries to read them?
  4. How does GP react if properties are not (yet) there?

I'm already thinking ahead on how to make "installing" the stuff as simple as possible for the user - ideal would be just copy the .nas and the protocol file to the respective folders and not additionally have to edit some XML files.
FG 3.1 GIT / Opensuse 12.3 / Phenom II X4 / GForce GTX560
Stefan's little Flightgear corner | The Finnish Weather Center | Wolves in Finland

Working on: EFTP
COM: IAX2:home.gofferje.net/stefan (MO-FR 0700-2000 UTC, SA+SU 0900-2000 UTC)
sgofferj
 
Posts: 790
Joined: Mon Dec 05, 2011 4:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Hooray » Tue Apr 15, 2014 5:06 pm

you are asking lots of questions that are covered on the wiki, anyway:

#1: you can make up your own place, e.g. /simgauges
#2: you can start using them right away, but if they're supposed to send data, they obviously need to have some value/type, or the data may be "nil"/NaN, so I'd pre-define them via preferences.xml or by setting them up via setprop() first
#3: as I said, it would make sense to initialize those properties, if you don't want garbled data to be sent
#4: try it :D
#5: the Nasal file can contain initialization stuff, so no need to edit other XML files
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11925
Joined: Tue Mar 25, 2008 8:40 am

Re: Integration of Flight Illusion simgauges

Postby Philosopher » Wed Apr 16, 2014 10:48 pm

Hi, here's an initial sketch of a Nasal script for sendCommand. Actually sending data will require a little more work, and a loop/timer. I need to research a few more things, but the GP XML file should be nearly trivial, and I think the terminator could be directly encoded there. Running at frame rate will be fine, right?

Code: Select all
var __int = func(name, len=-1) {
    if (len == -1) len = size(bits.bit);
    var val = int(caller()[0][name]);
    caller()[0][name] = bits.trunc(val, len);
}

bits.shiftleft  = func(a,b) bits.clear(a,-1)*math.pow(2,b);
bits.shiftright = func(a,b) bits.clear(a, 0)/math.pow(2,b);
bits.bitand = func(a,b) {
    forindex (var i; bits.bit)
        if (!bits.test(b,i))
            a = bits.clear(a,i);
    return a;
}
bits.bitor = func(a,b) {
    forindex (var i; bits.bit)
        if (bits.test(b,i))
            a = bits.set(a,i);
    return a;
}
bits.trunc = func(a,len) {
    for (var i=len; i<size(bits.bit); i+=1)
        a = bits.clear(a,i);
    return a;
}
bits.idx = func(b) {
    forindex (var i; bits.bit)
        if (bits.bit[i] == b) return i;
    die("bit index for "~b~" not found");
}

var rootN = props.globals.getNode("sim/flight-illusion/protocol");
var bitsN = rootN.addChildren("byte", 6, 0, 0);
bitsN[0].setValue(0); # Message start
bitsN[-1].setValue(0xFF); # Terminator

# What was the intended size here (bytes)?
var sizeof_long = 2;
var sizeof_char = 1;
var sendCommand = func(device_id, cmd, value) {
  __int("device_id", sizeof_char*8);
  __int("cmd", sizeof_char*8);
  __int("value", sizeof_long*8);
  bitsN[0].setValue(device_id); # Gauge ID
 
  var a = abs(value);
  var b = bits.shiftright(a, 8);
  bitsN[3].setValue(bits.bitor(bits.trunc(a,8), 0x01));
  bitsN[4].setValue(bits.bitor(bits.trunc(b,8), 0x02));
 
  var c = bits.shiftleft(cmd, 4);
  if (bits.test(a,0)) c = bits.set(c,0);
  if (bits.test(b,1)) c = bits.set(c,1);
  if (value < 0) c = bits.bitor(c,0x0C);
  else c = bits.bitor(c,0x08);
 
  bitsN[2].setValue(bits.trunc(c,8));
}


EDIT: the code will create the necessary property nodes, essentially giving them a default value of 0. Adding a flag to determine when to run would be trivial, as I don't quite know if Nasal timers will run before GP starts initially.. though I suspect they will.
Last edited by Philosopher on Fri Apr 18, 2014 7:53 pm, edited 2 times in total.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Integration of Flight Illusion simgauges

Postby Hooray » Thu Apr 17, 2014 12:05 am

I don't quite know if Nasal timers will run before GP starts initially

I /think/ that GP initialization still happens directly when options are parsed/processed, i.e. there's some form of I/O channel setup going on inside options.cxx which ultimately uses something along the lines of add_channel() to set up channels that are stored in globals.?xx, including the generic protocol stuff. Ultimately, each IO channel is managed via FGIO which is added in fg_init.cxx, see $FG_SRC/Main/fg_io.?xx: https://gitorious.org/fg/flightgear/sou ... t.cxx#L695

Nasal/events (timers) are initialized 100-200 lines later.

And it actually makes sense, the whole I/O stuff shebang predates Nasal - and we're still not quite there yet when it comes to initializing Nasal much earlier, due to all those runtime dependencies.

PS: I have no way to test this currently, but I do remember that things like telnet/httpd used to be available BEFORE Nasal was available :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11925
Joined: Tue Mar 25, 2008 8:40 am

Re: Integration of Flight Illusion simgauges

Postby Philosopher » Thu Apr 17, 2014 12:39 am

Yeah, it looks like Nasal (SGSubsystemMgr::DISPLAY) runs after GP (SGSubsystemMgr::GENERAL), but I guess it doesn't matter because Nasal can do init in the script...

Stefan, is there any sort of NULL command you could send? Otherwise, integrating SGConditions would be literally 3-4 lines of code, or just a simple on/off flag.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Integration of Flight Illusion simgauges

Postby Hooray » Thu Apr 17, 2014 12:59 am

right, it would be kinda straightforward to make things conditional, either through scripting bindings or through SGCondition - but once we do that, we really need to add some identifiers or do escaping in some form, because messages would no longer be sent at fixed rates, and would not even be fixed length anymore - fact, even the format would then be fully dynamic. While that brings a lot of flexibility, it also causes new challenges.
And I don't know if he even builds from source or not, providing a simple patch would be straightforward to make things (chunks) optional, but otherwise everything would need to be done without touching the C++ code
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11925
Joined: Tue Mar 25, 2008 8:40 am

Re: Integration of Flight Illusion simgauges

Postby Philosopher » Thu Apr 17, 2014 2:40 am

I was thinking about just choosing whether or not to generate and send the message, not toggling individual chunks, which would obviously be more work, especially with length. (I do know what strings are sent with a four-byte length marker in front, and so there obviously are ideas to handle variable lengths.) There is something about a "footer" that indicates length sometimes... but I didn't read into that.

P.S. He posted in the compiling forum a few days ago, aka - he builds from source ;). I don't think it would be possible to do it without C++ changes, other than if there's some command the devices would ignore (NULL command), because nothing's conditional right now.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Thu Apr 17, 2014 7:34 pm

Well, there is a NOOP command but also that needs to be properly encoded in the protocol...
Running at frame rate should be more than enough. The gauges speak 38k4 and they don't have the fastest CPU, so I actually wouldn't update them more often than 3 or 4 times per sec. They also seem to dislike if certain commands come to fast...
I just finished the functions and testing for the digital altimeter and pushed everything to git. Talking about this, I do see another problem - before we get too deep into Nasal and GP... We do need 2 way communication! Few examples:
  • Altimeters have baro knobs which can be read (actually, the gauge returns the set pressure value!)
  • A couple of NAV gauges have knobs for bugs, pointers, etc. which can be read
  • ...
What I figured out today was that this is not exactly easy. Those things tend to be picky... You have to send the query command, and then start listening for a reply but the query command can't come too fast behind another command, etc.

Another thing that should be done is identifying all connected gauges at startup. In essence, one would send 255 query commands and wait for the reply (which includes the gauge type, etc.) and then build some kind of array, so we know, where to send which command. The reason is that "special" gauges, such as attitude indicators have their unique ID but all plain single-needle gauges come from the factory with the ID 255 and the user need to choose and set an ID before it can be used. Of course, we still need to know what kind of gauge it is, so we know, e.g. to which step to set the needle for e.g. 50kts on an IASI.

So, I'm wondering if Nasal is the way to go here.

Besides - @Philosopher:
I can't make any sense of your sendCommand function... And you're right - Int should be enough for most of the vars - I have to look into that again.
FG 3.1 GIT / Opensuse 12.3 / Phenom II X4 / GForce GTX560
Stefan's little Flightgear corner | The Finnish Weather Center | Wolves in Finland

Working on: EFTP
COM: IAX2:home.gofferje.net/stefan (MO-FR 0700-2000 UTC, SA+SU 0900-2000 UTC)
sgofferj
 
Posts: 790
Joined: Mon Dec 05, 2011 4:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Hooray » Thu Apr 17, 2014 8:29 pm

just provide a few working GP examples so that we can take a look and provide the Nasal bits required to explore this further. The Nasal stuff is a bit sophisticated because it involves things that you are unlikely to be familiar with, such as the bits.nas module and quite a few helper functions. Normally, you should not need to understand anything beyond using sendCommand(), so I wouldn't worry too much if you can provide a few examples on working GP configurations and valid commands.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11925
Joined: Tue Mar 25, 2008 8:40 am

Re: Integration of Flight Illusion simgauges

Postby Philosopher » Fri Apr 18, 2014 1:32 pm

Here's his GitHub repo: https://github.com/sgofferj/ArduIllusio ... lusion.cpp

It doesn't look like he has uploaded any reading-back-in code yet. But otherwise it's fairly straight-forward, doable with GP so far.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Sat Apr 19, 2014 8:52 am

Jeps, I only implemented the send query command yet. Working on a way to to handle the reading...

Remember what I wrote about detection and initialization. Also performance-wise it might be a good idea to only send data to gauges which actually exist :).
FG 3.1 GIT / Opensuse 12.3 / Phenom II X4 / GForce GTX560
Stefan's little Flightgear corner | The Finnish Weather Center | Wolves in Finland

Working on: EFTP
COM: IAX2:home.gofferje.net/stefan (MO-FR 0700-2000 UTC, SA+SU 0900-2000 UTC)
sgofferj
 
Posts: 790
Joined: Mon Dec 05, 2011 4:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Hooray » Sat Apr 19, 2014 9:54 am

Remember what I wrote about detection and initialization. Also performance-wise it might be a good idea to only send data to gauges which actually exist

I think as long as the GP part really only deals with messages on the byte/bit-level and all logic is handled by Nasal even that should still be possible.

We could then use a timer to update things using settimer/maketimer and send a NULL/NOP command otherwise (i.e. each frame)

I can't make any sense of your sendCommand function... And you're right - Int should be enough for most of the vars - I have to look into that again.

looking at your own code, he's really just using a few custom helper functions and library functions for doing bit manipulation, which is not supported by Nasal through syntax, i.e. needs to be done via library functions - which is why the sendCommand() stuff in Nasal looks more verbose, but it's also more explicit and self-explanatory, and should feel more natural to most people who are not familiar with low-level C programming.

For the sake of simplicity it would be good to have a set of working GP & Nasal files. For instance, we may even be able to use another GP file to simulate the device for testing purposes, so that Philosopher's code can be tested without requiring actual access to the hardware.

Adapting sendCommand() to become getCommand() should be fairly straightforward (using the same helpers), and would allow us to test things even without the hardware, by passing data through sendCommand() to getCommand() and either parsing/processing it, or maybe even visualizing some of it.

In fact, FG already has all the instruments that we could animate for testing purposes, as I demonstrated a while ago:

Image
http://wiki.flightgear.org/Howto:Parsin ... the_Canvas
http://wiki.flightgear.org/FlightGear_N ... ears_later

Adding a text area to show a log of all received messages per instruments would just require 10 lines of code.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11925
Joined: Tue Mar 25, 2008 8:40 am

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Sat May 10, 2014 7:38 pm

Sorry for the slow progress. I'm incredibly busy with other stuff and haven't got to making a Nasal script actually run. Nasal is a bit too different from what I'm used to and most of the lessons from Hooray I already forgot and had to read up on. On the bright side, I got the altimeter finally running - there were some issues with the displays but I'm still waiting for some answers from the firmware developers. The altimeter gauge seems to be very particular about in which sequence certain commands are sent and about the timing... :/



FG 3.1 GIT / Opensuse 12.3 / Phenom II X4 / GForce GTX560
Stefan's little Flightgear corner | The Finnish Weather Center | Wolves in Finland

Working on: EFTP
COM: IAX2:home.gofferje.net/stefan (MO-FR 0700-2000 UTC, SA+SU 0900-2000 UTC)
sgofferj
 
Posts: 790
Joined: Mon Dec 05, 2011 4:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Previous

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest