Vassilis' Hobbies and Projects

Powered Paragliding Over Honey Brook, PA

2011-10-02T10:03:00.000-07:00

Since last year I have been learning to fly a Powered Paraglider (PPG) and I received my PPG2 certification.

Working on the OpenPilot project

2010-03-04T20:36:00.000-08:00

In the last few months I have been working on a new open source autopilot project called OpenPilot. The project is still fairly new but with a lot of potential, I am developing the flight software architecture and framework. Check it out!

IMU potting in gel

2010-01-04T14:03:00.000-08:00

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.

Quad-rotor demo with CHR-6D IMU and DCM algorithm

2009-12-30T13:01:00.000-08:00

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:

Encapsulating the IMU sensors in gel to reduce vibration

High speed sampling and extensive filtering of raw sensor data

Direction Cosine Matrix using a 6DOF IMU (3 accels and 3 gyros) - although a Kalman filter should also have worked

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).

Direction Cosine Matrix implementation for the CHR-6d IMU

2009-12-20T07:48:00.000-08:00

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.

DIY Drones T3 contest - Round 2

2009-10-22T15:02:00.000-07:00

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).

Flight testing of new Paparazzi altitude and airspeed control loops

2009-10-04T15:16:00.000-07:00

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):

Test EagleTree sensors in 3rd party mode

Revert to GPS measurements if any of the sensors fail

Update on airspeed integration in the Paparazzi code

2009-10-02T16:00:00.000-07:00

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:

Aggressive climb mode

Altitude control using barometric sensor

Test airspeed and barometric sensors in 3rd party mode (in the default mode the sensors will output raw values where in the 3rd party mode they will output converted values)

Paparazzi source files for the EagleTree altitude and airspeed sensors

2009-09-07T13:18:00.000-07:00

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).

Connecting the EagleTree airspeed module to Paparazzi

2009-09-06T01:54:00.000-07:00

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.

DIY Drones T3 competition (August)

2009-09-04T13:29:00.000-07:00

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.

EasyStar with Paparazzi autopilot, first AUTO2 flight

2009-08-04T04:48:00.000-07:00

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:

EasyStar airframe with added ailerons

Paparazzi TWOG autopilot (from PPZ UAV)

GPS receiver

IR, horizontal and vertical

PPM encoder (worked great and with excellent support from Chris)

Xbee Pro 2.4GHz modem

KX191 camera

900MHz, 500mW video transmitter

Pan/tilt video pod

Spektrum AR9000 receiver with a remote receiver (total of three receivers)

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.

httpvh://www.youtube.com/watch?v=jD1Llbc0fkw

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.

OSD and Audio Modem Design Files

2009-07-10T15:44:00.000-07:00

Due to multiple requests, I decided to put together what I have and release it as is. As you can see from the video below it works! However there is still work to be done, including cleaning up the design a bit.

OSD and Audio Modem Design Files

OSD Flight Demo

2009-07-10T15:32:00.000-07:00

Following is a demo of the OSD in flight. The data are received from the AttoPilot telemetry port. The AFSK audio telemetry is not yet enabled. Still a few things to improve but it is getting there.

httpvh://www.youtube.com/watch?v=vDj_2fxuBtI

OSD Demo

2009-03-21T07:45:00.000-07:00

The OSD functionality is now operational. A short demo can be seen in the video below. The OSD and audio telemetry functionality is now combined on the same board. I am planning to use this board with the AttoPilot autopilot. I will be now working on my new airframe (Telemaster Electro) and integration with the AttoPilot.

httpvh://www.youtube.com/watch?v=V0n4GLd9Ll8

Telemetry using audio channel of video transmitter

2009-03-11T13:30:00.000-07:00

In all my FPV setups the audio channels remains unused, so I decided to use it for telemetry. The idea is quite simple and can be seen in the block diagram below.

The boxes in orange are the only custom made parts, the rest are existing components. A board with a Propeller chip is used to read the GPS data and send them through the transmitter audio channel. Audio generation with the Propeller can be achieved by using PWM on a single pin and then low pass filtering the output.

The modulation technique used is also quite standard and implemented in only one COG. I decided to use the Bell 202 AFSK modulation, on top of that the AX.25 protocol is implemented. The GPS data are encapsulated into an unnumbered AX.25 frame and send at 1200 bps line speed. Error detection, framing and synchronization is already build in to the AX.25 protocol. This protocol is quite popular and used in HAM radio, the main advantage however is the availability of applications that can be used to receive AX.25 packets. The ground station basically requires no additional hardware, a PC with a sound card is all that is needed. The audio channel of the receiver is connected to the audio input of a PC and an application called AGW Packet Engine is used to demodulate the data. A custom application was finally made to receive the payload (GPS) data and display them.

The following video shows the whole system together. My next step is to use the same board to implement OSD functionality, the complete system will be used to display and downlink the telemetry output from an autopilot I will be soon be experimenting with.

httpvh://www.youtube.com/watch?v=cvzWCTohb1E

IMU stabilizer design files

2009-02-20T12:52:00.000-08:00

