1) The SVN seems out of date or unused. Is there a development branch we can sync with?
svn checkout http://ardupilot.googlecode.com/svn/trunk/ ardupilot-read-only

2) Whats the procedure for patches? Should they be emailed or posted? Diffs?

3) Serial ports on Arduino 0017 on Ubuntu Linux seem unstable, is the windows version stable?

4) I am working on building a hardware in the loop test system and have GPS data coming out of X-Plane. So, before I get myself any further into this can someone verify my understanding of the NEMA parser?
GPGGA Only position fix and altitude are used
GPRMC everything except utc, utc status and date are used
and GPS times out after 2 seconds
My understanding is that none of the other NEMA information is used.

I get the impression that long term you only want to support ublox binary protocol. Is part of that due to issues with reproducing bugs and troubleshooting?

I would like to see some sort of flight data recorder that can be plugged in to x-plane and the HITL test system to reproduce test cases.

5) My GPS emulator right now outputs the exact position (exact in x-plane), Should I even bother emulating error at this point? Is supporting binary GPS formats more important?

This looks like some good information on GPS error distribution http://users.erols.com/dlwilson/gpsacc.htm Apparently GPS error has a Rayleigh distribution.

Views: 141

Reply to This

Replies to This Discussion

1, 2) Yes, we're noobs with SVN and never got it working correctly. And Jordi doesn't like the whole checkin/checkout process ;-) For now, let's just email patches or post them to the ArduPilot thread. If there are a lot, we'll get SVN working.

3) Yes, the Windows version of 17 is stable. If you're using Linux and having trouble, stick with 16. ArduPilot works fine with either.

4) That sounds right. It's been a while since I looked at the NMEA parser (we don't use it anymore), but that's my recollection

5) Long term, we want one code base and one hardware configuration. Given how many people have the EM406, we'll continue to support that but as soon as we release the uBlox5 combo, we'll make that the recommended GPS. It's too hard to support random combinations of hardware, which spiral into an unlimited number of one-off configuration problems. If people want support, they'll have to use the recommended configurations. (Of course, they're free to use other hardware and software just as long as they don't expect us to debug their setups).

6) GPS error (other than heading) is not a big problem with uBlox 5
Ok today I am looking at the servo PWM subsystem...
This afternoon I got the connectors soldered to the ArduPilot and hooked up a scope and it looks like the way the PWM signals are generated is interesting. I went through the source and it looks like...

Channel 1 and Channel 2 are generated by a hardware PWM generator that gives approximately an effective 9 bit resolution due to the 2us resolution. This uses roughly 0 cpu since everything is in hardware.

Channel 3 (the throttle) is generated by hitting an interrupt every 8us and running a counter to the right time to flip the i/o line. This give us a 7 bit resolution on the throttle and is drive by an interrupt.

On the scope it looked like channel 1 and 2 turn on at the same time and from the code it looks like the period for channel 3 is probably different than the period for 1&2.
It also looks like the capture for flyby wire is driven by the hardware interrupt pins.
So the ArduPilot does not output PPM compatible PWM signals.

Does this sound correct?

If you have the software internals documented somewhere let me know and I can read that instead of asking all these questions.
That sounds correct, but it's a bit over my head. PM Jordi, who actually knows this stuff, if you want confirmation.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service