Servo vs HobbyServo

Servo      HobbyServo

They look the same don't they ?    But, I'm talking about MyRobotLab services Servo and HobbyServo. Two software services which are used to control the ubiquitous little motors we have come to love.

We tell the motors to move to a position with the same commands :

servo.moveTo(30)
hobbyservo.moveTo(30)

Since there is no real feedback with these motors we "guess" when and where they will travel and arrive at their destinations.  They use very different processes to formulate these estimates.

The "guessing the path of the servo" was originally implemented on an Arduino.  And that means it was not portable to other Servo Controllers. (e.g. RasPi, Adafruit 16 c Servo Board, Pololu Maestro, or any electronics which generate the appropriate pulse width modulation to control a servo)

Accurately guessing where and when your servo stops moving can be extremely useful. Its useful in planning more complex activities like gestures, blocking moves, auto disabling power, inverse kinmatics, obstacle avoidance,  and route planning.

A "real" accurate feedback sensor or encoder would be best, but this typically involves hacking up your servo and adding additional electronics, feedback wires and programming.  So instead we want the option to guess where the servo is as accurately as possible.  I'll go over in some detail how each works.

Legacy Servo ServoEvents - Manticore

In the above diagram, using a Legacy Servo service, you can see a moveTo(30) command get interpreted to an Arduino servo library writeMicroseconds(853) command.  If a "real" encoder was connected to the servo, real feedback could be provided. In our typical usage, estimation messages are created in MRLComm.ino (the script running on the Arduino) and sent back to myrobotlab running on the computer.

New HobbyServo Encoder Events - Nixie

The new HobbyServo service has several advantages over the older Servo service.  It uses a TimeEncoder - which potentially any other service in MyRobotLab could use.   The TimeEncoder will provide calculations and a stream of encoder events on demand.  The TimeEncoder will give you access to the resolution, update interval and I believe a better estimated position of the servo.  

 


Because the TimeEncoder is not implemented in Arduino, it will behave the same on all ServoControllers.  For instance, this setup of a RasPi and a AdaFruit 16 channel servo board could be supported.

Because TimeEncoder will be modular and implement the same interface as a real encoder, it will provide easy substitution with a "Real Encoder".   The same software with only configuration changes could support a continuous DC gearhead motor with an amt10 rotary encoder.  This configuration could provide much more powerful solution with more accuracy and real sensor feedback .

The rest of this post will be details on initialization, testing, and what our examination on what our interface provides.

Action HobbyServo Servo
energize on attach true true
moves to rest position on attach true  true
moves at full speed to rest on attach
even if speed is set before attach		 true :( 
undesired		 true :(
undesired
a move command interrupts moveTo command in progress ? ?
a moveTo command is cancled when moveToBlocking is in progress ? ?
autoDisable(true) before attach works as expected when attached
to servo controller		 ? ?
accuracy - unloaded with 0.12/60 assumed max ? ?
adjustable max speed     
moveToBlocking does not get interrupted by moveTo nor moveToBlocking on different thread    
     
     
     
     
     
     

 

calamity

5 years 6 months ago

Great work Grog!

 

I really like your new time encoder. Way more versatile than the code on the arduino.

One thing you did not talk in your post, that is valid for both the legacy servo and the new hobbyservo, is the relation of the "guessing" of the position of the servo with a speed (or velocity) setting. Without a speed setting that is in the limits of what the servo can do, the accuracy of the "guessing" will be bad. 

In your time encoder, you seem to assume a speed of 0.12/60 (500deg/sec), wich is already an improvement over the legacy servo because that one will "think" the movement happen instantaneously if no speed setting is set.

But most servo that actually do something, like moving a part, will do it at at a lower speed than the unloaded speed. So if you assume the unloaded speed, it will create an inacuracy that can be trouble if you want to use the data from your time encoder.

I just want to enphase on the fact that knowing the servo capability and at wich speed it can go (not was the manufacturer report, but what it can actually do) is as important as knowing the servo limit in position if you want to use that kind of software "guessing" the position of the servo.

 

On another note, since I believe you can now save the servo configuration, maybe you can design a way to attach servo at the "last know position" then move under speed control to rest. To avoid part moving at full speed of power on. May not solve all the problem relate to that way the servo work, but could be useful. Just thinking about it.

 

 

Hi Calmity,
I agree.  

Manufactures say one rate, servo will likely behave differently. 
Loaded and unloaded are very different.
Modified gearing would produce very different results as well.

Our predictions depend on the initial accuracy of the max speed of the servo.

If we had an easy or fun way to calibrate servos to determine the "max" speed - then subsequent "guessing" would be better.

How to calibrate ?  I'll be trying to make a very simple jig with a wire which makes at 2 positions.  The general idea is, if we don't want to bother putting a real encoder in with feedback, then maybe a temporary 2 switch (start & stop) would be enough to calibrate.

I'm not sure what to do about saving the last position.   At one point I believe Servo was changed to auto-load its config (which included lastPos).  Auto-loading all services is probably a very bad idea, it would cause more unexpected results in other Services.  Perhaps just auto loading the lastPos, and saving it at each completed servo movement might work the best ... still not sure.

calamity

5 years 6 months ago

to calibrate the speed of the servo on my inMoov, I simply chronometer the time it take to move x degree. Most part of the inMoov moves slowly so it was not too hard to get fairly accurate results. At least good enough to have usable data.

 

about the saving of the last position, it was just an idea that pop out while reading your post. Not sure if it worth it too.