HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Jan 07, 2014, 01:39 PM
Just me..
cgroen's Avatar
Denmark (Jylland)
Joined Nov 2004
82 Posts
Discussion
Multiple PWM outputs/driving 16 or 18 servos

Hello guys,
I'm currently tinkering with a small project where I need 16 or 18 PWM outputs that can drive servos.

In an ideal world I would have 18 seperate PWM channels (driven from SBUS) from my CPU (ARM Cortex) but I only have a few available

There are several ways of making the PWM outputs. One method is to use the few PWM outputs and feed them thru seperate multiplexers. This would then mean that each output is driven in turn and that the leading edge of each PWM channel would be offset (all channels will not start at the same time but would be delayed with a fixed amount of time like 3 mS or so).

Another method is to use a dedicated PWM chip (PCA9685 f.ex) but this will limit the resolution of the PWM signal (something like 3 uS or so). I have made a mockup with this solution, and as far as I can "feel" the servos moves perfectly nice and smooth (driving JR8911s). However, this resolution is below the 11 bit resolution offered by Futaba and that irritates me

So, my question is if any of you have some real life experience with either the staggering of individual PWM signals and/or the "low" resolution ?
I guess if a swashplate was driven with the staggered outputs it would not look nice....

Any thoughts ?
cgroen is offline Find More Posts by cgroen
Last edited by cgroen; Jun 06, 2014 at 05:02 AM.
Reply With Quote
Sign up now
to remove ads between posts
Old Jan 07, 2014, 01:56 PM
"MAYONNAISE"
Acetronics's Avatar
Le Treport, France
Joined Jun 2004
1,397 Posts
http://www.adafruit.com/products/815
Acetronics is offline Find More Posts by Acetronics
Last edited by Acetronics; Jan 07, 2014 at 01:59 PM. Reason: .
Reply With Quote
Old Jan 07, 2014, 02:01 PM
Just me..
cgroen's Avatar
Denmark (Jylland)
Joined Nov 2004
82 Posts
Yes, it's 12 bits, but you have to have the delay between the pulses from the PCA9685 (say 20 mS) so this reduces the resolution of the "on time" to around 3 uS (so around 500 steps for full deflection more or less)
cgroen is offline Find More Posts by cgroen
Reply With Quote
Old Jan 08, 2014, 12:57 AM
We want... Information!
Bruce Abbott's Avatar
Hastings, New Zealand
Joined Jan 2001
5,179 Posts
Quote:
Originally Posted by cgroen View Post
In an idea world I would have 18 seperate PWM channels (driven from SBUS) from my CPU (ARM Cortex) but I only have a few available
If you were using a better CPU then you wouldn't have that problem.

Quote:
There are several ways of making the PWM outputs. One method is to use the few PWM outputs and feed them thru seperate multiplexers. This would then mean that each output is driven in turn and that the leading edge of each PWM channel would be offset (all channels will not start at the same time but would be delayed with a fixed amount of time like 3 mS or so).
Conventional RC receivers send servo pulses sequentially. Devices with multiple servo inputs may actually require that the signals be sequential, and will get confused if they overlap. Another reason to prefer sequential pulses with analog servos is that they draw current pulses in sync with the servo pulse. Staggering the pulses reduces peak current draw from the power supply.

The down side of sending 18 servo pulses sequentially is that the frame rate must be lower than normal (~40mS for max 2.2ms per channel). To get around this you could split the outputs up into several groups. With 6 PWM generators you could have group 1 = ch1~6, group 2 = ch7~12, group 3 = ch13~18. The maximum delay between any two channels would then be only 4.4ms. For critical applications (eg. ccpm swashplate) simply select the required channels from a single group.

Quote:
So, my question is if any of you have some real life experience with either the staggering of individual PWM signals and/or the "low" resolution ?
I guess if a swashplate was driven with the staggered outputs it would not look nice....
I have found a resolution of 3us to be more than smooth enough (I developed a ppm decoder with 6us resolution, which produces barely noticeable jitter), and sequential output has not been a problem for me.

I did see a delay between elevon outputs when using my Futaba 9CAP with a Spektrum DM8 rf module. I suspect this was due to the ppm capture and channel remapping creating a big delay between the aileron and elevator channels. Even though it was very noticeable in a control surface test, I could not detect it in flight.

