Bioloid dance routine and the value of speed control

[limor]

Robotis just uploaded a bunch of dance routines that are available for download and experimentation.
http://www.robotis.com/xe/download_en/69693

AX12 servos and for that matter ALL servos except for those flashed with altenative firmware such as Morpheus, libbioloid or Openservo or the new Dynamixel top end servos.. don't have real speed control.

What that means is that the speed of rotation depends on the fluctuation of available electric current . as the battery dissipates, the speed decreases.

This is usually not important for short gaits in the use cases of walking or fighting but it is critical when executing a dance routine. As you can see from these dance routines, the robots loose their sync even though they are running the exact same sequence. (btw: this was also the case in the famous robonova and robobuilder sync dance videos uploaded in the past)

phpBB [media]

http://www.robotis.com/xe/guide02_ko/42938

phpBB [media]

(wrong download link)

phpBB [media]

http://www.robotis.com/xe/guide02_ko/42931

phpBB [media]

http://www.robotis.com/xe/guide02_ko/42928

http://cafe.naver.com/jooyarobot.cafe?i ... icleid=109
(slow connection)
http://www.robotis.com/xe/guide02_ko/24687

[i-Bot]

Hi Limor,

I am not convinced that the servo software is the major cause the sync problem.

Can you show some video of speed controlled servos dancing ?

[Fritzoid]

Honestly guys I don't see any long-term sync problem at all. What I do see is normal variation between different servos. That and the fact that the Bioloid on the left keeps shifting its orientation.

Also, the synchronization is pretty good during the long smooth movements but it is not so good when the movements are jerky and fast.

[limor]

Sorry, Don't have a dance sequence with speed control
I wish i had time to do a motion editor for the Morpheus firmware.

We have been working the past week on a minute long dance sequence with the Bioloid GP for a special event, and there are mixed opinions about the relationship between battery level and keeping in sync with the music.

AX servos dynamixel firmware does best effort at speed control probably by driving the servo through small intermediate positions. This is different than PD speed control. For lower speeds (ex: 50% PWM), PD can do a good job at maintaining speed when the battery level varies even when the external torque on the servo varies. (we did some tests with the Morpheus firmware, check actuated.wordpress.com).
The AX hardly poses the same resistance when blocking the rotation with your fingers as it moves from one position to another, as when it is holding a target position. I guess this is because they don't vary the PWM % if speed is not kept.

So I'm guessing that given the limited amount of battery current available for all the servos, if a couple of them are momentarily stuck and saturate the current, the rest will suffer and therefore loose motion repeatability.

In fact for a dance routine the ideal servo control paradigm would not be fixed speed, instead it would look something like:
Go from angle A to B within X exactly milliseconds, using approximate acceleration curve G
(the acceleration curve is for making non-jerky movements but the first priority is to reach B exactly after X milliseconds)

[PaulL]

... there are mixed opinions about the relationship between battery level and keeping in sync with the music.

