SMALL - espritmodel.com SMALL - Telemetry SMALL - Radio
Reply
Thread Tools
Old Apr 19, 2010, 06:07 PM
Registered User
rancho san antonio, CA
Joined Sep 2005
775 Posts
Discussion
Atmel AVR programming for ppm signals.

I need some advice from those who are experienced at AVR programming.

Now that 3-axis gyros are available, I'm thinking of building a flybarless
controller for small helis. I'm wondering if an Atmega 8
will have enough processing power.

Since this is a fairly complicated DIY project, I'm thinking of breaking it up
into smaller problems solve them one by one:

First, I'll need to take 5 channels of PPM signals from a receiver and
determine the pulse width of each channel. I'm thinking of sending the
5 channels directly into 5 input ports of the AVR, at the same time,
use 5 diodes to sum these 5 signals to create a train of five pulses
and feed the ICP pin. The ICP (input capture pin) will timestamp
the rising and falling edge of each pulse (via an interrupt handler),
and from that I can determine the pulse width of each channel.
The 5 input ports are simply to allow me to determine which channel
the pulse belongs to. Question: is there a better/more efficient
way of evaluating the pulse width? I don't like having to use 5 diodes
and using 6 pins of the AVR.

Second, I need to generate PPM signals to drive the servos. What is
a good way to generate 4 PPM signals with standard PPM pulse width
(1 to 2mS), at a frame rate of the incoming 5 channels? Can the PWM
wave form generator of the chip be used for this? Will it give enough
resolution (ideally I want the pulse width to have 1 or 2 microseconds
of resolution)? I need to have the wave sent to 4 different channels.

Thanks for any suggestion!
mayday1 is offline Find More Posts by mayday1
Reply With Quote
Sign up now
to remove ads between posts
Old Apr 19, 2010, 06:21 PM
Guru Apprentice
osfcman's Avatar
Stockholm, Sweden
Joined Apr 2010
6 Posts
The AVR can easily do this, however, you should look at the mega48/mega88/mega168 devices, these are never and have more features.
You can use ICP to receive a MUX'ed version of the pulses. No need to use 5 separate pins. As there are approx. 20 mS between each pulse train, you use that to determine which pulse is which.
Use a timer for the PWM out. Not in PWM mode, but just a regular timer that in combination with a little software sequences it's output to the 4 output pins.
Piece of cake, all in a days work.
osfcman is offline Find More Posts by osfcman
Reply With Quote
Old Apr 19, 2010, 06:35 PM
Registered User
rancho san antonio, CA
Joined Sep 2005
775 Posts
I was worried that if one of the input channels is disconnected or
glitched, I'll get confused as to which pulse is from which channel
if I'm simply counting the pulses. But your suggestion of knowing
the nominal time separation of each pulse should allow me to
unambiguously determine the pulse ordering.

Don't quite understand your suggestion of generating the PWM pulse
but not in PWM mode. Can you give me more details?

Thanks a bunch!

