Author
Topic: openservo (Read 4126 times)

so i just took the time to read up on this project:http://www.openservo.com/it looks really interesting for anyone who needs precise servo controll and feedback of the servos position.

you basically replace a standard servos circuit board with a custom one that allows you to control and monitor a servos position over the i2c bus.you'd also be able to do away with a dedicated servo controller or PWM routines on your main controller.

to be honest, i think that you dont need to know perfect angle information for a biped, and that some type of global sensor might be more effective.

the advantage would come when you are training your creation to walk.you could just move it's limbs manualy and record the positions the servos move to (as well as the speed they move at) then just play back the movements.

Dunk, what you are suggesting is nice in theory, but doesn't work well in reality. Most bipeds have 10 or 12 servos combined in the two legs (the humanoid I'm working on has 12, and my MicroRaptor has 14). Manually getting that many servos to move all at the same time in a coordinated fashion is basically impossible. I gave up, and switched to doing the equivalent of keyframe animation.

hmmm my plan was to precalculate the required angles by hand of each servo for each motion - knowing weight distribution and motion dynamics apriori - then write some simplified algebraic equations for the ucontroller to use with sensor updates from gyros and accelerometers. (i want to attempt a dynamic walker)

i was also thinking of putting springs in the legs - something crazy hard to control without precalculating what will happen . . .

I figure this is where my mechanical engineer skills can shine

but of course I have never done this before so it might not work . . . its still a thought in progress . . .

I don't know much about openservo, but I know a reasonable amount about the Bioloid bus. The Bioloid bus runs at 1.0 Mbps, and you can achieve some pretty decent update rates at that speed for 20-25 servos.

I2C in its normal form runs at 100 kHz, and in fast mode 400 kHz. There is also, as far as I know, a "really fast" mode, which runs at 1.0 Mbps.

I'm the creator of the OpenServo and I thought I would drop in some comments regarding what we are up to. I believe the major innovation of the OpenServo will be that we have implemented motion algorithms within the servo based on hermite curves -- the same mathematical constructs commonly used in 3D animation applications such as Maya to describe complex joint rotations. This feature allows a user to send a precise position/velocity profile for the servo to follow using only a very small amount of the I2C bus bandwidth. For instance, this video shows a gripper controlled by the OpenServo following a non-trivial position/velocity profile that is represented in about 40 bytes of data. When you can describe 50 to 5000 milliseconds of complex motor motion in such a highly compressed format the speed of the bus becomes much less of a concern.

The key for bipeds is that with curve based motion a controller can operate at a much higher level with the servos under its command. The controller can be working out which motion profiles are appropriate to keep the robot dynamically balanced and the duty of controlling the motors to follow the motion profiles is pushed out to the intelligent servos. Through distributed processing such an approach better leverages the fact that a biped robot with 16 joints has the equivalent of 128 MIPS of computation power at its disposal.

Over time I do expect the OpenServo to branch out beyond the I2C bus. For instance, in projects unrelated to the OpenServo I've been working on UARTs connected to CAN transceivers at the physical layer operating at 500K to 1M baud with very high noise immunity . This approach or the full CAN protocol might one day make its way into the OpenServo. The bus technology is actually a small part of the servo and swapping I2C for some other high-speed bus would not be difficult.

The OpenServo is definitely still a work in progress and some aspects of the servo are more polished than others, but hopefully over time it will become a completely open digital servo that rivals the features found in very high cost proprietary servos. Perhaps the best thing is that if there is a feature that is missing or not implemented to your liking you are free to modify the servo to meet your specific requirements.

Anyway, I'll get off my soap box. Hopefully this describes a bit of where we are going with the OpenServo and despite the use of a slower bus, why we may be able to ultimately get smoother, more accurate motions in our robots than other approaches over servo control.

OpenServo is a very interesting project for developers who want to move beyond existing servo technology to bus interfaces and accurate force/position feedback.

I'm interested in understanding the limitations of the current design. If I understand correctly, you're using a 20Hz update rate, with 40 bytes of data per update, which computes as 6.4kbits / servo / second. So with a 100kHz I2C bus, your limit is 15 servos, right ?

What update rate are you using for your balancing robot ? 20Hz seems like it might be a bit too slow.

My balancing 'bot is not really related to the OpenServo. The balance 'bot is an experiment in building a robot from RoboBricks2 modules designed by a fellow I know in my local robotics club. More about RoboBricks2 modules can be found here. I built a few of my own RoboBricks2 modules using AVR ATmega168 MCUs which is the same in the OpenServo, but that is really the only thing they have in common.

> If I understand correctly, you're using a 20Hz update rate, with 40 bytes of data per update, > which computes as 6.4kbits / servo / second. So with a 100kHz I2C bus, your limit is 15 servos, right ?

Actually, the motion in the video requires 40 byte total! Not 40 bytes per position update.

Let me try to clarify how the OpenServo is utilizing curve data for control. Basically, a curve segment describes the motion in terms of position and velocity of a servo joint over time. A good general introduction to cubic curves and their importance in describing keyframe animation [http://graphics.ucsd.edu/courses/cse169_w07/CSE169_08.pdf]here[/url]. If you create a robot that you want to follow animations paths using normal servos, you generally will have to have your controller interpret the curve data for each motor into discrete position values and then have the controller pass those values to the servo in real-time every 50mS or faster for at least a 20 Hz update rate. This would be done by either updating a standard RC pulse signal to the servo or perhaps serial data being sent to the servo to command it to a new position. Either way, the operations involved to keep the servo updated with position information becomes a significant overhead when the controller is managing 12 to 18 servos. If you choose, you can operate the OpenServo using this method of control, but it doesn't offer significant advantage over other servos in this respect.

However, with the OpenServo, the controller can instead transfer the raw curve data to the OpenServo itself. Each curve segment requires about 8 bytes of data and can describe motion as brief as 50 ms or as long as 5000 ms or more depending on the nature of the motion. The OpenServo then locally interprets the curve description into discrete position/velocity values and controls the motion of the motor at a 100Hz rate. You can create degenerate cases where each curve segment is 50 ms in length and requires a lot of I/O to transfer, but more typically joint motions are gentle sinusiodial curves with spans of 100s to 1000s of milliseconds. By just transferring the curve data that describes complex servo motion over over a longer span of time instead of discrete positions every 50ms an enormous amount of bus bandwidth can be saved.