Hello,
AvrMiniCopter is a quadcopter controller that works on SBC + AVR setup. The AVR role is to read gyroscope + accelerometer sensors and stabilise the quadcopter. It runs a very basic quadcopter controller that was written from scratch. On the other side SBC (Raspberry Pi or Odroid) reads any additional sensors (like barometer) and issues requests to AVR. It also processes any data from AVR (i.e. to do charting, flight log). SBC also provides WWW interface for configuration and debugging as well as 2D/3D FPV over WIFI with Android device.
This works pretty well as explained and shown in here:
http://www.rcgroups.com/forums/showthread.php?t=2302054
Going forward with the project I’m considering replacing the backend (AVR software) to use a modified version of MultiWii. Why? - I do not want to re-invent the wheel when it comes to functionality like return-to-home, position hold etc. And foremost MultiWii seems to be a very well written and has easy to understand structure.
To do this move, MultiWii would need to support bi-directional SPI communication to SBC. In this setup SBC will be feeding AVR with configuration, altitude readings, GPS readings and yaw, pitch, roll, throttle and other requests. While AVR (MultiWii) will be responding and providing data for charting, flight log and other purposes. This obviously renders certain aspect of MultiWii redundant - like EEPROM, LCD, BARO and GPS reader, etc.
Hence, I see two ways going forward:
- bake in SPI support into current sources
- fork MultiWii to create something like MiniMultiWii with most modules removed and the code altered to read all data over a single SPI channel
At the moment I am more keen to go with the latter approach as I fear changes might be conflicting. Any objections or opinions?
Thanks,
Gregory