If you’ve reached this stage, you’ve caught up with me, and I can’t help you any more with details, but here’s a list of things I’d like to try.
- video your flights – there’s support for the PiCam built in to the code (use -v option), but I’ve not run it for a long time now – this requires an A+ rather than zero to get access to the CSI connector – so Phoebe or Chloe rather than Zoe.
- tweak the flight plan to add horizontal motion steps between a couple of hovers – I’ve done a single test on this, and it worked reasonably with no code changes.
- add a simple remote control by using a os.select() call with 0 timeout on stdin inside the FlightPlan() code – use the arrow keys to direct the flight laterally during a long ‘hover’ phase.
- The DroTek board has a barometer and compass too, so you could add height and orientation control, and to some extent a further input to calculating angles based upon the change in location of the earth’s north pole compared to the quadcopter frame – similar to the integrated gyro data but with an immovable reference point and no integration drift.
- A true remote control requires some more significant work to the code:
- remove the X and Y velocity PIDs
- replace them with angle PIDs
- the angles are derived from GetAbsoluteAngles() and integrating the gyro – they are both quadcopter frame values.
- you probably want to discard the GPIO edge_detect_wait() code, and instead, use os.select() to listen on both the data ready interrupt rising edge, and the incoming RC messages – looks at the GPIO/source/event_gpio.c for details
- If you’re sticking with autonomous flight, then a USB GPS is a good next step once you have the compass working to allow the flight plan to be specified as absolute directions at fixed speeds with the GPS providing long term low resolution backup to the less accurate but high resolution compass settings.
- With a GPS in place, you can do something awesome like the Hexo+, which controls the quad through a smart phone, using the differences between the phone and quad GPSs, combined with predefined set of flight plans to make the quad follow and video you autonomously while you do cools things like skiing or mountain biking!
There’s one big problem with all of these however: a single CPU Raspberry Pi running interpreted CPython is near its performance limit already. This means adding more sensors risks missing readings from the IMU. The autonomy relies critically on catching every sample to ensure acceleration integrates accurately to velocity.
There are two solutions to this performance problem, as long term followers will know: move over to PyPy or wait patiently for the A2; both will provide the spare CPU cycles required for further processing, but both have significant problems:
- The GPIO and RPIO use the CPython API to product libraries that CPython can import; PyPy doesn’t use these, instead using CFFI for provide direct access to ‘C’ function calls from Python. I’d need to pull out the ‘C’ code from GPIO and RPIO and put that into a CFFI framework. Trouble is, I’m fairly ignorant on how this works, and the fact the GPIO and RPIO code isn’t mine makes this more complicated. And my confidence is not that high that it will produce the performance enhancements I’m looking for.
- The alternative is to swap Phoebe over to (the yet to be announced) 4-core 1GHz 512MB RAM A2. This will allow me to split motion processing and sensor reading across cores, leaving a couple spare for other sensors. The problem here though is that the release of the PiZero at best has deferred creation of an A2, and at worst, cancelled its development altogether.
So for the mo, I’m stuck again.