Some people complain of 'low' resolution because they have reduced the servo travel in order to cut down control surface movement. This may show up deficiencies in the transmitter's math routines (particularly in older radios) as well as magnifying the effect of servo dead-band and control linkage slop. A better way to reduce sensitivity is to adjust linkages for the desired deflection with full servo travel, then apply expo to linearize control surface movement.

Some radios only have an 8 bit A/D converter, and so can only detect about 250 stick positions. Is this enough? I tried moving the throttle stick on my 9CAP by the smallest amounts that I could physically reproduce, and only managed 150 separate positions. From this I determined that my fingers are by far the lowest resolution component in the system.
Bruce Abbott is offline Find More Posts by Bruce Abbott
Reply With Quote
Old Jan 08, 2014, 01:13 AM
User
Colorado
Joined Oct 2004
1,424 Posts
Quote:
Originally Posted by Bruce Abbott View Post
If you were using a better CPU then you wouldn't have that problem.
Such as ???
rmteo is offline Find More Posts by rmteo
Reply With Quote
Old Jan 08, 2014, 01:35 AM
Registered User
salvix's Avatar
United States, CA, San Jose
Joined Apr 2009
93 Posts
Try the Pololu Mini Maestro at pololu.com.
salvix is offline Find More Posts by salvix
Reply With Quote
Old Jan 08, 2014, 02:18 AM
Just me..
cgroen's Avatar
Denmark (Jylland)
Joined Nov 2004
82 Posts
Thanks for input Bruce!
You kind of confirms some of my thoughts, especially that the 3 uS resolution should be enough! I also thought about how many "steps" my fingers could produce and I have a hard time beliving that 8 bit (or maybe 9) should be noticeable in flight! I would prefer the external PWM generator as it simplifies things more in the CPU. However, your point about the staggering would be positive in sense of current draw is also a very valid point!

I'm doing a device that will give me 18 PWM outputs from Futaba SBUS2.
It has two SBUS2 inputs giving redundancy using 2 receivers
The device has two battery inputs, each of these is monitored for voltage, current and ma/H consumed and fed as telemetry back to the transmitter (emulating two F1678 sensors). I'm still trying to decide if I should go with the simple "diode type" connection of the batteries (each are fed thru 15 Amp diodes to a common point that drives the servos etc) or if it should contain actual voltage regulators (would prefer not to go the "regulator" route).
The device also logs all activity on the SBUS2 to SD card and drives a CAN Bus with info (flight log, GPS etc) and a USB connection for update of firmware/configuration (it will also update firmware from the SDcard)

Regarding the CPU used, well it could always be better and more powerfull but its a mix of many things that made me select this specific type. I'm using a 32 bit Cortex-M3, LPC1758, running at 100 MHz (512 KByte Flash and 64 KByte of SRAM with USB, CAN, 4 UARTs, MPU and "some more")

I would rather use the external PWM generator as it removes the "stress" in the main processor for the timing critical stuff, the CPU is running the two SBUS2 channels, datalog, CAN bus and a bunch of other things (and an RTOS).

The protype is running and I'm ready for the second spin of my board, but the PWM generating stuff made me wonder if I should do something else than what I'm doing in the prototype (PCA9685) or not...

