Afternoon all...
I've been meddling with an Arduino, on & off, for some time, and enjoy it very much. I'd quite like to do something a bit cleverer than a combination lock though, and - typical bloke - I begin to wonder if I can do something creative with a quadcopter. I should point out that I've never flown an RC model, of any flavour, so I figured "how hard can it be...?"
Ultimately, I'd like to build a completely bespoke homebrew FPV machine. Being based in the UK, I am (legally?) limited to 27, 35 and 459MHz or 2.4GHz. This seems to exclude most FPV gear which runs at .9, 1.3 or 5.8GHz. I'd come up with the idea to use a pair of 2.4GHz transceivers i.e. transmit commands from the ground station to the aircraft and transmit fpv/telemetry back from the aircraft to the ground using the same transceivers, thus avoiding the problem of having 2 2.4GHz systems in use simultaneously. However, as the Arduino simply isn't able to handle the data volumes generated by a video camera, I'm not sure how I can do that.
So for now, I'd like to try to come up with a simplified 2-way system which sends commands from ground station to aircraft & receives telemetry back. Since I will have to tear up a radio system to do this (have you seen the price of potentiometer joysticks?!), I may as well also use my own command protocol.
So, here's the plan:
X times per second (50?) the Arduino will sample the stick positions and any switches I may add. Left stick will control altitude up/down and rotation ccw/cw. Right stick will control forward/backward left/right slew. Kind of like an arcade machine, rather than a true flyer. Obviously, this only makes sense for a rotary-wing aircraft, a fixed-wing would need different commands. Anyhow; package up the stick positions and any switch positions into a data packet, and transmit to the aircraft. As soon as we've transmitted some commands, switch to receive mode and wait for some telemetry. Once the telemetry is received, output it to the serial port (or whatever we end up doing with it); then if there's any time left, idle until it's time to send again.
Meanwhile, some distance away:
The receiver picks up the commands, which the Arduino reads & decodes. Based on the sensor readings, and the stick commands, it decides what power to feed the motors in order to carry out the pilot's request. Once the power settings are decided & output to the servos/ESCs, the telemetry is read - e.g. battery condition, power use, position, velocity, etc., packaged up into a data packet and transmitted back to the ground station.
I reckon on using an Ardupilot Mega as a starting point for the flying side of things. The radio stuff I'll hack together from some old crappy 27MHz gear. The bit I'm not sure about is whether the 2.4GHz transceiver modules I've been looking at will work properly when they're constantly being switched from transmit to receive - these are the ones I am looking at: http://uk.farnell.com/quasar/rfm70-s/module-transceiver-smd-2-4ghz/dp/1878287 The chips appear to be compatible (Chinese-stylee) with the NRF24L01 chip, so I am hopeful that I can use the RF24 library to generate my datagrams. Any thoughts on this gratefully received. I guess ultimately it's not much different from a wireless network with two nodes...
