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.

Integration of Flight Illusion simgauges

Postby sgofferj » Mon Apr 07, 2014 12:42 pm

Hi,

About half a year ago, I have started working on a bridge to control Flight Illusion simgauges via MAVLink, for integration in UAV Ground Control Stations. I was a bit busy in the meanwhile but I just got the Attitude Indicator ready and will start working on the Altimeter soon. The controller is Arduino-based. I tried to keep the MAVLink brigde and the gauge control separated from the beginning, so the gauge control is available as separate library under the LGPLv2.
I thought, that might be of interest for FG cockpit-builders. Also, the FI protocol is fairly straightforward (but has some quirks) and it's serial, so it might also be pretty simple to integrate it into FG directly, although maybe not just with a protocol definition file.

Here's a short video of an Ardupilot MEGA 2.5 controlling the AI via MAVLink



Here's my project page with more infos and the devel blog. I'm still fairly booked out and might not read here regularly. If there's anything urgent, please PM me.
Please note that the main project goal is focused on UAV Ground Control Stations, so I might not integrate all FI gauges and/or integrate those which are not excessively useful for UAVs later. But chances are, I will integrate all with time.

-Stefan
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: 789
Joined: Mon Dec 05, 2011 5:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Hooray » Mon Apr 07, 2014 12:54 pm

Hi, welcome back !

I'd suggest to add this to the upcoming newsletter (see my signature), or maybe even add a dedicated article to the wiki
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Mon Apr 07, 2014 12:56 pm

Well, I'm not "back" in this sense. I really just thought, people here might be interested or find the project usable.
I just got the first gauge working - with MAVLink - so it might be a bit premature to write about it in the FG newletter or FG Wiki :).
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: 789
Joined: Mon Dec 05, 2011 5:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Hooray » Mon Apr 07, 2014 1:02 pm

We have similar projects that started out just as basic, e.g. see: http://wiki.flightgear.org/FlightGear_TQPanel

So, I'd not feel shy about adding more related projects to the wiki.
And it would give your project's website "high authority" backlinks, too ...
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Mon Apr 07, 2014 1:17 pm

Uuh, high authority backlinks = lots of traffic = lots of questions :D.
Let me get a bit further with the development and - especially - let it be integrated in Flight Gear (what I am NOT working on at the moment), then we can talk about newsletter and Wiki :).

Regarding FG, I see 2 possible ways of integration:
1.) MAVLink - that would work with my bridge but it would probably lack interactivity (I'm probably not going to integrate switches and stuff).
2.) Native integration. As I wrote, the gauges basically speak TTL serial and FI's native interface is mainly an FTDI with a power and bus distribution circuit. I'm not sure if it's possible to easily integrate the protocol via an XML file because there is some weird bitshifting and -banging going on. But because it's serial, it should be easy to integrate it natively cross-platform. For that, there's again 2 options:
a) Some developer looks at my library and transfers the sendCommand() function into something FG-native and then piece by piece also takes over the gauge integration or
b) People wait until I get to do this - which will take a while.

The library is LGPLv2. If this would be a problem, I can double-license the code for FG.
In case of a) I'd - of course - help as far as I can.

That's the sendCommand() function:
Code: Select all
void FIGaugeSet::sendCommand(char id, char cmd, long value) {
  char buffer[]={0x00,0x00,0x00,0x00,0x00,0x00};
  char bytethree, int2, cnt;
  long long1;
  buffer[1]=id;      // Gauge ID
  buffer[5]=0xff;    // Terminator
 
  long1 = abs(value);
  int2 = long1 >> 8;
 
  buffer[3]=(long1 & 0xff) | 0x01;
  buffer[4]=(int2 & 0xff) | 0x02;

  bytethree = cmd << 4;
  bytethree |= (long1 & 0x01);
  bytethree |= (int2 & 0x02);
  if (value < 0) bytethree |= 0x0C;
  else bytethree |= 0x08;

  buffer[2]=bytethree & 0xff;
 
  for (cnt=0;cnt<=5;cnt++) {
    Serial.write(buffer[cnt]);
  }
}
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: 789
Joined: Mon Dec 05, 2011 5:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Philosopher » Tue Apr 08, 2014 2:44 pm

