Blogs

Video of ROFL Tuning Session with spectacular crash when we deliberately detune one of the PID values! No quadcopters harmed (much) in the making of this video.  Video of stable flight below.

By the way, the ROFL quadcopter kit is still on sale on my website: http://www.universalair.co.uk/catalog/rofl for special Christmas/New year price!

The video shows our tuning set up, this is the setup we use to test and tune new control schemes for our ROFL kits, and you can see part of our debug console running on a laptop - it's an app that contains logging functionality, displays raw hex values from the quad, and also sends various parameters with plenty of input boxes and sliders.  There are no labels on the sliders and the input boxes because the speed at which we develop the code means we repurpose these inputs for different parameters several times a day.  End-users of the quadcopter kit will have a much more streamlined interface that can be used to fine-tune their quads.

The ROFL we use for code development is our ROFL-H variant, which uses Hivebrain instead of Forebrain for the control board.  Hivebrain is the same ARM Cortex-M3 powered microcontroller board, but with an integrated surface-mounted XBee module with external antenna.  The computer has another Hivebrain module connected over USB (that you can see in the foreground), communicating with the debug console over USB-HID, which we find to be a lot more reliable than USB-Serial that you would normally use with XBees, and a lot easier to implement since Hivebrain/Forebrain has a built-in USB-HID stack in ROM.

At the end, as a quick demonstration, we change one PID component to zero just to see what happens.  Turns out this is a bad idea and leads to fast growing oscillations!

Here is another video taken in the same session, testing the current codes response to external disturbances, I use my right hand on the cyclic, so when I am using it to push the quadcopter around I only have throttle and yaw command available. The clutter and confines of the garage are a bit limiting, and we need to add finer throttle control.  We are moving to some larger testing grounds soon!

As an engineer of rapidly growing experience, one of the hardest lessons I have learnt is how much time testing and tuning can take.

In an ideal engineering world, no testing is required, and no design modifications are needed during the build. The closest we come to this ideal is in the design and manufacture of very high cost structures such as civil turbofan engines and bridges. However, because these structures are so critical we have to use 99% previously proven theory and design methods, which in turn means changes are incremental, it is not economical to make wild guesses and risk significant differences from one version to another.

Micro UAV design is much the opposite, making exciting new designs into uncharted territory can be very rewarding, discovering new operating regions and performance gains, importantly it is also feasible to do this as mistakes are not economically self destructive.

ROFL, shown flying in the video above, is what I'd class as a structural design tangent, it differs from already available UAVs not in concept, as it uses a conventional quadcopter layout, but in structural design.

The vertical plate design makes the construction extremely simple, the frame very cheap, highly modifiable, at no sacrifice to weight or stiffness. Yet it is very much still a quadcopter.

Converging on a successful mechanical design and writing the initial flight code was a small part of the challenge however, the BIGGEST CHALLENGE then became streamlining the code modifications and tuning!

If each time you make major changes to the code, you have to retune, it's easy to see where a lot of your time is going to be spent over a few months!