This article is part six in a series, describing some of the inner workings of an autopilot system - even though the description is specific for this particular system, a lot of principles are generic and can be used to describe a variety of auto pilot systems.
To summarise the previous posts we had:
Part 1 that introduced to overall concept of a decentralised autopilot, where the autopilot can reside on a remote server and/or guide several drones in a coordinated effort.
Part 2 about the overall software architecture and hardware interface.
Part 3 A detailed look into some of the software features.
Part 4 Flight testing the small vehicle UTV-3 to prove the basic concept in real life and explaining the wonders of PID.
Part 5 A description of the complete electronics that goes into the final vehicle including gas sensing hardware.
Today we take a look at the complete “guts” of the next test vehicle, how it’s set up for test and the fitting inside the actual frame. Also a short video from the 100% automated checkout and pre-flight sequence.
Intro
Last time we took a look at the analysis unit that hosts the gas sensors, arduino, IMU etc.. One thing I didn’t mention was the analog accelerometer (it arrived after the previous post).
The ADXL335 is outputting an analog voltage for each of the three axises. The idea is to measure two things;
Big and slow vibrations caused by either a feedback in the IMU causing wobble or a bad airframe design or misaligned cog
Small and fast vibrations caused by unbalanced props, loose motor mount etc….
To measure vibrations we have to sample the output of the ADXL335, x number of times each second and compare each sample to the previous one. Problem is that one x value is good for measuring case 2, and another for case 1.
After a lot of testing it seemed that case 2 gives good results when sampled at 380 hz, while case 1 is better at around 20 hz.
The Arduino that interfaces with the ADXL335 is therefore programmed to take a subset of samples from the 380 hz sample set, equivalent to roughly 20 hz. This way, we get two vibration numbers for each axis, one for small & fast vibrations and one for bigger but slower vibrations. The numbers are sent together with the values form the gas-sensors to the autopilot, and the watchdog will warn if either vibration measurement is above a certain threshold.
Testing rig
Before fitting the electronics onto the airframe, a test setup is made, where everything is connected and tested. This is much easier when the electronics is not yet placed in the airframe and the modularity of the electronics make the transition easy. I did however place the boxes in the airframe prior to testing, to make sure we had enough room for interconnecting as well as getting a good COG.
This is the complete electronics block diagram, that shows how everything is interconnected.
Power consumption of the electronics, without servos and motor was measured to roughly 0.35 amps, which means that the computer and sensory would be able to run a full 14 hours on a 5000 mAh battery - not bad.
Software packages
We will test two different software packages, one being the autopilot software described and used in the previous posts as well as a combination of “The SIXPack” and ALF.
The SIXPack (Scientific Instruments Xpander) is a universal software to gather data from various sensors (cameras, gas sensors etc.), process the data and send it in near realtime through a GPRS connection. Together with the ALF (http://diydrones.com/profiles/blogs/in-a-tight-spot-where-would-you-land) the system will be able to capture footage from the onboard cameras, analyse them and send the result on to a computer on the ground - all in near real time and the reciever can be located anywhere as long as it has internet connection! Pretty Sweet!
Testing
There are several things we'd like to check while the hardware is mounted on the test rig. Most important is ofcourse that the systems that need to talk to eachother, are in fact doing so. This includes the sensory platform, that through I2C sends data from gas sensors and the analog accelerometer to the onboard computer. The IMU also sends a lot of sensor data the same way, through a serial connection. After some hazzle with level shifters, I got all data fed into the onboard computer, and also got the GPRS modem to send pictures and telemetry to a client on my laptop (no wires).
I'd also took some measurements of how hard the main computer CPU was pushed while just receiving and processing telemetry and sensory data. After approx. 30 seconds the average CPU load was on 19% which gives us plenty of headroom for image processing or guiding other drones from the main drone.
Mounting
With everything working on the test bed, it's time to put the two boxes (sensory+IMU and onboard computer) back on the airframe. With the boxes in place, the battery can be mounted on top of them and placed for optimum CG.
Total weight is 1.33 kilo grams, which should be fine for this airframe.
More Testing
So with a lot of work put iton diagnostics, the final checkout is pretty easy to perform. If the craft completes the automatic checkout and preflight check, everything should be good for the first real flight. Everything is controlled by the statemachine and only a 100% pass will lead to the craft going to READY state.
The preflight check makes sure that:
1. Commands can be sent from the autopilot software to the IMU and acknowledged by the IMU
2. The telemetry link between IMU and onboard computer performs perfectly (in terms of datapackets and signal fidelity)
3. The primary flight sensors deliver stable numbers
4. Servos and engine is responding
Below is a video that show the startup and run of the preflight, checkout sequence. The laptop client receives overall info from the onboard computer and reads them aloud. This is also convenient when flying, because you don't need to look at a screen while the bird is in the air.
The preflight sequence was performed 10 times in a row without a glitch. The Autopilot client can be run on any java capable device and receives telemetry data and statuses from the onboard computer.
So were does that leave us?
Right, so a summary of the vehicle looks like this;
UTV 1 - Flying wing with additional sensory system and onboard computer for auto piloting and data analysis.
Sensory consists of two on board cameras (one normal and one NIR), two gas sensors (Monooxide and Methane) and a analog vibration sensor.
Communication and data down/up link through a GPRS modem using the XMPP protocol (means that control and monitoring can be done anywhere, as long as there is an internet connection).
Range safety and vehicle performance auto monitoring with capability to shut vehicle down or land if problems occur.
Flight testing the ALF system for automatic landing spot detection.
Manual flight through 2.4 gHz radio.
All in all, pretty cool :-)
Next time
Next time we’ll take the UTV-1 for it’s first test flight - pretty exciting.
Comments