Jerky reads

[Fritzoid]

I've been writing some new motion routines and I can pulse-out position commands to 24 servos at one time. I can also read-back the current positions of 24 servos at once. The problem is that each time I read the servos, one or more of them jerks a degree or two out of position. Subsequent positioning commands return them to their hold positions but the net effect makes the poor guy spastic .

I then tried a RoboBasic program with a looping GETMOTORSET after some initial MOVE commands and the result is the same, albeit much slower, random jerking. It appears that this is a defect/feature of the servo hardware/firmware and not a programming error.

From my point of view this rules out any effective use of the PWM position read function as part of a feedback-type control loop, at least when the motors are on!

Any ideas on how to deal with this problem will be greatly appreciated!

[i-Bot]

You are right that the turning off of the motor drive in a PWM position read is a bit of a problem. you need to quickly send a new position command

I just updated the spec to cover the serial mode.
http://robosavvy.com/Builders/i-Bot/HSR ... 0Servo.pdf

It appears that the serial mode position read does not turn off the motor. Only problem is I cannot get the serial motor off command to work.

To use this mode you need to turn the ports into parallel bit banged UARTS. Daisy chain is not yet available due to not being able to set ID. Also it will be too slow, serial is similar speed to PWM

[DirtyRoboto]

I've been writing some new motion routines and I can pulse-out position commands to 24 servos at one time. I can also read-back the current positions of 24 servos at once. The problem is that each time I read the servos, one or more of them jerks a degree or two out of position. Subsequent positioning commands return them to their hold positions but the net effect makes the poor guy spastic .

Yea, the servos may be between points and are moved to the nearest point so that the read value = the actual position.

[Fritzoid]

I believe that it is more fundamental to the servos in PWM mode. The jerks occur even if the reads are issued long after the robot has reached a stable position. Also, the effect is still quite pronounced even if I follow the read request immediately with another move. Driving 24 lines at a time the repositioning move pulses follow the read loop by only a few microseconds.

I'll be moving on to serial mode as soon as I get my little guy back together again from a gyro installation. I-bot's post implies that bit-banging the digital ports on the controller can be done, so that's encouraging.

Sure would be nice to look at that servo firmware...

[Fritzoid]

Well, after a week or two of experimentation in serial mode I can say that things are looking up. At this point I can get the little guy to smoothly rise from a squat into the standard position just like PWM with PTP. In serial mode this takes just three commands, one to read the present positions, one to set the speeds, and one to move the servos into position.

Read position commands can be issued before, during and after the actual move and work much better than in pulse mode. There is still a small bit of what I would now call twitching and some gear chatter as this occurs but it is hardly noticeable in comparison to the PWM jerkiness.

The positions reported after a move completes are not exactly the same as the positioning commands request. The difference is small, plus or minus eight or less. This indicates that the granularity of the positions actually reachable by the servo is less than the 2000 possibilities that can be specified in a move command. Also, the read postion commands are pretty reliable but not 100 percent. I see a failure rate though of less than 1 percent.

I've also played around with the read current and voltage command and have some interesting results to report. The voltage values reported by the servos are usually quite close to one another. The values are lower when he's moving than when he's just standing and lower still if he's under strain.

The current value is more interesting. The numbers returned by different servos are often quite different and much lower than the voltage. Typical voltage values are in the range of 0x80 to 0xC0. Current values range from a low of 0x00 to about 0x40. The current value is closely related to the strain on the particular servo. If you pull on an arm the current on the arm servos and only the arm servos goes up!

The voltage reflects the overall system drain while the current reflects the local servo's strain. Seems useful!

[DerekZahn]

Interesting info! Thanks for sharing your experimentation results.

The "current" value should be pretty much exactly proportional to the strain on the particular servo. DirtyRoboto has been doing some cool things with those current readings, and I'm sure there are lots of other possibilities (maybe an unexpected current reading in a shoulder servo could cause him to raise his arms to be picked up, so you could tug on his arm to make him ask to be held, etc)

It's not intuitive, but servos don't actually go to the spot you tell them to go, they go somewhere nearby. The width of the region that is considered "close enough" is called the dead band, and you can set this in some servos (I'm not sure about the robonova). The reason to have a deadband is that otherwise the servo will overshoot and correct and keep doing that over and over, which is hard on the servo because it's working very hard to do nothing. Also small variations in the position readings would cause the servo to try to react all the time.

[Fritzoid]

My understanding is that, as it relates to analog servos, deadband refers to the delay between moving the transmitter's stick and the time the servo actually reacts. What Hitec means by deadband in a digital servo is anybody's guess. As far as overshoot and oscillation, these are usually related to the PID control loop and the P-gain and D-gain values. Since Hitec hasn't seen fit to document these settings it's hard to know. My experimentation has shown some minor overshoot and minimal oscillation about a set point, so I assume that the P-gain and D-gain defaults are adequite for the present time.

My guess about the inexact positioning is that the servo converts the digital value to an analog voltage and visa versa. Hard to say without the actual servo firmware.

[DerekZahn]

My guess about the inexact positioning is that the servo converts the digital value to an analog voltage and visa versa. Hard to say without the actual servo firmware.

Yes, the position is digitized so it can be used to tell if the servo needs to be moved. It also can be reported to the user in these fancy servos.

Looking at the documentation for the Hitec HFP-10 servo programmer, hitec seems to use the word "deadband" to refer to the range of settings that correspond to the "neutral" point, which isn't a very interesting concept for robo-one bots.

So maybe instead of the word "deadband" i should have used the phrase "allowable error". There has to be some allowable error, but it may not be programmable.

[Fritzoid]

If Hitec has used the term in such a way before I would have to go with that definition too. Since it's a settable parameter maybe someday we'll be able to change it and see.