OpenServo.com

[eric_lmi]

400k i2c, is that the max bus speed a mega168 can do?
need some faster solution


another thinking, is that possible:
using openservo/mega168 as a ADC, pass potentiometer data to external DSP/faster MCU/CPU
using external faster DSP do the PID or more advanced control method.
then pass the PWM back to openservo

[ginge]

Hi Eric,

[eric_lmi]

Hi Barry

1) 400k is pretty fast for 1-5 openservo
I am using up to 30 openservo. all openservo need ideally move together. one i2c bus at 400k is not fast enough.
if send command to 30 openservo one by one, there is a time gap between the first one and last one. which big enough to be identified by human eyes

i am using 4 i2c bus at this moment.

parallel bus? All ideas based on software modify. if changing hardware, i prefer using a small FPGA chip or DSP, or maybe new PICdsp will get better speed.

2) OpenServo is a pretty good idea for distributed motor control
flexibility is a big achievable advantage for OpenServo (we can't expect Openservo achieve High performance)

the reason for using AVR Build in ADC is, plug and play, every openservo board is a small individual module with ADC, also can be self controled.
easy replace and basic self control can make the whole system more robust, even i had a main control board faulty, the motor itself can take out and provide a basic control until main control board turn back

and i can use 1 or 10 or 30 motors in my system without any new hardware design.

3) the idea to make it using external control method is give openservo a option to achieve some complex control by using external control unit.
for example,multi motor synchronous moving.

will it be hard to manage by current hardware?
what is the current PID loop frequency?
i think, it will not be lots works to modify it. just don't use internal PID update fucntion. get the PWM value from external by I2C? and refresh timer. will I2C faster enough to do this?


Eric

[ginge]

Hi Eric,

you have some good points, let me see if I can work though these

1) 30 OpenServos is quite a lot. I have had 50 running before, but I did have 5 i2c adapters (well 5x i2c hardware in FPGA) so 10 on each bus.

If you need to have all of the servos on one bus, you could look at this thread

http://openservo.org/Forums/viewtopic.php?t=660

I agree that there are problems with having to write to each servo one after the other. Another member of the OpenServo community came up with the idea of broadcast packets. I have the firmware patch to support this syncronised start movement if it would help.

Parallel bus would be very easy to implement if you have 8 spare pins on the openservo. If you are serious about this method, I would be willing to help port the firmware, but you will need a new PCB design

2) Agreed!

3) for the syncronous movement, see above.
the PID is updated every 10ms, so you see 100 updates per second.

[bren]

Hi

I've been having the idea for the synchronous. The first time you communicate with the servo's you can send all the position curves and then send a start signal. This will work as long as you send the next position values to all the servo's before they have finished the previous movement.

The other way could be to have a tick/command e.g. sending 0xFFFF could synchronous them.

I have a question waist I wait for my board to turn up. Ginge you say that the i2c is fast, but how fast? If you want to update 5 servo's and get some value back like force, what the refresh time.

Thanks Bren

[ginge]

Hi Bren,

Yeah syncronised movement is very useful. As I mentioned above I wrote a patch to implement this exactly as you described using a broadcast packet. You load all of the servos with the position, and then send a broadcast packet to all servos at once with the "go" command.

The tick command is an interesting idea. How would that work in practice?

As for how fast... I can get around about 100-120 samples per second from the servo using my high speed Diolan interface.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[bren]

Hi there

This might be a rubbish idea as it would require a lot of work and a complete write of the code BUT.

Looking at how my system works at the moment I have a big Array of positions and speeds that's the routine for a move (biped robot). I then add these with sensors values using a PID and transmit them to each servo's using PWM.

I could use this same setup and just send the value over the i2c but then there's the time problem and speed problems.

So my ideas this:

You could off load the Array to the servo's e.g. they have a list of moves for the next 5 seconds (already done using the curves). The master sender can then send a tick that tells all the servo's to go to the next position depending on the speed Or you could send the speed value and the system used this input as the command to go to the next position.

And lastly you could transmit the sensor reading down the i2c and use these sensor values to manipulate the position values using PID. You would have to tune this value for each servo but it would be worth it.

[bren]

Cont ...

To clarify.

My system at the moment is a 18 servo biped.

The sensors at the moment are in the chest and are a compass, 3 axis accelerometer and a 2 axis gyro.

