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.