13 replies to this topic

[Richard]

Hi all, I am new to the Netduino way but a very experienced programmer at all levels. While I originally bought the device for remote sensing, I find myself doing what everyone seems to do at some point, playing with robotics :-) Anyway, I am looking for ways to drive at many servos as I have GPIO ports. As far as I can tell, we are limited to only 4 ports that support PWM on the standard board. It occurs to me, however, that I may be able to get around this by creating a 100kHz timer interrupt (to get 10uS resolution) and a lookup table to brute force the signal generation. As far as I can see, this will not be possible in C# since the interrupt servicing in the CLR is too slow and timer resolution is far too poor. I am thinking the only approach will be some sort of C/ASM driver with a few friendly C# classes for servo control. Is this overkill? Assuming that I can come up with an efficient way of modulating the GPIOs in my interrupt handler, do you think that the CPU will have enough grunt left over for control loops and other work? As far as I can tell, all I have to do is keep a an array of desired pulse widths (between 125 and 175 for a 10uS clock). At the beginning of every 25ms cycle (assuming 400Hz update) a counter is zeroed and all GPIOs are sent high. Each interrupt, the counter is incremented and compared with each of the individual pulse widths. When the counter exceeds the pulse width for a given servo, the GPIO is driven low. When all ports are low, the interrupt could be disabled for 2.5ms (to reduce CPU load) before starting the cycle again. So, am I on the right track or is there a better way to do this? Am I fooling myself that the Netduino can handle this as well as doing real work in the foreground? Would I be better off firing up the old AVR development board and knocking up a dedicated AVR chip that takes the traditional 3 byte commands across SPI and is otherwise dedicated to the control loop? Thanks in advance people, I look forward to comments and/or critisisms :-) Richard.

[Crispin]

While not really answering your question on brute force pwm off a digital pin, why not get a servo shield? IIRC, there is a 16 channel one floating around which works well with Arduino and no reason why it should not work with Netduino. Google Arduino servo shield.

[Chris Seto]

Yeah, your best bet is to use one of those UART driven servo drivers. I can't find the one right now, but basically it takes a serial sentence and moves the target servo accordingly. Very nice for hexapods and things.

[Chris Seto]

Psst: http://www.microfram...ervo_Controller

[Richard]

The servo shield is basically a variation on option 2 I guess. The AVRs that are being used in those shields do not have 16 PWM outputs so they must be generating the appropriate waveforms on-chip, unless those little SMDs are SPI PWM generators or something. There are a bunch of PIC based boards that generate their own waveforms as well. I guess I was interested in pushing the existing hardware as far as it can be pushed rather than adding peripherals.

[hari]

...It occurs to me, however, that I may be able to get around this by creating a 100kHz timer interrupt (to get 10uS resolution) and a lookup table to brute force the signal generation.

I wonder if that's what the guys at GHI did. They use OutputCompare to drive Servos on any digital pin. I would love to have something like that on the Netduino also.

[Chris Walker]

Hari, We have a "software PWM" feature planned for a future firmware update. It would basically use a timer interrupt in the background to allow you to run one or two additional PWM channels. This would also give Netduino 100% pinout compatibility with Arduino shields. Chris

[hari]

Hari,

We have a "software PWM" feature planned for a future firmware update. It would basically use a timer interrupt in the background to allow you to run one or two additional PWM channels. This would also give Netduino 100% pinout compatibility with Arduino shields.

Chris

Woohoo! Awesome!!! Thanks Chris!

[Crispin]

The daddy of them all: http://www.coolcompo...products_id=546 64 servos Shield your eyes from the price.

[Richard]

Hari,

We have a "software PWM" feature planned for a future firmware update. It would basically use a timer interrupt in the background to allow you to run one or two additional PWM channels. This would also give Netduino 100% pinout compatibility with Arduino shields.

Chris

Will this be limited to 1 or 2 extras or will it allow you to run pulse accurate PWM for every digital pin?

[Chris Walker]

Will this be limited to 1 or 2 extras or will it allow you to run pulse accurate PWM for every digital pin?

Good point. The initial theory is to enable 1 or 2 pins (specifically the two PWM pins where we don't have true hardware PWM--but you could do it on any analog/digital pin). The good news and bad news here is that software PWM requires a lot of processor time. If you had a slow PWM clock we might be able to enable PWM on more pins--but we'll have to see how testing goes on that... As it is, two super-fast software PWM will slow down your app significantly.

Chris

[Richard]

Would this depend on whether you were doing full phase accurate PWM? For servos though, we don't actually really care about that sort of thing. All we care about is 1uS accuracy on the pulse width, delay between pulses could be pretty random and from 2.5ms to 20ms. Is there any chance of getting some advance look at the code you are putting together for this?

[Chris Seto]

Servos don't care about terribly accurate PPM frames. The PPM wave can be a bit sloppy, and as long as they sort of average out to the target angle, the servo won't jitter too much. for high precision you do need to use a real (RE: hardware) PWM solution.

RC electric speed controllers are a different matter. Screw up the pulse going into one of those and you can easily have a dangerous situation. They are very sensitive.

[Chris Walker]

Would this depend on whether you were doing full phase accurate PWM? For servos though, we don't actually really care about that sort of thing. All we care about is 1uS accuracy on the pulse width, delay between pulses could be pretty random and from 2.5ms to 20ms. Is there any chance of getting some advance look at the code you are putting together for this?

The software PWM is scheduled for phase 3. Right now we're in Phase 2 (getting the PWM code done for the v4.1.1 beta). But there's no reason we can't share the code when we get there...

The basic operation will be a timer in the background which executes every # clock cycles--and compares a counter to determine when to raise/lower the pin's output.

Does that give you a good idea of the direction?