The position table:

Position1, Speed1 | position2 , speed2 | .......
Servo1 25 15 | 243 25 | ......
Servo2 231 15 | 24 25 | ......

So my Position changes for each servo but the speed stays the same.

The psuedo code for my current controller:

for (i = 0, i < speed, i++)
servo1 = position[servo1]*Gyro*Acc*Comp*SpeedAdjust
.......

theres some more code that takes care of the speed Adjust. this is just the diffence in the current position and the wanted position.

What I want my Openservo system to be.

Have the main controller send these messages to the openservo.

position
clear
sersor1,sersor2......
speed

You should be able to send position values and servo store so that they can be executed one after the other. sending the clear signal will clear the queue. When you send a speed signal the servo should execute the next move.

So in theory the master controller only has to send the speed signal and in between update the position values. This would give you a fast synchronize system.

So to take advantage of the distributed design of the system it makes no sense for my main controller to make the adjustment for the sensor to each servo that's 18 servo position need adjusting when each servo can make the adjustment using the sensor value.

So to make this work your main controller would read in the sensor values turn them into a value that could be used in the servo code and globally transmit. This would save a big bandwidth in my system.

I hope you get the main idea that I'm trying to get over. I will come back and reread it in an hour and see if it still makes sense to me

bren

[ginge]

Hi Bren,

I think I can see what you are getting at here.

I think that there would be minimal code changes needed in the OpenServo, if any at all.

The OpenServo can store an array of curves that would match each of your movement commands. Each curve is a combination of position and speed as it is, the speed defined by the gradient of the curve.

In theory all you should need to do is compute the new positions and curves for your accelerometer and gyro sensors, and then queue them out to the OpenServo. You can send very small curves (or trapezoids) to the servo that last ms each, allowing you to react to any over balance issues quickly. With the motion engine inside the OpenServo you can clear the array of curves at any point and start again, all with a single command.

I am working on something similar with a Biped, and I am achieving motion using sine like curves. Each segment of the biped is sent a continuous (but different) sine wave that moves everything in one nice coordinated movement. This makes the servo move smoothly from one position to another, and by manipulating these sine waves, it allows me to control any balance issues that arise.

To make sure all of the curves are syncronised, I send the new position commands as the old ones are being executed. There is a window of 100ms for each of my movements before things start to go horribly wrong, which I can update any movements. This is more than enough time to manipulate the new curve, and send it without things going out of sync.
You could think of each curve manipulation like a PID transformation. As the sensors detect drift, the curve is altered by the PID before being sent.


I assume this could work for your system too?

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[eric_lmi]

i use openservo for biped as well

what i did before is very similar to bren's position array idea. store position inside as a checking table

but i gave up the old idea, the reason is how can you get the position data? and it is works for slow movement only, you have to always looking for a static balance position and then move to another static position.

by my testing, another biped robot tip, faster joint movement(almost full speed) with high frequency is stable than low speed.

the main movement unstable factors are starting to move, stop (include hit on ground or stop joint movement by motor)

what i do now: store a internal curve function in openservo, which calculate only 3 key movemnet points with different accelerator. start from 0, then increase accelerator untill the first key point, full speed (not real full speed, i mean the highest speed at the first key point) until second key point, then decrease accelerator for a period time, until stop.

i have a balance control board with high speed CPU, collect sensor data and adjust curve function parameters for next step. i got a function to send servos a urgent adjust signal, which will make PID loop output few empty PWM period or few high PWM output. that will not change too much moving speed, but changed force/torque. so need a high speed i2c to make sure if i want sent 20 servo together, they will get this signal at this same time(ideally).

this method works with high stepping speed, but not smooth low speed movement. so i am thinking using central syncronise control every PID loop.

[eric_lmi]

Barry

looks you are doing Electronic engineer?
i am not a EE, need a little help.

how can i get -3.3v from +5v or +3.3 without DC to DC chip. need a simple solution for my sensor ref voltage.


Eric

[linuxguy]

[eric_lmi]

what i need is a negative 3.3v, sorry i am wrong, negatice 2.5v

[linuxguy]

[robotjay]

Hi all.

Mike mentioned that ADC sampling and position updating occurs based on each servo's internal clock timing. Is it possible to synch all of the CPU clocks on the bus based on the SCL timing?

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."