OSD and Audio Modem Design Files

July 10th, 2009

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

July 10th, 2009

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.

OSD Demo

March 21st, 2009

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.

Telemetry using audio channel of video transmitter

March 11th, 2009

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.

AFSK Modem Block Diagram

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.

IMU stabilizer design files

February 20th, 2009

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

February 4th, 2009

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

January 7th, 2009

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

January 7th, 2009

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.

img_1

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.

img_2

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

December 6th, 2008

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!

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

December 6th, 2008

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.