This all depends on how motion control is designed. If you increment positions over time based on some duration (what I'm doing in my efforts), speed is derived based on position and time, even to the point where a "method" of getting from a start position to an end position over a period of time can be mathematically defined (I built some simple accel / decel code for this). Using position and time will leave battery levels to control only torque, which is as I believe it should be.

In fact for a dance routine the ideal servo control paradigm would not be fixed speed, instead it would look something like:
Go from angle A to B within X exactly milliseconds, using approximate acceleration curve G
(the acceleration curve is for making non-jerky movements but the first priority is to reach B exactly after X milliseconds)

EXACTLY! The typical approach to speed is to indicate speed and position. This says nothing of time or accel / decel and so on. I FIRMLY believe that the proper paradigm should be positions and duration, leaving accel / decel to be done at a higher control level, not at the servo itself. How COULD you synchronize 16+ servos that all have "a mind of their own"? I actually think that using a position / duration approach makes more sense NOT just for dance moves, but for ALL motion.

Accel / Decel code should just calculate literal motion values based on positions and time. This lets you choose the METHOD of motion (accel, accel/decel, decel, straight linear interpolation) separately. Further, with a decent reference timebase (I use RDTSC in my code), timing itself (such as looped position updates) becomes less of an issue, and even a multithreaded operating system like Windows can be coaxed into delivering fluid, seemingly uninterrupted motion at <=4mS intervals!

Torque means strength, batteries provide power, more current, more torque, more strength. Not all motion scenarios require full torque, so we then have an opportunity to reduce servo power (including idle current!) based on the needs of a given set of motions. Power management starts to become more useful.

The Positions and Duration paradigm also can be scaled easily - for a given set of motions, reduce duration by 50% to move twice as fast. Why move faster? Why move slower? Now we have an easy system whereby acceleration and deceleration approaches remain consistent. Want to dance to the beat of music? Just adjust your durations based on a volume meter peak, and you can even speed up and slow down the music and keep the desired behavior!

I not only agree, THIS is what I'm CODING! I've written a bit about these things on the Roboard Experience thread, as well.

Slight side note - How do we humans deal with these aspects of motion? I think we humans just evaluate "I need to be at X at Y point in time", irrelevant of speed - speed is a blank that gets filled in later.

Take Care,
Paul

PS - If one uses the defining characteristics of motion in our robots as duration and position, the ability to "blend" moves starts to come into play - for example a 50/50 blend of walking turn left and walking turn right would yield a straight walk - but nobody walks straight! This introduces a proportional steering mechanism! HOW COOL IS THAT?

[limor]

Hi Paul

I like your enthusiasm!
If you can create some kind of motion profile editor it will be a great way to test all these theories.
check this out
http://openservo.com/moin.cgi/Utilities


I agree with you about position and duration. but there are are several ways of defining position/duration. the servo should essentially go through a fluid path interpolating between a set of "waypoints"+timestamps.
Scenario1: the servo moves between the waypoints and can do what he wants as long as he gets to the waypoint on time.
Scenario2: same as scenario1 but in addition he traverses each waypoint at a given speed!


btw: moving several servos in sync is what CNC machines do at great precision. (The CNC world has an ancient control language for this called G-code.). I'm about to engage in modifying a low cost mill called MF70 to make it into a CNC. and it is quite frustrating to discover that no one on the net has used RC servos with modified firmware to control the XYZ axises. everyone seems to use these *@#$ steppers that require amplifier boards, controller boards and parallel ports on the PC .. whereas using servos seems like a good idea but if no one is doing it then i'm probably wrong.

[i-Bot]

Limor wrote:

.. it is quite frustrating to discover that no one on the net has used RC servos with modified firmware to control the XYZ axises. everyone seems to use these *@#$ steppers that require amplifier boards, controller boards and parallel ports on the PC

Steppers are low cost and have 360 degree resolution wihout needing encoders, making them ideal using simple mechanics for low cost CNC. Reprap Ramps or Gen 6 are neat drivers for steppers.

[/code]

[limor]

yes. ok. but..
They weight a tonne, they have loads of inertia (so you need to build the CNC out of deplated uranium with titanium anti-backlash couplers to ensure it is consistently stable) and even though they are cheap, once you add the extra electronics required to operate them, they are no longer cheap. There's also no position feedback. the CNC is flying blind. you can sometime see the cnc's and 3d printers missing a step and you then need to restart the 30 minute object creation process.

so about 360deg feedback. there's some new China trend that looks very promising.
http://www.hobbyking.com/hobbyking/stor ... duct=14836

http://www.google.com/search?q=site:lta ... 25&bih=688

magnetic induction high torque servos.
imagine taking these and replacing the controller with some derivative of openservo.

[i-Bot]

The steppers are heavy, but for a typical solid milling platform, not disproportionately.

Steppers are normally directly connected to the lead or ball screws, so the backlash is derived from these.

DC or AC Servos suffer from exactly the same problems, there is no absolute position feedback, only from the encoder on the motor. You still have to manage the backlash in the lead or ball screw

I have used Maxon EPOS controllers with their brushless motors and they do easily outperform steppers, but at twenty times the price (600UKP per axis compared to 30UKP). They even sound like performance motors compared to the annoying buzz of steppers. BUT, they still sometimes drop encoder steps !

If you can find 360deg servos with similar performance at low cost, there will be great interest.

[PaulL]

I like your enthusiasm!

Thanks! I try! Some things I get fired up about, robotics is one of them! It's my entire life's learning and interests all rolled into one hobby!

If you can create some kind of motion profile editor it will be a great way to test all these theories.

Regarding motion profile editor - yes, I will likely have some form of graphical editor at some point. Regarding theories - I have already done testing on my theories! I have run a few servos at once (though, updating all PWM outs on the Roboard) with accel / decel, but the servos weren't in my bot, it was just horns moving - not much to see. You should know, your post has refocused my efforts a bit. I realized, I post a lot about theories, and haven't gone so far as to get my testing to a "full up" demonstrable level (walking around w/ accel / decel using my .Net Roboard code, etc). I also was not making as much progress on my control engine as I would have liked. That said, I've been working towards exactly that. I've put the side-projects aside, and have been focusing purely on the control engine and getting to a state where I can do a video to demonstrate motion. It's coming, I assure you!

Re open servo editor - Yup, that's what I have in mind, an editor very much like that one. It gets tricky with fixed accel / decel, as all you can alter is whether to use accel or decel, and duration and end point, but I've not written off the ability to do interpolation for curve smoothing (would be something like a large dataset to smooth a sharp transition).

At some point, I may do a full RN-1 to Open Servo conversion, but that's a possibly down the road kind of thing.

I agree with you about position and duration. but there are are several ways of defining position/duration. the servo should essentially go through a fluid path interpolating between a set of "waypoints"+timestamps.
Scenario1: the servo moves between the waypoints and can do what he wants as long as he gets to the waypoint on time.
Scenario2: same as scenario1 but in addition he traverses each waypoint at a given speed!

My plan is to stick to the intent of Scenario 1, but in my approach, a given speed can be specified in calling for "linear interpolation" of motion which introduces no accel / decel, and speed becomes a function of distance / time.

btw: moving several servos in sync is what CNC machines do at great precision. (The CNC world has an ancient control language for this called G-code.). I'm about to engage in modifying a low cost mill called MF70 to make it into a CNC. and it is quite frustrating to discover that no one on the net has used RC servos with modified firmware to control the XYZ axises. everyone seems to use these *@#$ steppers that require amplifier boards, controller boards and parallel ports on the PC .. whereas using servos seems like a good idea but if no one is doing it then i'm probably wrong.

Yah, I can relate - I have a 3 axis mill (Seig X2) in the other room that uses TurboCNC to drive the G-201's and 640 oz/in steppers! I can do some manual g-code, but am by no means a g-code wizard.

Regarding servos and CNC, you can do this, but the resolution is what will bite you. If you use a servo with an optical encoder or similar, you could do an OpenServo-like mod to produce RPM's (instead of just <1 RPM angular motion) with high resolution - that would be possible! Can't speak for the life of the servo, it depends...

Regarding open loop (no positional feedback) versus closed loop (positional feedback) - my CNC machine is open-loop, but I don't use it for production. If I did, I'd put some encoders on it. For one-off's, I don't find it to be all that critical.

Regarding backlash - In my setup, I purchased a conversion kit w/ ballscrews that have "oversized" balls in the nuts to reduce backlash. Other solutions incorporate two ballnuts w/ a spring between them, there are yet others. Helical couplers are also a means to reduce backlash, and there are many other coupler options for motor to shaft. The couplers I have from stepper to screw have virtually no backlash (forget what type they are, they have a sliding plate - but for what I do, it's good enough).

What I invested wasn't cheap, but I wanted to have a motor / driver / controller setup I could transfer to a knee mill some day (like a Bridgeport).

Backlash sucks, but it's part of a CNC machine. You also have deflection - deflection in the head, deflection in the tool, and to make matters worse, these change with material, feed rate, tool type, tool sharpness, tool speed, many factors. Depending on how your Z is built, deflection can be more of an issue at varying heights. In my machine, I'm at a point where deflection is more of an issue than backlash, and this thing is mostly cast iron! Oil must exist in a film between bearing balls and surfaces, oil is not a fixed variable.

What I've found is simply this: you can compensate for backlash, deflection, and most of the inadequacies of the mechanics of a machine, but they will always exist at some level. The trick is to set up your CNC program with suitable backlash compensation, and modify the CNC job as needed to get the results you want. At some point, the accuracy is impossible to chase down - there is truly no such thing as "perfect", but there is a heck of a lot of "good enough"! Problem is, "good enough" CAN involve a fair amount of trial, error, and money.

Take Care,
Paul

[PedroR]

Hi all

I wanted to contribute to the discussion (the initial one and therefore I will be deviating the current conversation a bit; I apologise for this):

From the project we've done with the Bioloid GP (a 1 minute dance sequence mixing break dance, John Travolta, Beyonce and others) the following became very clear:

- Battery level does not directly affect speed on Roboplus motions.
This is because Roboplus divides each motion in smaller steps (I believe 8ms steps) and when playing the motion the robot is receving instructions to move to a new position every 8 ms.
Therefore if the Robot is not yet in position it should be, it doesn't care and moves to the next one.
Because the movement is divided in such small steps there are no synchronization issues (this was visible and was confirmed by the fact that it always stuck to the music and made the key movements on the key points of the rhythm).

- What we did see happening was:

1) If the battery level was too low sometimes it would not do the whole range of the movement (as the timing mechanism pulled it to the next position (every 8ms) to keep timing in sync).
This was hardly perceivable but it exists, especially if you program movements that require servos moving over a large range in a short period of time. (ie very fast movements).

2) The most perceivable effect that the battery level has relates to torque: on a full battery movements are performed with high torque.
On an almost flat battery the torque is much inferior.
This was a real issue on a particular movement where the robot did a complete split and had to get up from the floor right after that.
This sequence had to be done quickly.
What we saw was that on a full battery the robot fell forward when getting up (excess torque); on a flat battery it fell backwards (insufficient torque).
There was a small window where the robot worked properly.