I have uploaded a small video of my prototype device (sorry for bad quality) and a couple of pictures, one of the device and one of my CANLCD module that I use in other projects (http://tinyurl.com/lo63cpp)

Video:
Test of SBUS2 to PWM encoder (0 min 49 sec)

.
.
cgroen is offline Find More Posts by cgroen
Last edited by cgroen; Jan 08, 2014 at 02:51 AM.
Reply With Quote
Old Jan 08, 2014, 05:00 AM
Just me..
cgroen's Avatar
Denmark (Jylland)
Joined Nov 2004
82 Posts
Quote:
Originally Posted by Bruce Abbott View Post

Conventional RC receivers send servo pulses sequentially. Devices with multiple servo inputs may actually require that the signals be sequential, and will get confused if they overlap. Another reason to prefer sequential pulses with analog servos is that they draw current pulses in sync with the servo pulse. Staggering the pulses reduces peak current draw from the power supply.



BTW, not all RC receivers send the channels out staggered ( I would guess only "old" receivers did ?), at least my Futaba R7008SB receivers starts the pulses at the exact same time:
cgroen is offline Find More Posts by cgroen
Reply With Quote
Old Jan 08, 2014, 06:22 AM
"MAYONNAISE"
Acetronics's Avatar
Le Treport, France
Joined Jun 2004
1,397 Posts
Hi, CGroen

I'm always a bit surprised when I read about so much servos to be driven independently
look, I bet in those servos, you have landing gear servos, animations and so on ...

just make sub-sytems that drive i.e. landing gears + doors ... pilot animation, or ...

I think you understand what I mean.

so, you only have a little number of functions to drive, that will have their own brains to take care of all that ...

That's how I've made with "show" models, including scale championship models ( understand I design and build that for friends, as championships are not at all my pleasure ! )

was just a simplifying idea ...

Alain
Acetronics is offline Find More Posts by Acetronics
Reply With Quote
Old Jan 08, 2014, 06:28 AM
Just me..
cgroen's Avatar
Denmark (Jylland)
Joined Nov 2004
82 Posts
Hi Alain,
yes you are right, it is a lot of servos
But I would like to make something that is not limited (at least too much) from the start. I want to make something to fill the gap between the simple receivers and the very complex "powerboxes" that are available (of which none? does have any telemetry when talking SBUS2). For now it is just a "benchtop project" whether it will ever "fly" is another question (it will in anycase be flown in "small models" first to iron out the errors/problems before fitting it to a $10K jet/large model!)
cgroen is offline Find More Posts by cgroen
Reply With Quote
Old Jan 08, 2014, 06:42 AM
We want... Information!
Bruce Abbott's Avatar
Hastings, New Zealand
Joined Jan 2001
5,179 Posts
Quote:
Originally Posted by cgroen View Post
I would rather use the external PWM generator as it removes the "stress" in the main processor for the timing critical stuff,
Good idea. You will probably need a buffer chip to isolate the ARM from the servo ports anyway - might as well make it do some work!

Quote:
wonder if I should do something else than what I'm doing in the prototype (PCA9685) or not...
The PCA9685 only has 12 bit PWM, so it's limited to 5us resolution at 20ms frame rate, and it only has 16 channels but you want 18? You might consider using a cheap 8 or 16 bit MCU with 5V compliant outputs, and send the channel data to it via IIC. Since it only has one job to do, it could easily 'bit-bang' 18 servo outputs with 1us resolution.
Bruce Abbott is offline Find More Posts by Bruce Abbott
Reply With Quote
Old Jan 08, 2014, 06:50 AM
Just me..
cgroen's Avatar
Denmark (Jylland)
Joined Nov 2004
82 Posts
Bruce,
you are right about the "external" chip! I have also thought about using a small CPU driving the PWM outputs directly but I would rather try to avoid that if possible at all (more coding to do and maintain...although it probably would be "program and forget" type of thing..I'll give that an extra thought though!)

You are right about the 16 channels, currently I use the PCA device to drive the first 16 channels and then I use two built in PWM generators in the CPU to drive the last two channels (ch17 and ch18) (the PCA and the two buffers for ch17 and ch18 are driving the servo output signal pins with 5V thru limiting resistors)

The code I have running right now gives me approx 3.63 uS in resolution on the 16 channels from the PCA9685 device.
I know it is very subjective, but when I compare the movement of two JR8911 servos, one driven directly by the receiver and one driven by my board (which gets the SBUS2 from the same receiver the first servo is driven from) I honestly can not "feel" any difference at all. If it is like this "in flight" I don't know!
cgroen is offline Find More Posts by cgroen
Reply With Quote
Old Jan 09, 2014, 09:55 AM
Just me..
cgroen's Avatar
Denmark (Jylland)
Joined Nov 2004
82 Posts
I took a quick decission, the PCA9685 can be driven either by it's internal 25MHz oscillator (I'm using that in my first prototype) or by an external (up to 50 MHz). The next prototype of the board will include a external oscillator, this should bring the resolution to around 1.5 uS for the PWM outputs. This also make the pulses more accurate as the internal oscillator is not the most precise....
Thanks for all the inputs!
cgroen is offline Find More Posts by cgroen
Reply With Quote
Old Jan 09, 2014, 08:57 PM
Registered User
United States, ID
Joined Sep 2011
417 Posts
Quote:
Originally Posted by cgroen View Post
I took a quick decission, the PCA9685 can be driven either by it's internal 25MHz oscillator (I'm using that in my first prototype) or by an external (up to 50 MHz). The next prototype of the board will include a external oscillator, this should bring the resolution to around 1.5 uS for the PWM outputs. This also make the pulses more accurate as the internal oscillator is not the most precise....
I don't follow that. How does the osc. speed affect the resolution?

