We've recently made the move from the old clunky DCM implementation to a new Quaternion approach, and it seems to perform better, or at least the code is much smaller and takes almost no time at all to execute on our 72MHz 32-bit flight controller. I'll be writing an article on the Quaternion method as part of our series on Engineering Insights.
We've also added MAVLink support, and full integration with QGroundControl GCS. This helps greatly with debugging, and of course enables waypoint flying. The ROFL quadcopter kits have GPS built-in, and wireless versions that include an integrated XBee module are available.
Still to come: waypoint flying, and FPV: The flight controller GPS code just needs a bit of tuning, and we'll have the thing flying autonomously in no time. The full-range of waypoint options in QGroudControl are supported, including waypoint tolerances, and yaw angles. (See image below):
Tuning the quad is also possible over QGroundControl, this is a massive improvement in useability over our previous custom solution:
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.
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!
Seraphim is our sensor board for the quadcopter, it includes accelerometer, gyroscope, magnetometer, barometer, GPS and micro-SD card slot. With the exception of the GPS unit, all of these components are a complete pain in the backside to solder properly, and there are some consequences of not being careful with constructing prototypes, we'll explain all below
An update from the guys at Universal Air! Normally, the less we post, the busier we are making exciting new electronics and flying things, this time it's been no exception. As always, you can keep up with us by checking our website:
We have decided to present some helpful hints and tips that we have learnt along the way as a mini series of blog posts. We're calling this series "Engineering Insights: learning the hard way from concept to finished product"
I'll start them all with "Engineering Insights - Lesson...." so keep your eyes peeled for handy advice and some engineering explainations!
This first lesson is all about mistaking hardware faults in temperamental prototypes for coding errors, and the hair tearing that can result!
Lesson 1: Problems with Prototypes:
Starting out designing making your own PCBs isn't for the faint of heart. When you don't have an existing design to work from, there are a gazillion things to get right in one go - the circuit itself, the component's footprint, component values, various requirements for track layout, and then there's the assembly quality, and then the software aspect. Through our epic journey bringing the Seraphim board from concept to product, we've encountered problems with each and every one of those above points, and torn out a lot of our hair as a result.
One of the most frequent problems with that we encounter is poor assembly quality of our hand-built prototype boards. But we didn't know this at first; for a long time we though our code just plain didn't work, and we wasted a lot of time debugging, optimising, and rewriting bits of code, only to find out that the thing worked perfectly fine when one corner of the chip was pressed down! It turns out the number one problem with the software is actually the hardware.
We used to solder chips onto our prototype boards using either a gas hob and frying pan, or a butane hot-air pencil (QFN packages can't be soldered properly using a soldering iron, trust us, we've tried). While we've become very proficient at assembling PCBs (the top right photo is of two Seraphim prototypes, various components attached to each) in the kitchen, the chance of a single unmade solder connection is simply not worth the grief. We recommend to anybody making a circuit from scratch to either use components that can actually be soldered by a human, or invest in some reflow-soldering equipment.
We've made our own reflow soldering system out of a cheap toaster oven, controlled by Forebrain of course (making it possibly the first USB-controlled 32-bit toaster oven). We will cry if this doesn't solve our prototype assembly quality problems.
Our production-quality Seraphim units however don't have any of these problems, they've been manufactured in a factory using industrial PCB assembly machinery. And once we got our hands on the units, we managed to solve ALL of our existing problems in mere minutes (these were the problems that have been plaguing us for the last few months).
Here's an example to show you how easily problems can occur and how weird they can be:
Our Seraphim prototypes are sensor boards,they include a variety of difficult to solder chips such as accelerometer, gyroscope, magnetometer and barometer, none of which have leads to solder (the GPS thankfully wasn't too bad). During the testing of one of the first Seraphim prototypes, we hooked up the Seraphim and Forebrain to output the 3-axis gyro data over USB HID (Forebrain has built-in USB HID, so it's actually eaiser to just use that and plug the USB cable in rather than faff around with plugging a serial cable in). We found the ITG3200 gyro chip behaved extremely oddly, it would only output values when the board was rotated in one direction.
This was a strange problem, but it was consistant - rotate the board in any direction in the other two axes and nothing happens, but rotate the board in a certain way, and the values output fine! At first we though this must be something to do with the chip itself, otherwise how could there be a problem that persists so specifically to that one axis? Then we tried debugging the I2C code, since it was the I2C which was timing out, perhaps it was some strange quirk to the way I2C is implemented on either the gyro or the microcontroller. But no, it was neither of these things, it turned out that things started working again if we pressed the gyro down with a thumb: these very strange yet very consistent symptoms were caused by a single loose connection, which would only connect itself when the board was rotated in a certain direction.
Everything was sorted after repairing the loose connection.
Here is a retail Seraphim, sexy in its black livery, alongside an equally attractive Forebrain!
The same Seraphim busy at work in the heart/ head of our newly released ROFL quadcopter!
Posted by Henry Fletcher on September 11, 2011 at 3:03pm
Here you can see the little guy we have just begun to use and will be releasing for sale in early October. The black Forebrain board is what was running the autopilot code in ROFL up till now, 72MHz ARM Cortex-M3 microcontroller, measures 66mm*23mm. The longer Hivebrain board is what we will switch to and will bundle as an optional upgrade to Forebrain with the ROFL kits, it's the same Forebrain pinout, but with a surface-mounted Series 2 XBee module using an external antenna, measures 111mm*23mm. No more messing around with weirdly spaced Xbee module pins!
For now it is proving an absolute god-send for PID tuning and other tweaks...speeds the process up considerably, in flight it can be used for all sorts of telemetry transfer. I'll be using this system in my upcoming video guides and demonstrations for PID tuning.
Posted by Henry Fletcher on September 11, 2011 at 7:31am
Well, after a rather merry holiday in Scotland I'm back and will be posting a load of development videos (mainly of ROFL) for those that are interested. This is our first attempt at flying outdoors in the night. Actually this is the first time I have ever tried to fly a model outdoors at night, it takes a little getting used to, all your old reference points are gone and suddenly you only have some very bright LEDs to refer to! Though we actually pointed the LEDs at the aircraft which made it partially visible and reduced the light intensity, I recommend this approach for anyone thinking about it!
I have some cunning plans for a much crazier and more exciting lighting system to be built soon. Keep in touch with all our progress as normal at: www.universalair.co.uk
Yuan has pretty much finished writing heaps and heaps of code for Forebrain...now we have a comprehensive set of functions in the guides section: www.universalair.co.uk/guides
I for one am massively excited about some of the things that are now possible! I am just about to start soldering up the neat little Servo Connector board prototype: www.universalair.co.uk/content/big-prototype-run
It looks more than elegant sitting in the "brain space" of ROFL. I'll post some pictures soon. Need to get in as many test flights as possible before the bad weather sets in.
As with any inventor, designer or engineer, things don't always go my way!
Actually as it turns out, I did not damage the Seraphim prototype, but did destroy the reciever! That cheered me up a bit as we have much more need for the Seraphim rather than the reciever at the moment, I have spare of the latter.
Nonetheless, the lesson still stands...check all the wiring, check it again, and check it once more. The problem is that bad wiring doesn't always do damage, so I tend to rush soldering jobs, if you cut a bit of wood short, there are no two ways about it....it definately won't bridge the gap!
I've been running loads of new tests recently, which I'll gradually find time to talk about! Check here on DIY drones for more detail and other information I don't have the time to post more than once on our website: www.universalair.co.uk
I know a couple of people at least were keen to see if it actually flew, I was a little skeptical it would be able to balance itself in the pitch axis myself!
I'll post another video shortly which shows some of the less successful flights, where it didn't quite manage to balance!
One of the biggest problems seems to be the landing gear.
Next challenge: Transistion and conventional flight :D
Well, I diverted onto a quadcopter frame I have designed and built in order to test the electronics and my code, and here it is working, reasonably well! Though many more improvements are yet to be made!
In the first clip I simply increase the collective throttle, with stabilisation enabled, and then catch it as I have no directional control to prevent drift.
In the second clip I have done some p d loop tuning and have it happily responding to inputs from the transmitter. I'll follow this blog up with some more videos soon!
In the near future we will be running quadcopter and uav workshops at various locations in the UK and publishing each as a video guide on YouTube.
We intend to publish a comprehensive guide on PID loop tuning for model aircraft - it was very exciting to immediately swap the electronics into two other airframes we have (including Talon) and with only an hour or so of fiddling, have them flying stably too!
When I first got interested in UAVs I took the advice of some of the forum members here and equipped myself with arduino based systems....but I'm a crazy engineer and this approach didn't last long before I had convinced myself I could make a better job of all this if I started from scratch...luckily I also managed to convince a friend of mine who specialises in electronics!
I'm an aeronautical and mechanical engineer, or I will be when I graduate! Resultantly I love all the spinning bits and the frames etc!
I've been a RC enthusiast for a while now and my original intention was to get a Radian glider flying autonomously, but just like the electronics, I swiftly became interested in a more exciting idea which I would have to custom build.
The result was the Talon airframe, which is the first in a series of aircraft with three goals in mind:
Vertical Take off and Landing (VTOL).
High Sprint Speed.
Long Loiter time in slow flight.
As you can see in the picture above, it is currently rather experimental and a little crude. The target of high speed flight has been completely ignored for now. Concessions to low speed loiter come in the form of modified Radian Glider wings and VTOL is achieved by wing and motor tilt.
I'll write more detailed posts about Talon on my website, www.universalair.co.uk - where the code will also be released open source.
It is controlled by the boards my friend has designed which we call "Forebrain" - the processor and "Seraphim" - the sensors.
Here is a brief video of a suspended test, as you can see, the pitch axis whilst hovering is the least damped and worst aerodynamically actuated so it has been hard work getting it stable, I'm currently running code verification on a quadcopter before returning to Talon.
Will probably post soon about the quadcopter too, looking forward to hearing any interesting comments/ ideas about the aircraft!
Tuning the quad is also possible over QGroundControl, this is a massive improvement in useability over our previous custom solution:
Loads more to come, I'll keep you guys posted.