We kept tuning and tuning but we were never able to completely overcome this issue.

Timing was always perfect but sometimes (more like 60%-80% of the times) the robot fell.

I believe an interesting approach to fix this - which we haven't yet seen in Humanoid Robotics - would be to do something similar what Pololu did with the 3pi: use a higher voltage battery and then use a voltage regulator to ensure the voltage getting to the robot and servos is always constant.

I believe that even if the servos have proper torque control (which I'm not sure AX-12 and AX-18 do properly), without ensuring a stable power supply it is very hard to control torque because the Voltage level directly affects the behaviour of the DC motor. (this can be seen on what's called "NTI graphs" I believe; I don't know what's this means but they're supposed to explain the behaviour of the motor under different voltages).

In addition using a regulator with Higher voltage batteries has the added bonus of allowing longer run times while using batteries that won't have to be necessarily much larger. (if I'm seeing things correctly a 4 cell 1000mAh LiPo (14.8V) with a voltage regulator for 12V would probably run for longer than the default 1000mAh 3 cell of the PREMIUM kit).

I look forward for your comments on this.

Regards
Pedro.

[i-Bot]

Sounds like a good idea. You might use high current BEC device to get the 12V. I think the Castle Creations BEC Pro can be programmed by USB to give 12V. You will need to power from at least 4s Lipo. With BECs and switching regulators generally they are more efficient at higher input voltages (opposite to linear regulators), so the more series cells the better ( maybe two 3s packs in series ?

Obviously the extra cells increase size plus the BEC.

I would expect the results to be more consistent while batteries are well charged, then a more rapid cutoff in performance.