BLOG combatprofile400.it

A photo of successful flight as seen in Google Earth and X-plane:
 
Here is another ArduPilot simulation inspired by Jordi’s simulation.

My simulation requires minimum additional hardware, all you need is ArduPilot connected by FTDI cable to PC.
Actual simulation runs in X-plane simulator. ArduPilot get simulated GPS data over serial, and it returns back proposed servo positions back over serial as part of telemetry info (servos can also move physically). ArduPilot also reports bunch of variables - lat/lot/alt, next waypoint, distance to it, etc.

What you need to repeat the simulation:
- Modified ArduPilot code from this blog post
- X-plane 9 demo (buy full version if you wish, but demo works just perfect, it only ignores joystick input after 10 minutes, but we control it other way so it really doesn’t limit us)
- Google Earth
- ArduSimulator ArduSim_20090211.zip (developed by me), which is simple application that does following:
1) Connects to ArduPilot over serial for sending/receiving data
2) Connects to X-plane on localhost (same PC)
3) Reads data from X-plane (lat/lon/alt/course), sending these to ArduPilot as GPS sentences
4) Simulating FMA copilot stabilization on ailerons/elevator
5) Reads and displays telemetry and servo positions from ArduPilot
6) Sends servo positions to X-plane to control throttle and rudder
7) Records fly path and sends it to Google Earth to display

Here’s how to repeat the simulation:
- Start X-plane, go to Menu->Settings->Net Connections, select tab Inet 3 and enable “IP of data receiver”, change IP address to 127.0.0.1 and port to 49001. It looks like this:

- Select Aircraft from folder Aircraft\Radio Control\GP_PT_60 (yes, we want to fly RC plane which has ail/elv/rud/thr controll)
- Select airport Innsbruck
- You can open this KML path: Innsbruck.kmz in Google Earth, which was my testing fly plan configured in ArduPilot; this will show you the waypoints
- upload compiled ArduPilot code to the board and leave it running; LOCK LED should keep flashing
- start ArduSim.exe (simulator tool); it will connect to serial port and X-plane; if it can’t connect to serial, specify correct port and baudrate and press Start button
- click [Google Earth] button in ArduSim to make connection with GE
- hit B in X-plane to release brakes, and try keys A/W/C to choose various views
Now simulation should be running if everything is connected successfully, and you should see plane in X-plane to fly and visualization path & icon in Google Earth to move. Don’t control plane in X-plane! ArduPilot will take-off and fly on its own.

Here’s video how it all looks in action:
 
And complete flight path visualization for Google Earth: Flight.kmz
You can see original waypoints in white, and real fly path in yellow. And also final circulation over start point when all waypoints were visited…

Now about problems and future tasks:
- I have strong impression that controlling altitude by throttle with use of copilot stabilization doesn’t work properly, this simulation showed me that plane didn’t want to drop altitude from high point to lower one… see results in above flight path in GE. I’m not sure how real plane behaves (didn’t went out to real world with this yet), we’ll see.
- For this reason I plan to start playing with complete stabilization in ArduPilot, and controlling both elevator+throttle to get desired altitude.
- You can play with dozen of various parameters to control behavior, most obvious are PID settings for throttle/rudder in ArduPilot, but also PID values in stabilization (which is here provided by simulator tool, in real world it is FMA Copilot which you can control by its sensitivity setting). Then you can change maximal servo rotation for ArduPilot to work with. All these values make the plane fly smoother, make more precise turns, etc etc. And the settings seem to depend on actual aircraft and its physical behavior. So there won’t be single settings working for everyone.
- It’s somehow cumbersome to specify different altitude for various waypoints; while I converted waypoints from KML file out of Google Earth, I had to specify individual altitudes manually in waypoints.h file in ArduPilot code.

After all, I’m pretty happy to see the plane flying in simulator and doing the task! Note that it’s ArduPilot doing the navigation work. And in a real airplane, this simulation allows to reuse the ArduSim application as a base station, getting telemetry from plane over Xbee modem and displaying what it does as well as showing path in Google Earth.

