ArduPilot waypoint navigation with Inspire OSD waypoint display

Hi everybody. As said elsewhere, I'm new to DIYdrones and I hope I type my inputs at right places.
I'm currently in final stages of building my personal FPV/UAV platform (2m trainer Kadet Senior, outrunner driven).
If I am quite convinced by adding ArduPilot + FMA coPilot + 5Hz GPS for navigation, I still wonder what OSD would be most useful for my budget. When a looked at specs of the Inspire OSD, two questions came to my mind:
1) is there a way for both boards to share a single 5Hz GPS chip or is the ArduPilot able to communicate its position to the OSD (latter would be my preferred solution)
2) since the Inspire OSD is able to exploit waypoint routing from a Garmin Geko handheld GPS, would there be a chance for this OSD to read and display the current waypoint target from ArduPilot during navigation.
If anybody has experience with one or both boards, I would be glad to know. Thanks.

Views: 688

Reply to This

Replies to This Discussion

There's one significant problem with forwarding GPS data back to serial out. And this is speed.

I profiled the GPS parser code (measured time spent in the function), and it is very fast: 2-3 milliseconds when actual NMEA sentence is parsed, and 0 when no data are available. This is thanks to Serial IN being processed by interrupt and buffered. However, this is not the case when sending to Serial OUT, CPU stalls while data are being sent. Since Serial port works on 4800 baud speed (default speed of GPS device?), CPU can send ~480 bytes/second. Forwarding GPS data takes about 240ms each second (assuming 1Hz GPS device, expect CPU overkill for 5Hz GPS). Quite enough time consumption which should be used for actual flight code.
So regarding GPS data used by 2 devices, some other way should be chosen.

@Chris: seeing the nice speed of NMEA parser, I think there's no need for GPS binary mode parser, what do you think?
Thanks for those profile tests, Michael B.
I see there's a problem with CPU sending speed to serial OUT. Since the goal is to just to feed NMEA sentences to the OSD so the pilot remains at least approximately informed about current GPS route, wouldn't it be a solution to decrease the parsing frequency of ArduPilot, let's say to 0.5 Hz or any minimal frequency? Diluting the parsing over time would probably leave enough com out capacity to the CPU to execute its flight code safely.
I am currently listing what NMEA sequences and information from the LS20031 GPS chip are necessary to build up the Garmin Geko emulator sequences to feed the OSD serial IN.
I hope there is some way to get that parsing done from the ArduPilot serial OUT.
Here's a short paper about a state machine NMEA parser. It's probably not of interest for many of you, but maybe for other newbies like me:
NMEA Parser Design, by Monte Variakojis, 2002
There're more possibilities:
1) Increase serial port baud speed (but I don't know if we can configure EM406 device).
2) Send out just some NMEA sentences, and not very often (e.g. one update every 4 seconds).
3) Redesign Serial Out to be buffered and sent asynchronously (I trust is could be possible). Then sending would not halt CPU. Code would output NMEA sentence when previous one was fully sent, or when there's enough space in out buffer.
The LS20031 GPS chip I intend to implement is configured for sending 9600 bps by default.
Your other options are ways to investigate, but I feel 1 update every 4 seconds is in the lowest range of what I'd expected. A solution mixing your points 1) and 3) is most appealing to my mind.
@Michal: (RE: choosing not to use the binary mode) Yes, that was our thinking. The binary mode parser only works with specific GPS modules, which makes the code non-portable. It's only other advantage is slightly smaller code size, which wasn't important enough for us to keep it. We like our NMEA parser ;-)
Hi Michal. You said one possibility would be to increase baud speed. The LS20031 GPS chip (which arrived today, by the way, actually replacing my GPS emulator) tranfers at 57600 baud. Would this help solve the problem together with a buffered output to the OSD board? Another question is: do you know at which rate ArduPilot is reading the NMEA sentences?
Hi Redo,
actually reading NMEA sentences doesn't have "rate", it reads everything that is available at serial port. It's called in main loop, and when there're new data on serial, it consumes them.

I also posted this tutorial how to configure EM406 for higher baudrate.
I have a question concerning the serial OUT of ArduPilot. Is it a "real" serial level or a TTL signal.
I ask because to feed the Inspire OSD serial in I need RS-232 level. So if ArduPilot serial OUT is TTL, I need to convert signal level (DIY converter with MAX232 IC from Maxim and 4 x 100nF (0.1uF) capacitors as described here.
I noticed this when I tried to connect RS-232 serial of Inspire OSD to my FTDI TTL breakout... (FTDI survived).
If anybody has any information about ArduPilot serial OUT levels, I'll be glad to get them. Thanks.
A week ago or so, I inquired if serial Out of ArduPilot is at TTL level (or regular RS-232 level).
Since nobody answered, I suspect it is a too basic question to ask and I suspect the answer is TTL.
Unfortunately, I cannot check it out on the board itself, since it is still traveling! But in the meantime, I could prepare eventual RS232-TTL conversion if needed (though I hope not).
Thanks if someone could confirm what I suspect.
It's TTL level
Thanks for this Chris. That makes it easier then.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service