Hi Stefan, nice to see that you're still hacking ;).

I know very little about the generic protocol, but I was wondering if Nasal could drive the output? It can read the relevant properties and do bit-bashing (even two ways - one using strings of bits, the other using doubles as 32-bit bitmask integers), so I think it might be possible to have the generic protocol read properties emitted by the Nasal, say in /sim/flight-illusion/output/char[0..n], or as a simple string (don't know if null-termination would be compatible though, it looks like 255 terminates in your sample, and I assume generic protocol would use null-termination, so strings wouldn't work...).

Anyhow, just throwing out that you shouldn't need to resort to C++.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Integration of Flight Illusion simgauges

Postby Hooray » Tue Apr 08, 2014 2:59 pm

He should be familiar with your idea, he started a thread a while back that ended up being turned into a "proof-of-concept" tutorial: http://wiki.flightgear.org/Howto:Port_I/O_from_Nasal
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Wed Apr 09, 2014 11:34 am

Right... THAT was SOME time ago.

Ok, if I find the time, I'll try to get back into Nasal at least as much to be able to write a bridge, but I definitely will need some help with that, especially, how to actually get this into Flight Gear itself. I haven't looked at Nasal or FG internals in ages.
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: 789
Joined: Mon Dec 05, 2011 5:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Philosopher » Wed Apr 09, 2014 1:26 pm

That's fine, I can help with both of those. I'd be fine with developing the library some more to make those C++ operations into Nasal double operations, v.g. by extending bits.nas with bitshift and masking, so then we could send chars out the generic protocol. At least it's fixed length, right? :)
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Wed Apr 09, 2014 4:20 pm

Jeps, for the moment, it's fixed length - 6 bytes.
Just to be sure - I can access the system's serial ports from Nasal on all platforms, Win, MAC and Linux, right?
I have asked FI to send me their standard USB2Gauge interface with the next gauges. According to the specs, that's mainly a USB2Serial chip plus a port multiplexer and power regulator/distributor. It should work out of the box without drivers and to FG it should appear as a serial port.
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: 789
Joined: Mon Dec 05, 2011 5:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Hooray » Fri Apr 11, 2014 10:09 pm

sgofferj wrote in Wed Apr 09, 2014 4:20 pm:Just to be sure - I can access the system's serial ports from Nasal on all platforms, Win, MAC and Linux, right?

Everything we told you 2+ years ago, still applies: there's no direct port I/O possible from Nasal. Instead, you'll have to go through the property tree and use one of the I/O options that supports the property tree, such as for example the generic protocol.

A summary of everything that you were told back then is provided at: http://wiki.flightgear.org/Howto:Port_I/O_from_Nasal
http://wiki.flightgear.org/Generic_protocol

It would be possible to map the I/O system directly into the property tree, so that protocols can be dynamically instantiated by setting properties - we talked about that idea when we were discussing USB/HID support (or even by using cppbind - which makes it straightforward to expose existing C++ code to Nasal)- otherwise, your setup will need to consist of at least two separate files: 1) the protocol file, 2) the Nasal file handling conversion/parsing - so deployment is admittedly not as straightforward/simple as it could be, but still simple enough for starters.

For example, both, MP/FGCOM have meanwhile become runtime-configurable features - the same thing could be done for the I/O system if necessary, and it would not even be very different, and even be overlapping with ongoing efforts like reset/re-init
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Sat Apr 12, 2014 9:14 am

And it's still more than hard for me to wrap my head around this... Ok, I get it, properties are kinda like sockets or fifos in this case, but how do I get this to the serial port. Yes, I know, generic protocol... That doesn't help me a bit because I understand that Wiki page partially at best and what I understand doesn't help me figuring out, how to get EXACTLY my bytes out of the serial port.
It's simply to much information, and too much information which I don't have any concept or reference to. You have no idea HOW frustrating that is!
Sometimes I really felt (and still feel) that Flight Gear is doing just about everything different than everybody else ever did and it feels like to understand one thing I have to read 10 other things and for that I have neither the patience nor the time.
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: 789
Joined: Mon Dec 05, 2011 5:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Hooray » Sat Apr 12, 2014 1:26 pm

  • actually, properties are more like a "file system" with folders, where variables are stored: http://wiki.flightgear.org/Property_Tree
  • network/serial I/O is handled through an XML configurable subsystem that allows these properties (=variables) to be accessed/modified/converted and sent