PS: I'm planning on using atmega88 (have a through-hole version
sitting around that I can use the breadboard to wire it up to
prototype.
mayday1 is offline Find More Posts by mayday1
Reply With Quote
Old Apr 19, 2010, 07:09 PM
Guru Apprentice
osfcman's Avatar
Stockholm, Sweden
Joined Apr 2010
6 Posts
Using the "built-in" PWM would require 4 channels, I can't remember if the '88 have this, but you would also need to trick around with prescalers and stuff to make the pulses right.
Futhermore, there would be no delay between each pulse like on the output from a receiver. Some servos don't care, other NEED at least 10mS pause.
So, you do it in software instead.
Set the 16-bit timer to run at 1uS ticks (prescaler 1/8, if you're running at 8MHz), then use the OCR to set a "timeout" for your pulse (or pause). This timeout is your servo time, for instance 1500, for a 1.5mS pulse. When the OCR interrupt triggers, set or reset the appropriate output pin(s), and setup the next timeout in the OCR. Repeat for each output channel.
When you've done all servos, set a timeout of 16000 to get a "receiver-like" delay between pulse trains.

This give out 1uS resolution for the output channels (approx 1200 steps). Whether you'll get that accuracy from your receiver is a another matter.
osfcman is offline Find More Posts by osfcman
Reply With Quote
Old Apr 19, 2010, 08:08 PM
"Simplify, then add lightness"
Raleigh,NC
Joined Nov 2000
2,701 Posts
Quote:
First, I'll need to take 5 channels of PPM signals from a receiver and
determine the pulse width of each channel. I'm thinking of sending the
5 channels directly into 5 input ports of the AVR, at the same time,
use 5 diodes to sum these 5 signals to create a train of five pulses
and feed the ICP pin.
Summing 5 outputs from a standard receiver using diodes most likely would not generate a pulse train. On a standard receiver with a shift register decoder there is no space between channel outputs. The same clock that sets channel1 low also sets channel2 high. With an intelligent receiver with an onboard micro, there is no guarantee that only one channel will be output at the same time. I have done an 8 input PPM decoder on an AVR by using the pin change to interrupt when any of the 8 inputs changed. To minimize time inside the interrupt I simply read the input port, and saved it along with the count from a timer into a queue. In the background I read from the queue and determined which pins had changed at which time. Was able to get resolutions less than 1 uS.

If you are not set on the AVR, you might look into the PIC24FJ16. It has 5 input capture modules and 5 timer output modules. It is about the same price as the Mega8 and is much more powerful. It has both hardware multiply and divide. I was an AVR bigot and absolutely hated the 8-bit PICs (still do) and am not too impressed with Microchips support. However, the 16-bit PICs have so much more going for them that I am using them in most places I would have used an ATMega.
jeffs555 is offline Find More Posts by jeffs555
Reply With Quote
Old Apr 19, 2010, 11:15 PM
Registered User
rancho san antonio, CA
Joined Sep 2005
775 Posts
I think I understand osfcman's description of doing the PPM output in
software.

I agree that the PIC chip sounds a lot more appropriate, but I already
have the AVRisp programmer and gcc, ..etc installed, so I'll try to
use the AVR even though it means a lot more kludgy work.

If the pulses of the incoming channels overlap or are very close, I can
see I'll need to use the pin change interrupt instead of ICP, but of course
you give up timing accuracy.

I guess I'll have to do a back of envelop calculation of having the 5 channels
in an 4 channels out all in software and interrupt driven, what sort of
timing accuracy I can expect. On top of that, the AVR will need to
read the gyro values at fixed time intervals via I2C, and do some calculation as well.
mayday1 is offline Find More Posts by mayday1
Reply With Quote
Old Apr 20, 2010, 04:08 AM
Registered User
Solihull, England
Joined Jun 2004
962 Posts
For many IMU stabilised systems a special receiver or a modified standard receiver is used that delivers the PPM signal as a single stream - this can usually be extracted quite easily before the receiver decoder. This then requires a single input and timer to decode every channel within the micro.

I would sketch out all the hardware you will need before committing to a type of processor as you will probably need a three axis accelerometer as well as gyros.

Peter
Peter Seddon is online now Find More Posts by Peter Seddon
Reply With Quote
Old Apr 20, 2010, 04:42 AM
Guru Apprentice
osfcman's Avatar
Stockholm, Sweden
Joined Apr 2010
6 Posts
jefs555 is right that you might have a problem with a muxed input as he describe.
However, the mega88 can interrupt on a level change on the input pins, so it's easy to set up interrupt functions that store and evaluate the timer on each flank of the input signal, should you chose to do it that way.
osfcman is offline Find More Posts by osfcman
Reply With Quote
Old Apr 22, 2010, 12:23 AM
Registered User
rancho san antonio, CA
Joined Sep 2005
775 Posts
Thanks guys.

Spent the last couple of days playing around with Eagle and got
the schematics done. It'll be at atmega88 + a 3-axis gyro,
a few dip switches for rudder/aileron/elevator rotation direction,
and a couple of LEDs to indicate rudder/cyclic with neutral input,
gyro thinks it is holding position, and servos trying to play catch up.
mayday1 is offline Find More Posts by mayday1
Reply With Quote
Old Apr 22, 2010, 09:17 AM
Master of turbine fire
sycorax's Avatar
Germany, land of inventors
Joined Mar 2005
208 Posts
Quote:
use 5 diodes to sum these 5 signals to create a train of five pulses
and feed the ICP pin.
This will not work at all on 2.4 GHz technology any more. A lot of 2.4 GHz receivers don't wait for one servo channel output to be finished before applying the next. They control all servos at almost the same time.

Another thing to consider in your design is this .. and it's important:
ATMEL processors recognize a "high" level at 0.6 times Vcc . Using a stabilized 5V as Vcc , you will not be reliable compatible to Futaba RC equipment, since Futaba uses 3V maximum output level on their receivers ( most 6014FS only have 2.7V ). 0.6 times 5V = 3V .. not much tolerance.
I made an DIY AVR cuircuit for model lightning public which runs on 5V and several people using Futaba equipment reported problems. Using a lower Vcc resolved the problem.

Basically, I think there are two ways to measure the servo pulses:
Run a single timer, every servo is connected to it's own input pin and an edge interrupt is used to store the timers values. The difference between start and end reflects the servo position. If there's no servo pulse for a defined time, the timer is reset to 0 and starts again.
As an alternative, you could use a satellite receiver providing a PPM signal. In this setup, the servo positions are lined up correctly and you get one channel after the other. And you only need one input pin.
sycorax is offline Find More Posts by sycorax
Reply With Quote
Old Apr 24, 2010, 01:20 PM
Hang on, turbulence ahead
Heli Hacker's Avatar
St. Louis
Joined Dec 2007
534 Posts
Quote:
Originally Posted by mayday1 View Post
... It'll be at atmega88 + a 3-axis gyro,
....
I highly recommend the Propeller chip. No interrupts to mess with, and there is plenty of code in their Object Exchange library for doing PWM in or out. As well as code for ADC interface to a gyro chip.

I used one to build this:

http://www.rcgroups.com/forums/showthread.php?t=1233263

I am in no way associated with Parallax. I am just a happy customer.
Heli Hacker is offline Find More Posts by Heli Hacker
Reply With Quote
Old Jun 08, 2010, 08:53 PM
Registered User
rancho san antonio, CA
Joined Sep 2005
775 Posts
I haven't worked on this until yesterday. Yesterday I breadboarded a atmega88
the way I described in my original post, and wrote a little piece of code
to see if I could decode the PPM signals. I couldn't seem to get the input
capture to work despite trying different SW settings (atmel docs
aren't very clear on what registers need to be programmed for various
modes of op).

After half a day of scratching my head I finally hooked up a scope and discovered
that the atmega88 running at 5.5V (from a small wall-wart) didn't consistently
see the 3V output from the Spektrum AR6100E as logic high when the signal
goes through a diode. Lowering the atmega VCC to 5V made it solid (it
needs to see 0.6Vcc min as logic high).

For servo output I'm using the 16bit timer and set the output compare registers
so that I get an interrupt when it is time to set the servo to logic low.

It seems to work pretty well with very little CPU usage. I set a pin to logic
high whenever I enter an interrupt handler, and clear it when I exit
the handler, the scope shows very low duty cycle on that pin (<1%).

This is with just 3 input channels and 3 output channels wired up, but
I expect the PPM input and output code to consume negligible amount
of CPU, so the 8MHz atmega88 should have lots of cycles to handle
the gyro signals and computing what to do.
mayday1 is offline Find More Posts by mayday1
Reply With Quote
Old Jun 08, 2010, 09:03 PM
Registered User
rancho san antonio, CA
Joined Sep 2005
775 Posts
Quote:
Originally Posted by sycorax View Post
This will not work at all on 2.4 GHz technology any more. A lot of 2.4 GHz receivers don't wait for one servo channel output to be finished before applying the next. They control all servos at almost the same time.

Another thing to consider in your design is this .. and it's important:
ATMEL processors recognize a "high" level at 0.6 times Vcc . Using a stabilized 5V as Vcc , you will not be reliable compatible to Futaba RC equipment, since Futaba uses 3V maximum output level on their receivers ( most 6014FS only have 2.7V ). 0.6 times 5V = 3V .. not much tolerance.
I made an DIY AVR cuircuit for model lightning public which runs on 5V and several people using Futaba equipment reported problems. Using a lower Vcc resolved the problem.

Basically, I think there are two ways to measure the servo pulses:
Run a single timer, every servo is connected to it's own input pin and an edge interrupt is used to store the timers values. The difference between start and end reflects the servo position. If there's no servo pulse for a defined time, the timer is reset to 0 and starts again.
As an alternative, you could use a satellite receiver providing a PPM signal. In this setup, the servo positions are lined up correctly and you get one channel after the other. And you only need one input pin.
Wow, if only I've read your post before debugging yesterday. The voltage
problem caused me half a day of frustration. I kept thinking I didn't
program the atmega properly and tried lots of combination that also
failed. In my case I'm using a Spektrum receiver (which I think internally
uses a 3.3V voltage regulator for its logic).