In our quest to create the simplest and cheapest autopilot available, we’re debating whether we need a barometric pressure sensor or can do reasonable altitude control with GPS alone. The old answer to this was the GPS alone wouldn’t work–not only were errors of as much as 10s of meters, but glitching could leave you without any altitude data at all for many seconds at a time. But the newer SiRF III chipsets are much better at altitude calculation, and the even newer yet uBlox5 GPS module is almost as good as a pressure sensor at altitude (it’s too expensive for our purposes, but a glimpse of the way things are going). So let’s look at that question agan: do we need a pressure sensor?

The way to tell is to test a pressure sensor head-to-head against GPS under varying condition. Here’s a paper that did just that, using the older (and worse) SiRF II chipset. A sample of the data is the graph above, which as you can see shows errors of as much as 60m in some cases. Needless to say, that would be unusable. (It turns out that many of those errors were due to GPS lag, and shifting the GPS line forward by 13 seconds improves the fit considerably. But if you’re trying to fly on that data, you’re stuck in real time, so those sort of corrections don’t help.)

Jack Crossfire has been testing more modern GPSs, including both the SiRF III-based EM406 that we use and the uBlox5, and his data is more encouraging. A sample post on EM406 data is here, and a chart from that post follows:

Unfortunately this isn’t calibrated so there are no units on the scale, and we can’t calculate the absolute error. (Jack, any chance you still have that data and can oblige?). But given that the data was taken in a heli and he’s probably flying at around 30m, my sense is that we’re looking at errors of less than 6m and no crazy glitches.

If so, that’s within the usable range for us. We’re typically looking at holding altitude around 50-100m, so single-digit variation is acceptable. It’s not perfect, but doing without a pressure sensor would save us about $25 on the autopilot (keeping it below the magic $100 figure), and simplify calibration and instrument-compartment design (no need to pressure-isolate it).

I’ve got a pressure sensor coming and will do a proper head-to-head with the EM406 and the surface-mount EM312 (which will be built in to the autopilot on the production version) under various conditions before making the final decision, but for now we’re betting on GPS being good enough (and getting better) to do the trick. Anybody disagree?

As a challenge, I decided to program an arduino to fly a helicopter. It seemed like a good way to learn the language, and it’s caused me to learn processing. 

I recently purchased an Arduino from LadyAda, and started to learn the language. Having worked though the tutorials on her site I started looking at more and more complex code.

I coded an alarm clock, which successfully woke me up for a couple of mornings, 3 minutes before my normal alarm clock.

I then started thinking about what could be triggered after a specified delay, which lead me to the Nikon remote control/intervalometer. I’ve taken several long sequences of photos which I intend to turn into timelapse video.

I found sample code for reading the Wii nunchuck sensors, and tried it out to much success. This is about where Processingbecame involved. I wrote a basic readout for the accelerometer displaying a 3d cube, rotating with the reading from the accelerometers in the nunchuck.

I discovered a project someone was working on using the Wii nunchuck and arduino to stabilise a radio control helicopter.

I decided to try for myself, but using other sensors. I bought a Sparkfun development Gyro and a 3axis accelerometer, and set to coding the rest.

Using the SPI bus, I quickly got the Accelerometer up and running with the demo code from sparkfun.

I borrowed code for reading the RC signals from the Ardupilot project.

The accelerometers don’t provide any useful information for rotation of the helicopter (about the Z axis) but can provide a noisy approximation of pitch and roll.

The gyro provides only rotational information about the Z axis, so bridges the gap to give a fairly good approximation of the movement of the important axes of motion.

I found out about Kalman filters, and some example code, which I adapted for my purposes.

This code provides a stabilised value for both pitch and roll, and takes info from the accels to futher improve the quality of the readings from the gyro.

By filtering the accel and gyro together, the bias from the gyro can be lost in the filters, tilt proves less of an issue for the gyro and clean accurate signals can be achieved with little work.

I wrote a sketch in processing to decode the serial output from the arduino, which was sending all the output data from the sensors. I quickly constructed a basic display, plotting the XY angles computed, and the resulting output servo signals on an invisible Cartesian plot, this illustrates the point quite nicely…

As the tilt increases, the output to the servos reacts in the opposite direction. Hopefully this will result in the helicopter stabilising.

The radio control input affects the output too, but only by a relatively small amount, ie. auto correction mixed 60-40 with incoming human control. This theoretically means human control of the helicopter will be very smooth requiring minimum skill to operate.

Mixing all the signals to create the desired outputs is handled by averaging the various outputs into one signal per output function.