The property tree docs are actually really accessible - and we've seen newcomers use those without having a coding/hardware background.
Maybe the real problem is indeed you patience, i.e. not having fully worked through those 2-3 articles ??

You'll find that even just adapting a single example/protocol is going to be more helpful than reading dozens of docs.
In fact, most of us only understand how this stuff works because we've done it, not because we've read all those docs - indeed, most docs weren't around a few years ago.

FlightGear's isn't even particularly inconsistent here - one subsystem handles port I/O, results are written to the property tree, another subsystem (Nasal scripting) takes those results and processes them, writes them back to the property tree, where the generic protocol picks up the stuff and sends it to your hardware.

If reading is not your thing, open a few protocols and play with those, first by using hard-coded values - then use properties, then use Nasal to modify those properties.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Sat Apr 12, 2014 4:02 pm

Actually, the properties are the smaller problem for me. I have used them a lot, even with small Nasal scripts, e.g. in my joystick definition, my Helicopter-HUD or the GUI that I made for the Osprey, years ago.
What I totally don't see is how to get a generic protocol to do what I want. As far as I understand the generic protocol, it actually defines the protocol (=communications protocol), so it takes data from different properties and outputs them in a specific format, like ads commas or newlines, etc.
But that's exactly what I cannot use. What I need is "direct" (i.e. nobody messes with the data - not direct HW) access to the serial port.
Maybe I just don't see the forest behind all those trees but especially the Wiki doc on the generic protocol makes my head explode.
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: 789
Joined: Mon Dec 05, 2011 5:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Integration of Flight Illusion simgauges

Postby Hooray » Sat Apr 12, 2014 4:40 pm

I need to check the docs/code to see if there's any mandatory formatting/marshalling involved or if you have full control by just setting a property string with bytes/words or bits.
I don't have any hardware to test this, and I would need to set up a RS232 simulator of some form, or maybe send stuff back to FG via some kind of loopback setup, so you are probably in a better position to actually test this.

the generic protocol docs are actually fairly simple - you can also check $FG_ROOT/Docs for more compact examples.

The sprintf-style formatting stuff isn't required, and I don't think that those line/field (chunk) separators are required. So most things should be optional.

Once you omit stuff, you should just see the plain value (even if you're not using properties/Nasal)
To send a hex value from a property, you would just use setprop(property, 0xFF) and then reference the property in your XML file

I don't know if you have 100% flexibility for each message/byte here, but it is possible that there's some implied restriction here due to the way the generic protocol internally works.

But even if that should be the case, that should require fairly minor changes to the code.

And first of all, I would try to send some simple messages and analyse those according to the wiki article, to see if the format makes sense or if there's any "padding" or other stuff added that breaks the whole thing for you. Forget about properties and Nasal for now - just come up with a static protocol that keeps sending the same 6-byte message and see what it looks like.

For starters, you could post some simple examples - i.e. messages that you'd like to send, and how they're supposed to look (formatting-wise).
We can then check if it's possible to express those with existing generic protocol means, maybe in combination with Nasal.

EDIT: It is true that there's various comments saying that binary mode would not be supported for serial I/O, and that strings would not be supported - I have no way to test this, except for looking at the code.

But as previously mentioned, for fixed-size I/O, you would then simply set up 5-6 "fields" (chunks) each being a single byte/word (depending on your requirements) and then access each part separately by setting its property. Maybe I am missing something here, but that's how I would try to approach this for starters. And then dump the output to some file to see if it makes sense or looks corrupted.

messages with a fixed size of 6 bytes would then be expressed as having 6 chunks (bytes/char, or the equivalent size of ints ), or simply 6x8 boolean properties that you can control (set/clear) individually.

you could probably also use printf-style format strings to extract certain bits/bytes: https://en.wikipedia.org/wiki/Printf_format_string
So unless the generic I/O system will internally touch each message and break it for you, most required things should be there AFAIU
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to Development

Who is online

Users browsing this forum: No registered users and 6 guests