Need some robot advice: Hardware software setup

[klims]

Hi guys,

I'm hoping to get some feedback on my current biped robot configuration and possible upgraded configuration. This is going to be tricky to explain so if I'm not clear just let me know  

Currently I am running the Axon I, the Maestro 24 channel serial servo controller, gyro and accelerometer. The way my hardware and software is set up is that my Axon is sending out servo commands to the serial servo controller while grabbing gyro and accelerometer values that it is using to 'adjust' the servo commands it is sending out. The problem I am having is that in order to get any kind of accurate compensation I need to be refreshing the gyro and accel readings VERY quickly.

Here is my thought: the gyro is really the only thing I need to update really quickly, so I could possibly run it straight into the Maestro Servo Controller and write a script to compensate for gyro readings. I would have a layer of abstraction between my 'brain' and my body which would free the brain up to do more complex things. I feel as this might also allow me the most flexibility for future brain upgrades.

My question: has anyone got experience in Maestro Scripting? I'm reading about it and really don't want to learn another language if it's not going to get me where I want to go.

I guess my end goal would be to have a brain capable of making high level computations and decisions, and then passing this information off to a lower level to deal with the requests that would organise it into movements or whatever.

Feel free to rip my idea apart. Give me a reason not to redesign my robot yet again


thanks guys.

[garrettg84]

My question: has anyone got experience in Maestro Scripting? I'm reading about it and really don't want to learn another language if it's not going to get me where I want to go.

Never heard of it.

I guess my end goal would be to have a brain capable of making high level computations and decisions, and then passing this information off to a lower level to deal with the requests that would organise it into movements or whatever.

That's how your brain works, it sounds like a good idea to me. Would you be adding additional hardware to handle this? A simple (and cheap) Atmel chip could do this interfacing and you wouldn't need to learn another programming/scripting language.

[Crunchy Theory]