The test airframe is a Piccolo Eco 2, which was purchased on ebay for £7! After replacing all the broken bits I had a helicopter with no electronics. Exactly what I was after…

Having got a stabilised and filtered reading for Yaw, X and Y angles I felt it was time to try making it fly.

The initial obstacle to flying was lack of 2x motor controllers, however a couple of burly transistors (TIP41C - just because I had some spare,) two resistors and two diodes was sufficient to get both motors running, speed control being handled using PWM from the arduino.

Unfortunately, at this point I discovered a significant drawback to having a large breadboard for developing, and a very small heli.

Time for a helicopter-diet. At this point I decided to develop the Helishield - a small pcb which mounts straight on top of the arduino, carrying the headers for all the connections, the sensors and the motor controllers.

Using the GEDA suite of programs, I created a layout for the Helishield, headers for the Accelerometer, gyro, servo connections, RC receiver, power and motors, two small motor controllers, and so on. It all fits on a board about 50mm2.

I have checked alignment with all the sockets, now all I’m waiting for is the PCB which is on order, and some spare time to etch and drill the pcb.

I have some ideas about making a whole system, on one board, using SMT throughout, then the whole thing could be sub 3 grams! (at a rough guess!)

I am working on getting a serial control API too, I think it would be very interesting (in this case possibly interesting == dangerous) to be able to fly the heli from a processing sketch.

The RC control reading code needs work… I wish to make the system as robust as possible, and at present all hell breaks loose if I turn off the transmitter, and occasionally it generates a random value, this is probably a timer overflow, or variable overflow. But to all intents and purposes, a functioning RC stabiliser.

I’d like to look at the possibility of capturing the whole RC signal using just one pin. The data sent over RC has to be sent serially, therefore, at some point in the receiver, all the values will be sent together on one line. I read something about doing that somewhere once upon a time. It would probably reduce the workload of the chip, as all 4/5/6 channels could be collected at once, on one pin. Freeing input/output pins and reducing code are both priorities for me at this stage.

Once I have the PCB made the heli will fly (to a lesser or greater extent) almost immediately. I am confident that it will get off the ground without my 500 gram development board attached! Once it takes off, it /should/ be a matter of adjusting ratios of control output relative to sensor input.

When all of the above is complete and I have stable-ish flight, I will turn my attention to the gyro, because at present I am using the analog output from the gyro, while it is able to provide an SPI interface, meaning the code to read the accelerometer could also read the gyro, freeing up more code space. This bit will probably require quite some work.

The serial API will have the ability to adjust the flight controls, and will take a similar approach to the RC control. I plan to continue to improve the processing sensor readout, and begin adding some form of human interaction with the heli.

Some time in the new year I hope to invest in a Collective Pitch helicopter, this will open up doors for HeliShield v2.

I think the Piccolo has taught me a lot about helicopters, and it’s never got further than skidding about on my desk so far.

I think that with the Piccolo, there will be little point in having any sensor input controlling the main rotor speed, as the torque available would probably not be immediate enough to be useful, whereas with a collective pitch heli, Z axis acceleration could slightly influence the main rotor pitch to achieve really smooth hovering, even in turbulence. I will test this feature with both types of helicopter though, it would be nice if it worked with the Piccolo too, but I have a feeling that the tail rotor would be working quite hard to keep everything straight.

Maybe I should investigate recording flight data, and plotting it somehow, then compare the results from different helicopters.

——-

Today I set about printing the masks for the PCB and etching a few test boards (having finally found a box of film suitable for the big laser printer).

The first masks I printed were good, but faint. A trial exposure for 6 minutes (under the UV) resulted in most of the resist being developed.

I set the printer to the best settings I could, and the next mask was much better. The first board I made (with a 5 minute exposure) was a great match to the mask, but the fine tracks were broken in places, and the pads were too small. Some of the pads lifted from the board during the drilling and I decided at that point that a slight redesign was needed. I have now increased the size of the pads, moved the gyro and accelerometer slightly towards the center of the board. I also removed the need for the two vias by re-routing a couple of tracks through newly found gaps. PCB layout software has a strange ability to make tiny spaces seem huge!

——-

I have made printed the new masks and made some test PCBs. The process timings are now known and repeatable, so there will be boards available to order from now on.

