HSR-5498 serial communication

[latchup]

Wow, regarding the concentrated knowledge about HiTEc-Servos in this place this is exactly the right forum for my topics.

I have just received a package of HSR-5498SG digital servos and been spending the day struggling
my way through the serial protocol. While I've mastered most of the basic functionality by now, there
are still some loose ends I would like to discuss here:


(1)
There seems to be a timing problem in the servos answer to some commands, e.g. F6 (set position).
An oscillogram of the communications line shows that the servos pulldown attempt is not synchronized
to the start bits of byte 5 and 6, resulting in erratic readouts or framing errors. The timing behaves well
on most of the other command set. Can anyone reproduce this bevaviour?
By the way, what is the cotent of these two reply words?


(2)
According to earlier therads, the HMI-servos suspend motion control after one queries the motor position
via extended pulse control. This seems not to be the case for a query via the serial interface. However,
I am observing an approx. 10 percent slowdown of the motor speed when performing a continuous
position readout during motion. Also there is a well audible switching noise and jiggling while reading
the position of a motor holding its position. Are there any insights into the side effects of a position readout?


(3) Has anyone a good model of the control mechanism, particularly with regard to the settable motion control
parameters speed, P-gain and D-gain?

Some observations:
(I regard the control pulsewidth read out via command 0xE9 as proportional to the motor speed (which should
be reasonably astimation for an unloaded motor)).

(a) The maximum speed as read out via command 0xE9 is 255 (100%?) for speeds set to 100 or higher. The
speed parameter influences both final speed and acceleration at the beginning of a motion (but not the
deceleration at reaching the end point).

(b) P-gain influences the both acceleration and deceleration but not the maximum reached speed. Larger
P-gains results in larger acceleration. Do the two P-gain bytes form a 16-bit word?

(c) D-gain influences acceleration and deceleration. Larger D-gains result in slower acceleration and smaller
position overshooting. (In opposition to the illustration in the HMI-servo-programmer demo program.)

Although I have been blessed with some basic knowledge of control theory, I am quite a newbie in this servo
business. (Oops, almost slipped up saying toy robots...)
What are the control variables P and D are referred to? Speed or position? If it was the position I expected an
integral term to fix the control deviation?


(4)
What is the difference of writing parameters to memory via command 0xE4 and writing to EEPROM via
command 0xE2? I assume writing to memory only changes parameters temporal. When changing the servo
ID in EEPROM I must follow this sequence:
Write ID via 0xE2 0x29 ID, Release motor via 0xEF, Power off motor, Power on motor.
Has anyone tested to change other parameters in EEPROM? Are they updated to memory immediately?


(5)
Has anybody experience with the EEPROM checksum (parameter 0x2C)? At the moment I just increase
or decrease the checksum appropriately when changing the servo ID. I hesitate to read out the entire
parameter set to recalculate the checksum when changing other parameters. Sniffing on the serial stream
of the Hitec's HID-serial-programmer demo program I found that the value 0xFF is written to parameter
location 0x2D. Any information about that parameter? (I just find this a somewhat suspicious location |-).)


Well, that will be enough for tonight,
hope my questions are not too boring,
robot programming continues tomorrow...

[Fritzoid]

Not sure I can help you much but here goes...

1) The return bytes from a E6/F6 command are undefined so timing should not matter.

2) There may well be a performance loss due to intensive position querying during servo motions. However the effect is much less pronounced in PWM mode. Thanks for quantifying this a little more for us.

3) I can't say much about the servo control mechanism other than that it more-or-less conforms to industry standards. More info can be found on the web.

4) The E2 command is used to write to the first 256 bytes of memory. This is where the control program keeps its variables (i.e. gain, speed, target position, etc.). Changes to this area are validated at power-on by the checksum at 0x2C. The E4 command is used to write outside of the first 0x100 range.

5) The standard checksum is 0x100 - the sum of bytes 0x00 thru 0x2B.
Can't say much about location 0x2D, probably some kind of flag.

You probably knew all of this already

[latchup]

Thanks very much for the answer, Fritzod. (You were right, I knew most of that by the time.) So according to the number of replies, the digital servo protocol doesn't seem to be that intersting after all? Then I will continue the thread by myself with a summary of what I've learned so far on the different topics.