The problem is that the PCA9685 only has 12-bits of resolution. That 12-bits is across the base PWM frequency.

So the problem is that a 50 Hz PWM signal is 20ms long, but uses only 1ms of information.

12-bits = 4095 values over 20 ms.
4095/20 = 205 positions, or approx. 8-bit resolution.

I don't think changing the osc speed is going to do anything. If you increase the base PWM frequency you can get higher resolution.
100 Hz = 10ms period. = 4095 values
4095/10 = 410 values/positions.

I haven't looked at that chip in awhile, but I don't think the osc speed matters that much as to what frequencies you can choose. If you go with 100 Hz you'll probably have to use digital servos.

I'd probably try using the chip in a more sophisticated manner. You might be able to set the frequency high, deliver your high resolution pulse, then switch it to 50 Hz and set it to zero to deliver the dead time, then repeat.

Alternately you might be able to deliver your pulse at high frequency and high resolution, then turn the outputs off for the dead time.

In both of those cases you'll probably have to lock the clock to the processor or you'll get noise and broken pulses, etc.. If you have a spare pin you'd be best off driving the PCA clock from the processor or sharing an osc. source.

You're not going to see any advantage from a crystal. Internal oscs. are plenty accurate. The only time you'd need an external one is if you're trying to time things over billions of cycles, like with a clock.


-Jake
jakestew is offline Find More Posts by jakestew
Reply With Quote
Old Jan 09, 2014, 10:58 PM
Just me..
cgroen's Avatar
Denmark (Jylland)
Joined Nov 2004
82 Posts
Hi Jack,
thanks for your input!
You are right, the higher frequency will not give a higher resolution! It is as you say, the difference between "off and on" that sets the resolution. However I will try and experiment driving the outputs low in the "off period" and use the higher frequency to give an advantage in resolution (raise the update rate to 100 or higher during the on period) just as you describe. I don't know if its going to work or not, I added the external osc just in case that it would be needed (I can omit it and still use the internal if not needed). Regarding the internal oscillator, I'm not sure how that is across multiple chips (I would like to have two board have the same PWM "on time" with the same register values, don't know what the difference is in internal osc freq across different chips..)

Maybe it is an idea to connect one of the PWM outputs from the PCA device to an edge triggered interrupt pin on the CPU and use this pin to start a 3 mSec (approx) timer. Then I would know when to set the outputs off (using the OE input to the PCA device), start the time again so it would fire at the correct point (a little before the PCA PWM outputs will go high) and bring OE low again to enable the outputs. In theory this should work...?

EDIT:
Right now I'm running 66 Hz giving an resolution of 66Hz/4096 = 3.699 uSec. If I raise the frequency to 300 Hz I will get 300Hz/4096 = 0.813 uSec resolution. Not bad!
(would have to adjust some of the times to make sure that I can enable/disable the OE output to the PCA at the correct time etc)
cgroen is offline Find More Posts by cgroen
Last edited by cgroen; Jan 09, 2014 at 11:43 PM.
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Totally clueless newbie - can I gang multiple motors together to drive single shaft. stratobee Electric Motor Design and Construction 19 Dec 17, 2013 07:03 AM
Discussion Help!!! NAZA PWM outputs are not consistent at hover gwfalcon Multirotor Talk 8 Oct 05, 2013 03:02 AM
Wanted skywalker 18 or 16 Sultan.alali Aircraft - Electric - Airplanes (FS/W) 0 Sep 29, 2013 04:50 PM
Discussion Driving 4 PWM outputs with PIC MCU dvsvkimo DIY Electronics 1 Mar 13, 2009 11:32 PM
Discussion PIC PWM output and servo driving... meteor DIY Electronics 18 Aug 10, 2006 10:28 PM