I will look into having the whole fabrication process done elsewhere, to allow for silk screen and other niceties, like solder masking - a must for boards with copper fill combined with hand soldering.

I have five boards for sale at £10 each, with more available if needed. Populated boards will be available soon.

If anyone is interested in the first few boards available, please contact me via the link at the bottom of this page.

The board carries two motor controllers, power and radio connections, 4x servo outputs (2 share pins with the motor controllers - either use the motor controllers, or the 2 extra servos, not both), a serial header, and sockets to fit a gyro and accelerometer.

I chose to fit sensors onto headers so the sensors are available for other uses. I am looking into building a complete system on one board with the Atmel micro, Accel, Gyro etc all fitted. It would probably be entirely SMT too, for the weight savings. Let me know if you have any ideas you’d like to see incorporated into the design.

———

I have partially populated the Helishield prototype with the parts for the motor controllers, pins to connect onto the arduino, servo headers etc.

Minor alterations have been made to the design to aid assembly,and to improve the position of the sensors. Both sensors are now roughly central.

A couple of tracks which were just too close for comfort have been tweaked too.

I’m awaiting delivery of the sockets for the gyro and accel, there seems to be a shortage. For the photo, I just plugged the header on the sensors into the holes on the PCB.

——–

I have been working on the serial control code for some time now and I have just succeeded in getting reliable control of the values in the flight algorithms from my processing sketch.

I have been offered a broken xBox 360, the dvd drive has failed, I looked up the use of the controllers using Linux, and have compiled and install the kernel module. I will have to see whether it works once I actually have it to work on. I also intend to replace the dvd drive and reflash the chip on the drive in order to boot live cds on the console. I will then try to set up the 360 as a flight control station - it seems to be plenty capable of the task.

I have also set up the library for Processing needed to read values from the controller (or other joysticks), although I can’t test this until I have the controller.

I will have a system together very soon that should be light enough to fly, I will be testing all aspects of the control, and tuning the flight algorithms to stabilise the flight as much as possible.

————–

Over the Christmas break, this project was on the front page of Sparkfun Electronics, causing a massive boost to traffic.

I’ve now answered questions from Bangladesh, Spain, Brazil, Russia and more…

Filling in the time between eating and sleeping, I was coding. I have written a test sketch for the Arduino with the intent of capturing all the incoming RC data in one pass, on one pin. The idea being to free up space for more (both in code and physical input/output)

Radio Control systems use PPM to code together a chain of pulses with the duration of each cycle being the value of a control, followed by a framing pause to enable the system keeping in sync.

I will test this as soon as I can get to my RC rx with the oscilloscope and find the PCM signal.

I intend to use this advance in code to further reduce the need for hardware other than the Helishield, I plan to design a complete on board solution soon.

————–

The serial API is now fully functional too, I can smoothly control the XY movement of the rotor, and control Throttle and yaw, all from a processing sketch (and potentially anything else that can output serial - yes, even your mobile phone…)

———-

I have successfully coded a system for reading the PCM data of the radio control signal (and hence all the channels available, entirely on one input pin.

The code times the the length of the cycles of incoming pulses, when the framing pulse is found a loop starts which records the start and finish times of each cycle, then the difference between these times is the RC control values.

No matter how many channels of radio you have, thee is only one period of waiting involved with reading the signal, so overall efficiency of the code is better than waiting for a signal on each pin of the RX.

—————

The collective pitch version is coming on fast, the code is nearly complete, and the helicopter is in transit to me. I will soon have all the equipment needed to flight test both the collective pitch and the Piccolo style helicopters.

Alongside the new PCB for the Arduino Duemillanove to control a CP heli, I will be releasing a system entirely on one PCB for weight and space saving reasons, and also because I’d like to keep the helicopter built up permanently.

There are currently 5 PCBs available for £10 each.

All the testing code will be available soon, as will the Helishieldv1.5, in both kit form, and pre built (with or without an Arduino - TBA).

See the artificial horizon page for more info.

To view or download the code please click here.

Please click here to ask a question, send your praises/insults to me!

You can build a waterproof GPS logger by putting the shield, Arduino and small power supply in an Otter Box!

Arduino Diecimila: new improvements to commemorate 10,000 boards.

Saturday, August 11th, 2007