Even though the IMU stabilized quadcopter is not yet complete, there have been enough requests for the source code to justify releasing it as it is. Please let me know if you try it out on your design and especially if you make any improvements. As soon as the weather improves around here, I am planning to try the stabilizer on my EasyStar. I will likely have more improvements at this time.

Download the source code from here.

First indoor flight

2009-02-04T13:11:00.000-08:00

httpvh://www.youtube.com/watch?v=TJIntyaSNqM

I was at last able to have the first successful indoor flight! Hover seems to be very stable, with only a slight drift. Small corrections are still needed to keep the quad in one spot, however much less input was needed to hover compared to a helicopter (I am flying a TRex 450).

Development took a bit more effort than I originally anticipated, due to the effect of vibration on the accelerometers. Having four (unbalanced) motors does produce quite a bit of vibration. I had to spend some time trying to understand the vibration and its effect on the accels. Given the constrains I have on the Propeller, I opted for a moving average filter on the accelerometer channels and I noticed a big improvement on the IMU response. The vibration would basically make the roll and pitch output of the Kalman filter drift by up to 15 degrees. With the filters I was able to keep any error below 3-4 degrees. Some more tuning on the filter length and Kalman parameters is possible, however I am quite satisfied with the performance of the IMU stabilizer so far. The results can be seen in the video above, during the flight some small corrections were needed but nothing major.

I would not declare victory just yet, there is still some room for improvement and more testing is needed on outdoor flights (for example the effect of centripetal force during a turn). However I am quite satisfied with the performance of the controller, considering that low cost gyros and accelerometers are used.

As soon as the weather improves I will also try it on my EasyStar. I will post the source code and design files on this blog soon, stay tuned!

Update on IMU controller progress

2009-01-07T10:32:00.000-08:00

httpvh://www.youtube.com/watch?v=IfVrz3Eljck

The IMU development is coming along but a number of modifications had to be made to get it to work more reliably:

The original design was updating both IMU and PID loops every 20 ms. I found that this was not fast enough to react to the fast attitude changes of the Quad. To achieve a faster update rate I had to re-write the IMU code and Kalman filters from scratch to allow them to run at a 5 ms update rate.

The gyro conversion from the raw ADC sample to rad/sec (or deg/sec) was wrong by a factor of two resulting in an error in the short term estimate of the pitch and roll angles (the accels did eventually correct the angle). Fixing the conversion factor considerably improved the the angle response and allowed to tune the Kalman filter to rely on the gyro more than the accels. That results in a much faster IMU response to attitude changes. That can also be seen in the video below. Keep in mind that the artificial horizon is only updated every 100ms through the debug port so there is a noticeable lag in the UI.

The PID loops now run at a 10 ms rate, the motor ESCs are updated at the same rate however I am not sure how often the input is actually read by the ESC. In any case an improvement was seen with the faster update rate.

Some more progress was also done on the Windows application that is used to record and display data from the IMU controller in real-time. The update rate is a bit slow (100 ms) due to the large number of channels that are transmitted through the debug port.

Preliminary flight tests show that a large amount of derivative control is needed in the PID loops to minimize the oscillation. The PID loops were also modified to use the un-biased rates that are calculated by the Kalman filters as the input to the derivative part of the PID loops (rate of change). That allows the loops to quickly react to changes in attitude before the Quad starts oscillating out of control.

The GY401 Heli gyro works pretty well, in heading hold mode it keeps the Quad steady in the yaw axis. There is a slow drift but this is expected since there is no sensor to measure the absolute yaw. A magnetic compass could be added in the future for that purpose.

More work is needed on the tuning of the PID loops and Kalman filters and this is the next step. Preliminary tests show that stable flight is possible with the current setup!

Quadcopter assembly completed

2009-01-06T16:38:00.000-08:00

The Quadcopter assembly has been finally completed. The design is based on the Kquad design as described in the RCGroups thread. There are many different frame designs mentioned in the thread but I went for Rusty's Rev 7 fiberglass frame. It is a bit heavier than the other options but it can take a lot of punishment (which will be needed while testing the IMU based controller!). Of course I am not using the controller that most use in the Kquad since the IMU I am developing will do all of the work. Assembly was very easy, wiring was a bit tricky but it worked out great. The video camera, transmitter, OSD and eLogger will be installed after IMU stabilized flight is achieved.

A number of lessons were learned during assembly and initial flight tests:

Motor spacing plays a big role on stability and yaw control. I found that when the spacing was about 800mm (shaft to shaft) the yaw was nearly impossible to control, also the Quad was impossible to control because any slight change in the motor speed will result in a large change in attitude. The solution was to move the motors in as much as possible for a spacing of 460mm. With that spacing the yaw authority was much better, however yaw became more sensitive to motor alignment so it took a few tries to get the yaw to be stable.

To my surprise, even at the reduced motor spacing it is nearly impossible to control the quad without active IMU stabilization. Especially when the yaw gyro is in heading-hold mode, the changes in motor speed tend to also affect pitch and roll. This is likely due to slight differences in the motor performance and position. My reflexes are not fast enough to manually compensate in time so I was not able to hover more than a foot from the ground.

