I got quite a few questions on what get I used to encapsulate the IMU. The gel is the Dow Corning Sylgard 527, the consistency of the gel is controlled by the proportion of part A vs. part B. I used 70% part B and 30% part A. After you mix the two parts you need to heat the mix (and the board in it) in order to cure. I put it in an oven at about 70 degC for 2 hours. It will also cure at room temperature but it may take several days.
After implementing the DCM algorithm on the CHR-6D IMU it was time to flight test it on my quad-copter. I used the same controller I developed last year but instead of using the onboard 5DOF IMU, I connected a serial port to the CHR-6D IMU. The filters and DCM algorithm was executed on the STM32 of the CHR-6D, the direction matrix was sent to the control board through the serial port. Only a few minor modifications were made on the control software to use the angles from the direction matrix, the rest remained the same.
I spent a few hours tuning the PID gains, filter cut-off frequencies and DCM parameters and the results look very promising. Occasionally, small corrections are still needed to keep the quad-rotor in one spot but that was expected. With a GPS and altimeter it should be possible to control the position and altitude fairly accurately.
The main reasons for the improved performance are:
The ESCs are still controlled using PWM, stability should improve by using a I2C ESCs and a higher update rate (>100Hz). Stability is not as good as in some more high-end setups but I can comfortably fly the quad-rotor outdoors, in fact it is easier than flying a heli. I still need to test the effect of large acceleration on the stabilization e.g. fast ascent, descent or turns (can be easily corrected by calculating and subtracting the centripetal acceleration).
I recently got the CHR-6d IMU from CH Robotics, I needed a 6DOF (3 gyros and 3 accelerometers) for my quad-rotor. In my last attempt I used a 5DOF IMU and did all processing in the control board. Although I was able to get it to hover fairly well with only minor manual corrections I had two main limitations. Processing power and sensitivity to vibration from the frame. The CHR-6d has a powerful ARM Cortex processor with plenty of processing power available for filtering and additional signal processing. I was able to drastically reduce the effect of vibration by complete potting the IMU in dielectric gel.
The board comes with open source software the implements the digital filters and serial communication. I needed to extend this functionality to calculate the actual Euler angles (or equivalent) that would be used to stabilize the quad-rotor. I have tried a Kalman filter in my last attempt so I wanted to try out something different. I found an excellent paper from William Premerlani that very clearly explains the theory behind the Direction Cosine Matrix. I prototyped the implementation in Matlab and tested it using data from the actual IMU, I also did a few vibration tests by mounting it on my quad-rotor and powering up the motors while holding it fixed on the ground. With the dielectric gel I was able to reduce the effect of vibration to about 1-2 degrees of error when the motors are running at 65% throttle (typical hover is 55%). The ultimate test will of course be a flight test.
The following video is a ground test of the complete setup. The implementation is not yet completed, I have a 3-axis magnetometer break-out board for the HMC5843 from SparkFun. It will be connected through the I2C bus to the CHR-6d IMU and will be used to correct the drift of the yaw gyro.
You can download the latest version of the DCM implementation and Matlab scripts from the DCM page.
This month’s DIY T3 contest was definitively more challenging. I was only able to have one attempt due to the weather and a few other projects that kept me busy. I got first place on this round as well!
This time the challenge was that on each waypoint the altitude would change. I was able to hit the target altitude within 5m at each waypoint, it was a clean run. This attempt was without using the airspeed and altimeter sensors (not implemented at the time).
Today it was the perfect day to test the new airspeed and altitude control loops. The wind was very gusty and with an average wind speed of 10 m/s, normally I would avoided flying my EasyStar in a day like that but what a better way to test the sensors and control loops! I had a few flights the day before in more mild conditions and had a chance to tune the altimeter and airspeed gains (see previous post for implementation details). The GPS only vertical control loops do a very good job when the wind is not too gusty, usually in days like today I would have to modify my airframe configuration to force the throttle to higher values than usual. With the airspeed sensor this is no longer needed, it will keep the airspeed in changing wind or attitude (e.g. climbing).
The following plots is from today’s flight. I was flying an oval against and with the wind, wind speed was about 10 m/s. Altitude hold was done with the barometric altitude sensor.
For comparison the GPS altittude is also shown. Aggressive climb mode is still not enabled. The EagleTree altimeter is read at 20Hz and the existing Kalman filter is used to calculate the rate of climb. What I found interesting was that the pitch and altitude gains had to be increased considerably when the barometric altitude was used instead of the GPS. I am not sure why, it might have something to do with the update rate or the slightly modified Kalman filter parameters. After some tuning, I am fairly satisfied with the altitude hold (+/- 2m from setpoint for most of the flight), especially considering the effects of the high wind speeds.
The airspeed hold was the main reason I started this project and the benefits are obvious in this example. The throttle adjusts to keep the airspeed close to the setpoint. This time the airspeed deviation from the setpoint was higher than the last flight, the gains were the same so I believe the winds gusts might be to blame. I will try to see if I can improve the gains in the next flight.
The new airspeed and altitude control loops will come in handy in the next DIY Drones T3 contest! Since endurance and not speed is the next objective, optimized throttle control will be essential.
I have a total of about 10 flights with the modified code and the EagleTree sensors with no major problems. I will be submitting my changes to SVN in the next few days. I still need to look into the following (hopefully in the next few weeks):
I was able to do a test flight with the airspeed sensor and the modified airspeed and altitude control loops. Some further tuning is required, but I am fairly happy with the results I got so far. First a brief description of the modifications made.
Besides the drivers for the EagleTree airspeed sensor, I had to modify the vertical control loops to make use of the airspeed. Since the actual airspeed is now known, I decided to try separating the altitude and airspeed loops as shown in the diagram below. Basically the throttle and pitch are now controlled independently and are not coupled in the control loops (of course one affects the other but the control loops are independent). The airspeed is controlled by two cascaded PI loops, the first is used to regulate the ground speed and the second the airspeed. This is needed to ensure that if the ground speed drops below a certain value the airspeed will be increased to compensate (in order to maintain a valid GPS heading).
I did some basic testing on the simulator (using airspeed = ground speed) and it worked well enough to fly test and tune. The following two plots are from an actual test flight after spending some time setting the loop gains (the real-time tuning through the GCS is a time saver!). The plane was flying circles at a constant altitude (except in the end). The wind was about 5 m/s, judging from the ground speed variations. In the middle there is an example of what happens when the ground speed falls below the setpoint. Finally the altitude setpoint was changed to verify that the airspeed will be maintained while climbing.
The altitude gains were the easiest to tune. Altitude is maintained fairly decently, at the end the altitude setpoint was changed (aggressive climb mode was disabled). This is still using the GPS altitude, barometric altitude has been implemented but not tested yet (Kalman parameters may need some tuning)
Considering this is the first flight test I am fairly happy with the results. I would like to see if I can get the airspeed to hold closer to the setpoint, the reading is inherently noisy so either some additional filtering or further tuning of the gains might help. As soon as everything is tested I will submit to SVN. Remaining items that need testing:
I was able to do a quick test with both sensors connected. The barometric altitude together with the GPS altitude is shown in the plot below.
There are some discrepancies at the lower altitudes that I will need to work on a bit more. The coefficients for converting raw values from the sensors to the actual altitude and airspeed are calculated experimentally so some tuning may be required.
The source code was also released. This is code I am using to test the sensors and does nothing more than sending the altitude and airspeed data to the GCS. The next step will be to modify the airborne code to make use of the airspeed (for example maintain constant airspeed by adjusting the throttle).
I had a successful flight with the EagleTree airspeed module connected to my TWOG. I did not have to do any hardware modifications, the sensor has an I2C interface that I connected directly to the TWOG I2C port. I was able to figure out the slave address and decode the raw output of the sensor. The results are quite good, the module is low cost and comes with a very good pitot tube (Prandtl style, pitot-static tube) that includes static and dynamic ports. For now I am simply sending the airspeed through the telemetry, the next step would be to modify the autopilot code to regulate the throttle in order to keep the airspeed constant (and a minimum ground speed). I am also working on interfacing with the EagleTree altimeter sensor.
Following is the data from my last flight, there was no wind and I tried to keep the pitch close to zero for most of the flight in order to be able to compare ground and air speed.
I will release the source code as soon as I have both airspeed and altimeter tested.
My Paparazzi / EasyStar entry won first place in the first round of the DIY drones T3 competition. Very fun competition and the timing was great, right after I finished tuning my EasyStar with Paparazzi. I did damage two LiPo packs running at full throttle but the airframe and autopilot performed great! The best part for me was getting to learn the Paparazzi flight plan editor, extremely powerful and flexible. Total time to complete the course was 49.5 seconds, a lot of very good entries with most autopilots represented. This was a great initiative of Chris Anderson and Gary Mortimer from DIY drones, the plan is to have a contest once a month. In fact the September competition is already ongoing. A video and a few screenshots follow.
Success! I was at last able to fly my EasyStar with the Paparazzi open source autopilot. A few days ago I made the first flight in MANUAL and AUTO1 mode to get everything tested and tuned. Today I tried for the first time AUTO2 mode and worked beautifully! Some tuning is obviously required, especially for the roll response but it worked after only a few test flights. I will make a separate post detailing my setup, wiring (very important) and configuration files.
Following is a picture of my EasyStar, I had to move components around to minimize interference from the various receivers/transmitter. I currently have the following equipment:
The following two screenshots are from the Paparazzi ground station, two flight plans were tested an oval and a figure eight. Both worked very well considering that I have not spent too much time on tuning. Altitude was alse held within about 5 meters of the target.
Finally a video from the flight follows.
I am very impressed with the Paparazzi autopilot so far, it is open source, it has the best ground station software and a large and helpful community, what else can I ask for.