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 » Sat Apr 12, 2014 6:40 pm

Testing... (just mentioning because now there's potentially a while no answer from me)
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 sgofferj » Sat Apr 12, 2014 7:34 pm

Maybe not that long...
So, I got a simple test running which outputs /sim/messages/mp-plane to a serial display. I have a little issue though - it repeats the last value over and over again. Is there any way to tell the generic protocol to only send something if there actually was written something to the property and not repeat the same stuff? Otherwise, I don't see how I could implement the command output for the gauges because I would likely run in to serious timing/sync issues, when the sending of a new byte comes "too late" and simply the last byte is repeated.
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 7:39 pm

sgofferj wrote in Sat Apr 12, 2014 7:34 pm:Maybe not that long...
So, I got a simple test running which outputs /sim/messages/mp-plane to a serial display. I have a little issue though - it repeats the last value over and over again. Is there any way to tell the generic protocol to only send something if there actually was written something to the property and not repeat the same stuff? Otherwise, I don't see how I could implement the command output for the gauges because I would likely run in to serious timing/sync issues, when the sending of a new byte comes "too late" and simply the last byte is repeated.


that's funny - 2+ years of asking questions related to serial I/O (and being responded to here!) and it's only now that you are figuring out that this is how the generic protocol system works :D
I guess that proves my point that experimenting beats asking questions, and even, reading docs? :lol:

And yes, those previous answers should contain the solution for this one as well: while the loop will keep on sending the property, you can use Nasal to affect the value of the property (e.g. blank/clear the property, or use a different message).

Otherwise, you would need to use some form of subscription-based pub/sub mechanism, which isn't currently supported by the generic protocol system.

You could emulate the whole thing by using several layers of indirection - the output property on the one hand, and a listener that determines if the output property needs to be updated - otherwise, it could default to some standard message that is ignored by your hardware, i.e. along the lines of "NOP"

I do agree that it would be a good idea to fix/extend the generic protocol system accordingly, so that such workarounds are not necessary - so feel free to add a feature request to the tracker, we have an increasing number of people doing embedded hardware stuff (UAVs, arduino, atmega etc)

A while ago I extended the telnet system to support "notifications" (on-demand sending of updated properties), that ended up being under 50 lines of code IIRC - the same mechanism could be used here: https://gitorious.org/fg/flightgear/sou ... c.cxx#L918
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 8:06 pm

Well, I haven't been constantly busy with that and 2 years ago, I IIRC didn't target serial comms but USB HID.

Anyways, the problem is not repeating a valid command, which would simply lead to more update request to the gauges. The problem is timing and sync.
Let's say, I let the generic protocol poll /myproperty/commandbyte 10 times per second, then I need to make sure that Nasal is updating the property not too fast and not too slow, otherwise, I'd send garbage, invalid commands or at worst, setup commands which could mess up the gauge.
Even if I use 6 properties, one for each byte, there is still the problem that changes in the property values could occur out of sync with the generic protocol poller, again leading to garbage output.

That becomes exceedingly and unnecessarily complicated. I absolutely can't understand why nobody ever thought that normal, oldfashioned fopen/fclose/etc. could be a useful thing for Nasal and implemented those...

Besides, I wonder that this repeating thing hasn't come up yet because in case of network-transmissions, that potentially creates a ton of unnecessary traffic.

At the moment, it looks more like there won't be a native integration. What I probably could do is write a bridge in C or Java which listens to FG native or some other protocol and translates this to the gauge commands. I have to think a bit about this, how to do this best.

Or maybe... Can a property value be an array of char - not a string with it's predetermined terminator and such - just an array of char?
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 8:19 pm

As I said, I don't necessarily disagree - so feel free to make a feature request. But the changes you are talking about would not even be very difficult. Once you start talking about C, C++ or Java, modifying/extending the existing code in FG is not all that difficult with some hand-holding from our side. In general, for people familiar with hardware projects and coding, the most difficult thing is setting up a working build environment - making tiny modifications and rebuilding FG isn't all that complicated afterwards. You don't even need to use git for that.

However, what you describe should still be possible - basically, you are looking for a way to ensure that the state is consistent, so that only atomic updates are made - that, again, could be managed by 5 lines of Nasal code. I don't say that this is necessarily the best/easiest option, but workarounds to accomplish this should be possible still.

Looking at generic.cxx, it would seem to require less than 30 lines of C++ code to modify it such that an optional "update-on-change" tag/attribute is supported and honored, so that non-modified properties are not updated/sent. Many ways to skin that cat...

sgofferj wrote in Sat Apr 12, 2014 8:06 pm:I absolutely can't understand why nobody ever thought that normal, oldfashioned fopen/fclose/etc. could be a useful thing for Nasal and implemented those...

Personally, I find that pretty low-level actually (even though flexible) - and FG does have an io module, and I think the Linux module on github should even support TTY-style I/O (not tested), and could probably be integrated/used in less than 15 minutes.
But I would be more in favor of exposing FGInput/FGProtocol to Nasal space eventually.

Besides, I wonder that this repeating thing hasn't come up yet because in case of network-transmissions, that potentially creates a ton of unnecessary traffic.

right, it does - and everybody knows about it - it's the way our MP protocol works, and it's the reason why we so called "generic properties", and why we've been discussing supporting PUB/SUB for over a decade, and why people are working on HLA.

At the moment, it looks more like there won't be a native integration. What I probably could do is write a bridge in C or Java which listens to FG native or some other protocol and translates this to the gauge commands. I have to think a bit about this, how to do this best.


If are able to build from source and are considering to build such a bridge app using C/Java, modifying FG's code should be less work probably.

Or maybe... Can a property value be an array of char - not a string with it's predetermined terminator and such - just an array of char?


what you are trying to do now ?
your thinking is confusing ...

PS: You can see how config parsing is done by checking https://gitorious.org/fg/flightgear/sou ... c.cxx#L805 - as you can probably tell, it's not necessarily very difficult or elegant code - the code was originally written pre-2000, so it's not difficult to extend, even without significant coding experience.
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 8:38 pm

Maybe for an experienced developer that would be easy but I am no such thing. To integrate the stuff into flightgear, i would have to read into the code, find the right place, etc. I would have to start dealing with makefiles, cmake, the whole toolchain. I never did anything with that beyond typing cmake or make as instructed in build instructions.
I have only done small pieces of stuff, and pretty much always only in IDEs (except some small PHP stuff) which keep the whole toolchain nice and far away from me. I don't even speak fluent C or C++ - IDEs have context-sensitive help :).

For me, firing up e.g. Netbeans, c&p my Arduino code into Netbeans and then making the changes to make it run would probably be much easier.

I was thinking as a last resort, to not use a single byte property like a fifo or 6 property bytes as 6 chunks, but use an array of char if that would be available as property. I probably can't use a string property because I suppose, the Nasal string handling automatically terminates the string with a terminator byte?
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 » Sun Apr 13, 2014 12:26 am

Okay, I'm about as uneducated as you, but making a few reasonable assumptions I would guess this:
  • Yes, sending arrays of chars is possible, through Nasal-writable props doing basically the same thing as you do in your sample.
  • Nasal wouldn't conflict with generic protocol at all, simply because they'll operate in the same thread (the property tree isn't threadsafe yet, so access will never be asynchronous).
  • Editing source is just that - unless you integrate a library (very unlikely) or add a file (unlikely, but simple to do), you won't need to touch CMake at all :). I know that for a fact - I only had to touch one once, and I've already done a few projects in C/C++.
  • We have enough people here to help you with C++ if you need it... but if sending char arrays with a 0xFF terminator is already doable, then you shouldn't need it. Researching isn't hard though, just needs some time and a non-iPodic device.

If need be, I could probably set up an Arduino to receive packets and see what comes out... but then I'd have to learn the whole process too ;).

P.S. Nasal definitely does have fopen/fseek/fclose/etc. for files... but doesn't it require Unix to turn those into actual serial streams? Anyways, it's just the io module.. but that would be even worse to use, IMHO.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Sun Apr 13, 2014 7:23 am

Ok, maybe I see this all wrong... Let me try to explain what I think might happen...

Option 1: I use one property and transmit the data sequentially.
Ideally, it would look like this:
Nasal writes a byte
GP pulls the byte
Nasal writes a byte
GP pulls the byte
Nasal writes a byte
GP pulls the byte
Nasal writes a byte
GP pulls the byte
Nasal writes a byte
GP pulls the byte
Nasal writes a byte
GP pulls the byte

However, as GP doesn't know when I wrote a new byte, this might happen:
Nasal writes a byte
GP pulls the byte
GP pulls the byte
Nasal writes a byte
GP pulls the byte
...
In which case garbage is sent to the gauges.

Option 2: I use 6 properties
Ideal:
Nasal writes byte 1
Nasal writes byte 2
Nasal writes byte 3
Nasal writes byte 4
Nasal writes byte 5
Nasal writes byte 6
GP pulls all 6 bytes

But, again, as GP doesn't know what Nasal is doing, this might happen:
Nasal writes byte 1
Nasal writes byte 2
Nasal writes byte 3
Nasal writes byte 4
GP pulls all 6 bytes
Nasal writes byte 5
Nasal writes byte 6
In which case the last 2 bytes would be from the old command = garbage again.

@Hooray:
If I understand you right, you suggest that I edit the code to implement the "pull only when there were changes" algo? I looked at the config parser and while I MIGHT be able to add this there, implementing this function would most certainly require also hacking the property tree core, the Nasal interpreter and potentially a ton of other things... THAT is way out of my league!
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 » Sun Apr 13, 2014 1:50 pm

If I understand you right, you suggest that I edit the code to implement the "pull only when there were changes" algo? I looked at the config parser and while I MIGHT be able to add this there, implementing this function would most certainly require also hacking the property tree core, the Nasal interpreter and potentially a ton of other things... THAT is way out of my league!

it doesn't require any of that - it just involved adding ~30 lines of code to generic.cxx - unless I am missing something it could even be less code probably.
This has nothing to do with the property tree or the Nasal engine - it just involves looking for a certain tag/attribute and once it's there, making sure that unchanged properties are not sent.
But like I said, there are many options here to accomplish this - this isn't necessarily the best idea, but it's pretty simple.

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
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 Philosopher » Sun Apr 13, 2014 5:57 pm

sgofferj wrote in Sun Apr 13, 2014 7:23 am:But, again, as GP doesn't know what Nasal is doing, this might happen:
Nasal writes byte 1
Nasal writes byte 2
Nasal writes byte 3
Nasal writes byte 4
GP pulls all 6 bytes
Nasal writes byte 5
Nasal writes byte 6
In which case the last 2 bytes would be from the old command = garbage again.

This will never ever ever happen - believe me, I just looked at the code, and there's no way it does it. Nasal runs at some point (atomically), GP runs at some time different (atomically as well).

Another simple extension would just be "run if X prop is true", so Nasal could manually tell GP when it needs to send stuff. Essentially you should be able to mimic a simple serial port using the GP setup with minimal hacking.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Integration of Flight Illusion simgauges

Postby Hooray » Sun Apr 13, 2014 6:10 pm

I think the misconception is that he thinks our main loop is multi-threaded, while it is indeed entirely sequential. Like Philosopher said, each subsystem in FlightGear gets called to run its update() method, including the FDM, autopilot, scenery, terrain, sound, scripting, I/O etc - there's a fixed pre-determined order. Each stage gets to see the state as it was left over from the previous stage. It would require a fair bit of sophistication and internals knowledge to mess this up (and I can only really come up with two methods, without going into specifics). And like Philosopher says, you can explicitly design for this by using a "signal" property that signals "completeness".

But overall, this is pointless unless you have some more specific examples that you'd like to try first, so that we can check if there are any real roadblocks ahead.

I'd suggest to post a handful of examples (messages) so that we can take a look
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 14, 2014 2:30 pm

Well I posted the sendCommand() function above.
Setting the horizon's bank angle would be e.g.
gaugeID=103
CMD_setroll=4
sendCommand(gaugeID,CMD_setroll,(360-(angle+180))*10.667)

The issue are a few "dangerous" commands, such as e.g. calibration. So, for starters, the thing I need is to get those 6 bytes out of the serial port without anything changing them. If it's 100% guaranteed that they are not changed, then it doesn't even matter if the same sequence is sent out again because that would just mean another position update for the gauge.
Later on, I might need also be able to read a reply, because some gauges can be queried, such as the altimeter, which returns the selected pressure if you ask it.

Just thinking - would it be a cool thing to be able to use nasal in the GP definitions - a bit like I can use Nasal in the Joystick definitions? That could make things even easier and even more flexible...
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 14, 2014 2:45 pm

take your existing GP config file, copy it to a new file and then extend it such that it uses multiple properties for each word/byte (or even bit) - that should be just copy&paste and changing some property indexes. Then open preferences.xml to pre-define those properties for testing purposes, i.e. add a valid 6-byte long message. See if it works.

Once it works, it's probably 30 lines of Nasal code to create a "sendCommand()" function that directly accesses those properties, we just need to know the message format, i.e. if each field is always two bytes ? If so, the bits.nas stuff could probably be used to set up everything inside sendCommand() - so that you only need to call the function. I am not even sure we really need C-style format strings, but the combination of 1) byte/bit-level property setting, 2) bits.nas and 3) C-style format strings should provide everything that's needed to come up with a simple wrapper for directly talking to your device.

Feel free to post your XML/Nasal code using a paste bin (or even just the wiki), so that others can easily help review/edit it.

PS: Supporting Nasal inside generic protocols isn't not such a bad idea, others have suggested it ~3-5 years ago, it could in fact be used to re-implement our MP protocol on top of the GP system or even implement a simple pub-sub mechanism - and we have lots of examples of supporting Nasal blocks in XML files, but currently nobody is really doing this kind of stuff, we're all hoping for HLA to eventually help get rid of our MP protocol :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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Integration of Flight Illusion simgauges

Postby sgofferj » Mon Apr 14, 2014 3:27 pm

No, the message format is the thing... Have a look at the sendCommand function. The only thing I can say for sure is that one message is always 6 bytes but there is so much bit-shifting and -banging going on with this depending on that and if this value is greater than x in another byte, this bit is set and so on...
I think, I'll hack a little test thing together in JAVA or so... Like a small sendCommand() wrapper.

Different question:
Where and how do I put a Nasal script so it gets executed in the main loop? Do I have to register it somewhere, put it to some config file?
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 14, 2014 3:50 pm

sgofferj wrote in Mon Apr 14, 2014 3:27 pm:Different question:
Where and how do I put a Nasal script so it gets executed in the main loop? Do I have to register it somewhere, put it to some config file?


Two straightforward options by adding your *.nas files to $FG_ROOT/Nasal (directly), or inside a subfolder under $FG_ROOT/Nasal (as a Nasal submodule, where all flies within the same folder will be loaded into the same namespace)

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

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 10 guests