The tennis balls are too heavy but I will temporary use them until I find something better.

Total weight is 1082 grams (38.2 oz) including the tennis balls (200 grams) but not the battery.

The next step is to work on the controller, tune the PID loops and Kalman filters for IMU stabilized flight. More details in the next post.

Successful bench test

2008-12-06T07:44:00.000-08:00

After some tweaking with the Kalman filter I was able to get a decent response. I also started working on a Windows application that I will use to display IMU data in real time, dump the recording memory and play back recordings. The Artificial Horizon component from Tom's web site came in very handy for the Windows application!

httpvh://www.youtube.com/watch?v=V8YldqttYjg

As you can see from the video the response if pretty good, some more tuning of the Kalman filter parameters is required. I started working on a Matlab model that will help me test adjustments a bit faster (it is also easier to quantify any improvements).

The Quadcopter parts are on order.

IMU board assembled

2008-12-05T16:37:00.000-08:00

The boards have been received and ready for testing. The software is also coming together, I was able to find quite a few objects in the Propeller Object Exchange.

The following COGs are used (COG is a the 32-bit processing unit in the Propeller chip, there are a total of eight available)

[1 COG] Servo output using the Servo32v3 object.

[1 COG[ Servo input using the ServoInput object.

[2 COG] Floating point math using the Float32Full object.

[2 COG] Logger and high speed UART for real-time debugging. This is only used for testing, if more COGs are needed in the future it can be easily disabled.

[1 COG] ADC driver using the MCP3208 object. I had to make quite a few modifications on this one to get it to average samples between IMU updates.

[1 COG] The main loop with the IMU code, Kalman filters, PID loops etc. It executes every 20ms. For the Kalman filter I started with an implementation found in the object exchange but I had to make quite a few modifications to speed it up and get it to work using all three accelerometers.

Schematics and layout completed

2008-12-05T15:58:00.000-08:00

The schematics and layout of the boards has been completed. I decided to use ExpressPCB, they provide the schematics and layout software and their mini-board service is fairly cheap. The mini-board service is limited to a fixed size board of 3.8 x 2.5 inches, so I decided to fit both the IMU and OSD boards in the same fab. I decided to have two separate Propeller chips, one for the IMU and the motor/servo control and the other for the artificial horizon and OSD. They are connected using an I2C bus.

The IMU board consists of the following:

Controller: Spin Stamp board. This board includes 3.3V regulator, boot EEPROM and the Propeller chip. To avoid using an extra regulator for the ADC, IMU and EEPROM, I had to add one jumper wire to the Spin Stamp in order to get the 3.3V out on pin 24. The regulator is rated at 500mA so it can easily handle the load of the complete board. The servos are powered directly from the 5V input to the board.

IMU:The 5 DOF IMU from SparkFun is used, to save some space I was able to fit the ADC right under the IMU. The ADC should also help mechanically support the IMU.

ADC: The 12bit MCP3208 from Microchip is used, the ADC has a standard SPI interface.

Memory: The 24LC256 32KB EEPROM from Microchip. Not much memory but since it will only be used during development I did not want to compromise the size of the board. It should allow to store data for a few minutes.

The OSD is fairly simple and based on the HC-OSD, Terry was kind enough to also supply the Propeller driver code for the OSD. The OSD will communicate with the IMU using an I2C bus, spare pins are also routed to the connector for future expansion.

The layout is completed. The boards could be made a bit smaller but having a bit more space between components made the layout easier.

IMU Stabilized Quadcopter

2008-12-03T15:01:00.000-08:00

This project started when I found out about the 5 DOF IMU from SparkFun. I always wanted to experiment with an IMU and Kalman filters so I decided to build an IMU based flight stabilizer. I also recently got in to FPV and was looking for the next platform after my EasyStar. A Quadcopter was the perfect platform, easy to build, can launch from my back yard and it should be able to carry a decent payload. Also developing the control hardware and software sounded like a nice challenge.

The same IMU stabilizer can also be used to stabilize my EasyStar, however I will first test it on the Quadcopter.

Of course this is not the first project of its kind (Tom's site is worth mentioning) but none of the existing projects was exactly what I wanted to do. So my objectives for this project are:

Develop an IMU stabilization board using the SparkFun IMU, with enough processing power to run the Kalman filters, servo controller, PID loops and data logger.

Tuning PID loops in no fun without a data logger, so enough memory to record a few minutes of data at high speed will be required.

Spare I2C buses for interfacing with peripheral boards and maybe the EagleTree eLogger.

Video transmitter (I already have a 900MHz 500mW system, including a ground station).

Heli gyro for yaw control (the IMU can only be used to control roll and pitch).

EagleTree eLogger with GPS, OSD and altimeter sensor.

Spektrum AR7000 receiver.

A nice to have would be an artificial horizon on the OSD, one approach I am considering is designing an additional OSD that would only be used to generate the artificial horizon. The EagleTree OSD will be used for the display of all other information.

The IMU board will be based on the Propeller chip from Parallax. This device has eight cores and can operate at frequencies up to 80MHz with very little power consumption.