Hello, I have a hexapod robot with 18 servos. Before, I used to split 18 servos into 3 banks of 6 and use a different timer for each (all software). I decided to try to use all 12 PMW pins as hardware and the other 6 servos as software. But it seems that if 12 PMW are used, then there are no free timers available and Project designer complains.I attached the screenshots. I read on forums that admin uses 10 PMW pins and 10 software on his 20 servo robot, so it should be possible? What is wrong here? Thanks

I deleted all old servos straight away. I didn't disable them. It's not working.I tried to modify the generated code to make 3 servo banks, but the servos didn't start. I think there's a hardware reason for this maybe. Anyway, I removed 3 hardware servos and put them in software, so that I have 9 software servos in bank1, 5 hardware servos in bank2 and 4 hardware servos in bank3. This freed up 1 times for all the software driven servos. Maybe if Webbot notices this thread he can clarify.Thanks (〜￣▽￣)〜

Here is the project file. When I open it, I get red triangles next to servo banks

Yep - what you are seeing is as expected. Here's why:-Look at H/W pwm 'bank2' this uses hardware pwm on B7,B6,B5. These are all Timer1 pwm outputs ie OC1C, OC1B, OC1A - where OC1x refers to Timer 1.

Now look at your software PWM 'bank1' by double clicking on it:- you will see the 'Timer' drop down is set to Timer1.

ie you are trying to use Timer1 to do 3 x Hardware PWM on bank2 but then you are also trying to use Timer1 to control software PWM on bank1. It can't do two things at once! Thats why got the triangles.

Your two hardware banks: bank2 and bank3 - use timers 1,3,4 and 5. The 'clock' device uses timer 0.So the only available timer for your software bank1 is Timer 2 - which is only an 8 bit timer and so can't be used.

So to progress:-use timers 3, 4, 5 for 9 x hardware PWM. Keep the clock on an 8 bit timer (0 or 2). and then use the remaining 16 bit timer 1 for software PWM and put remaining servos there. If you need 'more' hardware PWM then I suggest you look into the multiplexer solution by adding an external chip. (probably cheaper than servo controller boards).

An 8 bit timer (0 to 255) will therefore have: 256 * (1 / 2.5) = about 10 different positions it can be set to - which isn't very useful ie 5 positions clockwise and 5 positions anti-clockwise. Or for most servos represents a swing of about 25% per increment

Numbers are approximate, and will vary per servo, but hopefully explains the thinking as to why 8 bit timers aren't great for servo h/w pwm.

Thanks a lot Webbot, that clarifies a lot and that's what I actually had to use to overcome the problem. It's just on forums there were messages where people claimed to be using >9 hardware pwm servos.

Some quick questions, does it matter how the servos are divided into banks? Should I make as few banks as possible or as many as possible? Is it good to keep the number of servos in each bank equal?

You can get >9 hardware pwm servos if you can afford to dedicate all 16 bit timers - ie 4 timers = 12 hardware pwm servos. But since you've got more than 12 servos then you are using s/w pwm and hence need to grab one of the timers back. As for other folk claiming a different 'mix' then I can't vouch for how they did that - so if Admin claims more then perhaps ask him what he did.

As for 'banks'.... Hardware pwm doesn't really matter - the only advantage 'banks' give you is that you can instruct all servos in a bank at once rather than one at a time. For s/w pwm then each bank has its own timer - so if you put 'too many' servos into the bank then the total period may go over 20ms and the servos go floppy. But then you have to sacrifice another timer for another s/w bank.

So the rough equation is: a hardware pwm can drive 3 servos per timer (unless its an ATMega168 which may only have two channels per timer). A software pwm can drive, say, 8 servos per timer but does take up more CPU utilization. I say 'say' because it depends on the min/max pulse time of your servos. Software pwm will always have more judder because its using s/w to time the required pulse - but if you have other hardware thats causing lots of interrupts like encoders then this timing may not be exact - hence judder. Hardware pwm is great in that there is no judder and you get maximum torque.

Hence it also depends on the kind of bot your are building. For example: a biped probably needs h/w pwm for the legs as you dont want judder and you dont want floppiness. Whereas arms, or head movement, may just be cosmetic and non-load bearing and so are better candidates for s/w pwm.

Never built a hexapod - but if there are 'key' legs that provide the most thrust then use hardware pwm for those. Other ancillary legs may not need to be as exact.

So quick answer is 'you need to see what works for you!'.

Final comment: if servo control is critical and your robot is also having to do lots of complex maths (inverse kinematics say) then you may find the amount of CPU time that is lost to controlling s/w pwm slows down all of your main loop. In which case you really need to think about a slave board (or several) that just controls the servos. Either an available commercial one - or just build your own using an ATMega168/328 + WebbotLib using, say, the multiplex driver that is part of WebbotLib and allows one timer channel to control 8 servos. You could probably build one on matrix board for a few dollars so long as you have a hardware program (AVRISP MKII etc) to blow the code onto the chip!

High precision timing without hardware PWM is totally possible, if you can live with disabling interrupts for 2 milliseconds every 20 milliseconds. Note that disabled interrupts may make a serial port drop bytes, for example. I2C is better, as it contains built-in flow control in the hardware protocol.

First, order all your outputs from "shortest pulse" to "longest pulse."

On a typical Atmega, setting the timer to run 4 ticks per microsecond is common, so if your input time is in "microseconds" then your "tick" values have to be multiplied by 4 (and thus you'll have 0.25 microsecond resolution.)

@jwatte Yep WebbotLib has supported software PWM for years. By software PWM I mean anything that has a timer interrupt/delay that uses software - ie yours and WebbotLib. And the problem is always that you either have to disable all other interrupts at some point to keep the PWM correct or you keep them enabled and end up with potentially 'jittering' servos. You mention that your solution may loose the odd uart byte due to disabling interrupts - but what about an encoder generating 1000s of interrupts per second - can't afford to loose them! So my comment was really that: pure hardware PWM is 'exact no matter how many other things/interrupts youve got going on' whereas any PWM that has ANY software involved will always be flakey (unless all your program is doing is controlling servos - in which case buy/build a slave servo controller board)

Putting some code into a $2.50 AVR CPU is a lot cheaper than buying a $25 servo controller board, though! And then you can talk to that thing using I2C from your other CPU.

Absolutely - but why not build your own servo board ie $2.50 AVR CPU using WebbotLib to handle I2C and servos and nothing else - as suggested in the last paragraph of my earlier post? By having such a slave board then more timers become available for use by WebbotLib. My original comment was more to do with if you expect a single cpu to do lots of PWM + I2C devices + UARTS + Encoders + your main code etc etc then things may work - but not perfectly. Can't put a gallon in a pint glass! Its very easy to write each thing in isolation - but very difficult to do everything simultaneously.