GPS/Autopilot for ELEV-8V3

cberrya6e

This is intended primarily for Jason: is there any targeted date for the GPS integration to support autopilot functionality? I know you are probably assigned projects until the Rapture, but I was just curious because I was poking around GitHub and observed that you had started work on some of this awhile ago. Any info would be much appreciated - and please do not take this as criticism in the least. Thanks!

Regards,
Chuck

JasonDorie

Currently, no, there's no specific target date. I have added code to read the GPS and compute the current position, but it's a surprisingly difficult jump from there to actually navigating, with lots of new math, and I'm honestly not sure if there are enough resources left in the Prop to do it. There's a push for a number of additional safety features for the education / beginner market, and all of it is fighting for the remaining code & memory space. On top of that, I recently moved from a suburban area with a lot of open space to a dense urban area within 1.5 miles of a major airport, so it's much harder for me to do flight tests.

cberrya6e

Thanks for the response, Jason. I had imagined that the computing resources could become an issue. Is it the kind of thing where the GPS management could be farmed out to a Propeller Mini with outputs to the flight controller to drive nav responses? I am guessing not if there is a fusion of GPS with other onboard sensors as part of your algorithm.

JasonDorie

The 2nd CPU is the approach I've been pushing for. The Prop is great for doing lots of small things in parallel, but it's less great at long-loop code with heavy math and decision logic. Honestly it'd be totally fine if I had 128kb of ram and could just compile everything in LMM mode, but I can't. The math processing is currently done in a customized F32 unit that asynchronously runs a stream of commands, but it can't make logic decisions or do branches, and it ends up being really hard to code some things that way. I simply don't have space left in the FPU for the extra code to handle branching / logic.

If I were to do this on a second chip, I'd likely have the master Prop run the servos, sensors, R/C input, reading the GPS, and running the core IMU calcs. The second would take that data, do some additional vector math for the GPU, run the flight control logic, and pass motor control outputs back to the driver core. On top of this, I'd have the extra resources necessary to LOG everything so I could run simulations with full sensor readings stored to a card, which I simply can't do fast enough right now. An SD driver takes a cog on its own, and the code to feed it is another one. I only have two left, and that's before adding the GPS.

To get the GPS accurate enough you basically need to use the accelerometer vector rotated by the current orientation estimate to estimate your current direction / velocity, and use that to estimate a position. This is referred to as double integration, and it very quickly goes to hell if you don't have a way to rein it in, so the other part of it is that you use the GPS readings as an absolute reference and fuse that into the running accelerometer / velocity estimate in a complimentary filter. That way the accel-based estimate provides extra precision for the GPS, and the GPS readings prevent the inaccuracy of the accel-based readings from running away. In a traditional computing environment this is moderately complicated, but not too bad. On the prop it's additionally challenging, and it's non-trivial to test and debug this stuff.

Once you have those results, you need to compensate for the shrinkage of longitude values as you move away from the poles, handle the wrap-around at the date line, deal with numbers that are so large they want to overflow a lot, and do a few other things that are kind of ugly.

cberrya6e

Propeller 2....

JasonDorie

cberrya6e wrote: »

Propeller 2....

I'm not sure I have that kind of time. ;-)

cberrya6e

If you build it, they will come... ;-)

The_Master

I think Jason is talking about full sensor fusion and cberry is talking about just letting the thing bob about in it's current GPS position (stabilized with gyro, accel, compass, altimeter), the GPS providing only a crude navigation function.

JasonDorie

Unfortunately they're the same problem. Tracking *any* position, stationary or moving, requires almost exactly the same code.

The_Master

Let me rephrase:

I think Jason is talking about full sensor fusion and cberry is talking about just letting the thing bob about (attitude stabilized only-- with gyro, accel, compass, altimeter), the GPS providing only a crude navigation function.

If elev-8 is yaw stabilized with a compass, then the only firmware modification to elev-8 would be to accept desired roll and pitch input from a second micro.

macirish

Do you have to deal with coordinate, lat, long and great circle math? Can't the problem be solved with mapping the local region onto a local 2D grid?

In a square mile the curvature of the earth is negligible. A 6,000 x 6,000 grid seems adequate.

I'm probably being naive - but have to ask. Thanks.

JasonDorie

I don't really have to deal with curvature, no - I had planned to treat it as a grid, but the X-scale of the grid (longitude) varies as you move away from the equator. It's likely enough to compute that scale once on startup, but it has to be factored in. I had also planned to do as much work as possible in relative coordinates (relative to the takeoff point, for example) because then the scales become much more manageable, but you still have to convert to that relative coordinate and handle the flip as you go across the date line. Just in case anyone ever actually does.

cberrya6e

I did not suggest any limited solution as I am a tad too uneducated to do so - what Jason expressed was in line with my perceived functionality for GPS/autopiloting for this UAV. Sensor fusing makes sense to me based on Jason's decomposition of the problems associated with this requirement.

The_Master

Here is what you suggested:

cberrya6e wrote: »

Is it the kind of thing where the GPS management could be farmed out to a Propeller Mini with outputs to the flight controller to drive nav responses? I am guessing not if there is a fusion of GPS with other onboard sensors as part of your algorithm.

To respond to your question: there is NOT fusion with GPS. So therefore it CAN be farmed out. But a little bit of modification needs to be done to Elev-8 to accept the input from the "prop mini"

JasonDorie

It depends on where I do the math with the accelerometer. At present, it'd be simplest to do that as part of the IMU, and therefore it would need to be fused with GPS readings to prevent drift. I might have to farm that to the other chip though and just take the extra memory / speed hit for doing it in LMM mode because I may need to do logic while processing that stuff, which is hard to do in my current math stream code.

cberrya6e

Thanks, Jason. Your original explanation was quite elegant and made clear that data fusion was an element of your preferred approach. Based on my looks around the Pixhawk/Ardupilot community development efforts, it is amazing what you have accomplished on this platform on your own. The proverbial one-armed paper hanger...!! I will probably explore that arena for a flight controller to do this integrated GPS stuff, if I really want to go down that road and spend the time and money.

Regards,
Chuck