(1)
While the 0xE? commands work fine for the 8598, the 0xF? commands don't work at all or return garbage. (Note that the HMI Servo programmer uses 0xE6 to set the target position, and so continuously produces framing errors.) Unlike Fritzoids statement the replies to all 0xE? commands seemed relyable in my tests.

(2)
The speed reduction increases with increasing readout frequency, no further investigations.

(3)
The motion control mechanism seems to be divided in two modules: A trajectory generator, which generates a multi-point trajectory with constant speed, and a PD-controller, which sets the driving pulsewidth according to the deviation from the actual trajectory point (independent from speed). You can read the actual trajectory set-point from memory location 0x06:0x07.
This mechanism provides a load-independent motion with constant speed.
Since the motor works as an integrator, the PD-Controller on the pulsewidth acts as a PI-Controller on the position.

The trajectory generator has a dangerous bug: When setting a new target point, the trajectory always starts at the last set target position. Since the joint can be released with the 0xEF command and manually be moved in the meantime, the actual position may be different from the old target position. The joint will then start to move in the direction of the old target position with maximum speed until it catches up with the trajectory. (Imagine this happend with a 'real' industrial robot...)

(4)
Command 0xE2 writes to the EEPROM. Address space is 0:0x2C. (Writing cells >0x2C seems to have no apparent evil side-effects, but fails every 3rd!?! attempt.)
Command 0xE4 addresses the volatile memory. Address space is 0:0xFF. While all locations are readable, not all locations are writable.
EEPROM locations 0:0x1E are loaded to memy locations 0x80:0x9E at power-on. At a 0xEA command the corresponding control parameter set is loaded from th EEPROM to memory locations 0x80:0x83.
To change the ID only ID and checksum have to be written. The motor will load the new ID from the EEPROM after the next power-on. When the servo reads a wrong EEPROM-checksum at power-on, all communication works properly, but the motor will not move. (So one has always the chance to repair the Checksum properly or write the default state to the EEPROM).

@Fritzoid: Since the mapping of to the real memory locations is transparent to the outside, your comment suggests that you might have some further information about the internal memory arrangement?

So, thats all until now.
If anyone is interested in a more detailed description then I can upload my excerpt to the forum. Just let me know.

[limor]

hi latchup,

This is great system-identification work!
Please don't loose enthusiasm and and keep updating this thread since many here will find this exposure of the servo parameters very useful.

I'm particularly interested to see if you are taking this in the direction of closed-loop control of the RN1 that would allow improved stability, the ability to deal with uneven terrain, skateboarding or with fall prevention when being hit in the context of a robot fighting competition.

[Humanoido]

Latchup, please continue your study regarding these servos
and post your results and experiments here.
The information is especially useful, and any time we can
better understand the cryptic code it will equate into better
humanoids.

humanoido

[latchup]

So, there are some new results concerning the issues above. Details can be found here:
http://robosavvy.com/site/Builders/latc ... -09-22.pdf

So far I only tested the HSR-5498SG. I would appreciate if someone could verify my results for the other HSR types.

My next issue will be the P,D control parameters. Any information regarding this issue will be welcome to me.

While it is evident that the control parameter sets are stored in eeprom locations 0x00..0x03, 0x1F..0x22 and 0x24..0x27 the arrangement suggests that locations 0x04, 0x23 and 0x28 may also be involved. However, those locations are only loaded at power-on and not updated at a change of the control parameter set, nor are they touched by the HMI-Servo-Programmer. However, this could be due to the fact that this parameter is constant over the several parameter sets of the same servo?


@Humanoido:

any time we can better understand the cryptic code it will equate into better humanoids

So, has anyone actually seen some code? I suppose reading out the program memory of an AVR-microcontroller should be possible, but unfortunately I am living on the PIC-side of the universe...


@limor:

I'm particularly interested to see if you are taking this in the direction of closed-loop control of the RN1 that would allow improved stability, the ability to deal with uneven terrain, skateboarding or with fall prevention when being hit in the context of a robot fighting competition."

I agree that a hirarchic control structure is mandatory, but I am rather amused about the human(oid) priorities: First thing after learning to walk upright is trying to knock over someone else...


So far,
Good fight! Good night!