I've never heard of Maestro either, and I'm always drawn more toward industry standards for ease of expansion (good ol' C).

As for brains...

My approach is to use an ARM processor for the higher functions and an Atmel mcu for motor functions/some data collection. The draw of using an ARM processor is that you could use Linux as a common environment between your development host PC and target, thereby taking advantage of the free vision, speech processing, etc. software that's already available for Linux.

Depends on how much you want to build/design yourself, though. I personally try to use as much off-the-shelf-but-reasonably-priced stuff as possible (I think Admin hsa said he favors this as well) and then redesign components that I'm interested in doing myself.

[garrettg84]

To add to that ARM processor comment - 100% agree. There are actually some pretty inexpensive single board computers (panda, beagleboard, etc.) that run full blown distros of linux. These can be pretty amazing little devices to add to a bot. Though, I have always wanted to see a cluster of atmel chips just for giggles. I doubt it would be very practical to have much more than a few, but the nerd in me just wants to see racks of them humming away.

[klims]

Thanks for the input guys!

That is my plan. I really want a micro pc to do high level brain functions, maybe even some image processing.

The reason I went for the Pololu Maestro servo controller was because I was having troubles accurately controlling my servos. I would get jitters when I was controlling them using my Axon. http://www.societyofrobots.com/robotforum/index.php?topic=11331.0
Now that I think of it I don't think I ever tried using webbotlib to see if the jitters went away.

Can anyone tell me from experience if they think I will be able to software PWM 24 servos with good enough accuracy not to get jitters? If so maybe I can make my own servo controller like the Maestro since that's all it is anyway (a microcontroller I mean). Then I could easily make it a lower level system that will take orders from my brain while being able to compensate on the fly using gyro and accel readings.

[garrettg84]

If you did it in assembly instead of C (depending on your libraries), you MIGHT be able to do it. 24 sounds a bit high, but it should be possible. It may also depend on the relative accuracy you need for the PWM. Higher resolution on pulse width may get tricky with that many pins to control. I would set it up with a timer and simply set every single pin to high/low as necessary, wait for the given pulse width tick to pass and then repeat. The biggest trick is to complete every operation EVERY loop of your code, make sure that no loop cycle does any less or more work than another loop cycle - this will eliminate jitter entirely but may also reduce resolution. The setting of pins in the arduino libraries takes a ridiculous number of clock cycles, in the order of 10 or 20 times more clock cycles than the equivalent raw asm instruct doing the same operation.

[klims]

It has to be possible because the Pololu Maestro does it and runs scripts too. I'm not sure if it does it using a combination of hardware and software though... I'll have to investigate.

I'm really not keen on writing in assembly if there is another option.

I know it's a tall order, but has anyone ever heard of a micro with 24 channel hardware pwm?

[joe61]

It has to be possible because the Pololu Maestro does it and runs scripts too. I'm not sure if it does it using a combination of hardware and software though... I'll have to investigate.

I'm really not keen on writing in assembly if there is another option.

I know it's a tall order, but has anyone ever heard of a micro with 24 channel hardware pwm?

Maybe take a look at the Resources tab in the Maestro product page: http://www.pololu.com/catalog/product/1357/resources

The User's Guide describes the scripting language and answers other questions.

Joe

[hopslink]

Can anyone tell me from experience if they think I will be able to software PWM 24 servos with good enough accuracy not to get jitters?

Anyone with microcontroller experience will recommend you don't bother using an all software solution. Anybody with experience of driving 24 servos purely in software is the type of masochist you don't want to take advice from. Micro's have hardware timers for these types of aplications.

...I'm not sure if it does it using a combination of hardware and software though

Almost certainly it is a combination, with hardware timers generating interrupts and software selecting the correct channels to change and reloading the timer interrupt value for the next servo channel. This is the way that the Webbotlib servo library works...

I'm really not keen on writing in assembly if there is another option.

There is almost always another option. The strategy outlined above can deliver repeatable timing to the microsecond, which is likely more accuracy then a hobby servo can match.

I know it's a tall order, but has anyone ever heard of a micro with 24 channel hardware pwm?

Not off the top of my head, though they are probably available. You could use 2 micros since 12 16-bit hardware PWM channels are commonly available. Before you do that try Webbotlib - you may be fine with no extra outlay.   

[waltr]

Be careful of the specs if you expect to use the hardware PWM modules in u-controllers. Most are designed to output a 0 to 100% duty cycle with at most 10 bits of resolution. These do not work well for RC hobby Servos since the duty cycle is 5 to 10%.

It works out better to use two hardware timers, one for period and the second for the pulse width and ISRs. Most small u-controllers can easily do 8 servos this way and maybe more if you are good at coding.

Along the lines of some of the above posts: Use a higher end processor (ARM) for the central processing then over serial links (UART, SPI, I2C), send commands to u-controllers that do the timing to the servos. This way the central processor does get tied up with the 'real time' signals and can run higher level algorithms. The servos need a pulse every 20msec but in most cases the servo position doesn't need to change that often so the central processor only sends position data when the position needs to change.

[klims]

The User's Guide describes the scripting language and answers other questions.

Yep thanks mate I have seen this and had a read of the scripting language before posting here. My question about the scripting language was more asking if anyone had experience and could give me a yes or no to this approach based on what I needed.

Just for reference, the Pololu Maestro 24 Channel uses the PIC18F4550. It's a pretty impressive little unit.

[klims]

Thanks for the tips guys!

Be careful of the specs if you expect to use the hardware PWM modules in u-controllers. Most are designed to output a 0 to 100% duty cycle with at most 10 bits of resolution. These do not work well for RC hobby Servos since the duty cycle is 5 to 10%.

Very very very interesting point... I had not thought of this.
At the best I get a 16 bit pwm: wiki tells me most servos send out 1ms - 2ms pulse in a 20ms window, meaning my resolution will be scaled down by 20 right?
So 16-bit: (2^16)/20 = 3276.8 servo steps in the usable range. GREAT
Or 10-bit: (2^10)/20 = 51.2 steps. NOT GREAT
Or 8-bit: (2^8)/20 = 12.8 steps. BAD


I think I have come up with a game plan:
-I will test webbotlib v2 with my axon at controlling as many servos and sensors as I can find (or it can support) and see how stable it is.
-if webbotlib and the ATMega can handle it I make my own servo controller based on this chip and library.
-if not I learn to program in the Pololu scripting language.

Along the lines of some of the above posts: Use a higher end processor (ARM) for the central processing then over serial links (UART, SPI, I2C), send commands to u-controllers that do the timing to the servos.

Exactly what I was thinking

[klims]

I have found that webbotlib cannot control a bunch of servos accurately enough to prevent jitters. While the jitters are less than with Admin's libraries, they are still noticeable and annoying. Apparently it's due to interrupts.
http://www.societyofrobots.com/robotforum/index.php?topic=11331

I really don't want to make the move to the Pololu scripting language so I'm looking into the possibility of making a piggyback board for the Pololu that uses a ATmega so I can keep webbotlib and still use the webbotlib gaitDesigner and gaitRunner stuff.

Any suggestions would be appreciated, otherwise I will report back when I get some results!