I'm using essential your first method to decode the PPM pulses.
mayday1 is offline Find More Posts by mayday1
Reply With Quote
Old Jun 09, 2010, 08:08 AM
Registered User
UK
Joined May 2007
3,204 Posts
mayday1 - one more thing to keep in your mind: Avrora project.

If you have some Java experience you can always set up an virtual environment and code most of the stuff without even programming the chip itself! With Avrora it should be easy to:

a) simulate PPM input from RX and read/scan/log PPM output from your code. If you have enough time - making an Java component that will visually simulate servo would be even better
b) use joystick inputs (using same lib as Heli X for input - if you're interested I can find out exactly what is it called) to create/simular PPM output from the RX. If not - easy Swing component or just ordinary Swing sliders can do that

With it you would be able to simulate signal route from Tx to your code to servos... WOW... If I continue like that... . I am sure I can't do anything until mid August... but if you're still interested PM me and I'll be more than happy to help you with all of it!
clicky is offline Find More Posts by clicky
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Gauging Interest: 4 Channel ESC for Brushless Motors (RS232/PWM/I2C + Atmel AVR's!) Mrbmw99 Power Systems 0 Mar 10, 2010 03:36 PM
Link For Sale - Atmel AVR Programming Tools tune by tito DIY Electronics 2 Mar 23, 2009 02:39 AM
For Sale Atmel AVR Programming Tools tune by tito Non R/C Items (FS/W) 2 Mar 23, 2009 02:37 AM
Atmel AVR programming bigandy DIY Electronics 13 Oct 05, 2006 09:46 AM
AVR Atmel for UAV andyg UAV - Unmanned Aerial Vehicles 1 May 17, 2005 06:48 PM