I have started a seperate thread here, as there has been considerable interest in this interface, and it seems like the sensible thing to do.

Here is what sandy had to say about the feedback protocol:

"Here we go! Looks like you send the servo a short (50usec) pulse, switch your port pin to input (needs pull-up resistor) and then read back a variable length pulse 500-2500 usecs in length representing the feedback position (accuracy of 10%) "

Is there any news of weather the servo's can be daisy chained? I have not read the PDF yet, and if this is discussed there then I appologise in advance. :)

Ok I have now had time to view the PDF for the HMI interface.

So it seems that three parameter's can be set, but it does not explain what these parameter's are or how to set them. I guess one can assume that these could be Center pos, Max and Min limits? and that to set them: send the Control pulse, followed by a X us gap? followed by the desired position in 500us - 2500us? any thoughts.

This doesn't allow for the fact that the deadband and velocity can also be adjusted on these servo's?

Hi Matt :) - your proposal for the 3 parameters and how to set them sounds sensible. So there are more parameters... deadband and velocity? Could there be some other mode these servos can be switched into, perhaps a proper serial protocol which would then allow for daisychaining? The wording in the pdf is ambiguous - they may be saying some settings only acheivable using the "optional settings kit"...ie they're not going to tell us 'cos they want to sell kit! I hope some more web scouring will winkle out more info... If its not forthcoming, it might be worth one of us knocking up a servo hacking tool that can send *and receive* all manner of pulse lengths, baud rates, monitoring resposes ..

More info on the illusive HMI interface. I just stumbled upon the link above. From the specification list of the HSR-8498HB Servo which also uses the HMI interface, the data feedback list at the end is:

Current, Voltage and Position.

This would make more sense in a way. I think that parameters such as end limits and dead band can only be set using the HFP-10's curiously complicated protocol. Otherwise a glitch pulse may inadvertantly reset a limit!

I like the idea of getting current feedback from the servo... great for colision detection and force feedback!

So I think the other three parameters mentioned in the protocol PDF would be current, voltage.. and something unknow as yet?

M@

Cool - even though you pointed me at the page I missed it several times, well spotted! Yes, eg could do that trick they did with the toy dinosaur, and get it to react when you put a finger in its mouth. What I am now wondering is whether the servo can be put into some kind of free wheeling mode where it is not driving the output... I'm assuming it must be safe to push the servo around by its horn (if youll pardon the expression) and measure its position for performance recording purposes?

I'm not sure how good these servos would be in force feedback applications. Or complience control as it is sometimes called. I suppose you cold monitor the current and watch for changes when the motor is stationary, eg someone is trying to move it.

The only problem I can see at the moment, is that the documents only suggests a current feedback and not direction? unless the PWM feedback signal is center biased?

..hmmnnn. I wonder if the control system could monitor the current as you suggest, then when it goes above a suitable threshold, stop driving the servo with normal PWM, and start reading back the position... perhaps even alternate normal PWM with the short reading pulses.... there aught to be plenty time in a frame to do this - keep track of the feedback direction in software whilst simutaneously driving the position .... ?

Matt, agggg! I've just upgraded computers (nightmare) and managed to lose my forum cookie *and* my login details, couldn't get any joy out of the login "forgot your details" function either... could you email me my password? cheers, sorry 'bout that, Sandy

Sandy,

Have sent you an email.. let me know if you receive it.. and what you would like me to do.

Cheers. :)

I think that is exactly what you could do.

Send PWM position data, and Current Feedback pulse at 50hz each seperated by 10ms. As long as the current data sent back has some direction information, your controll software could then adjust the PWM drive signal to produce some form of force complience?

P.S. It would be nicer if you logged in.. so we have a name to posts :)

re not logging in, er... sorry that was me... fixed now though! oops :-|

Cool! seems like that could be the way to do it then! Just need a servo to play with... (and probably some long hours fiddling about with code).... I seem to remember with r/c servos... if you have them connected to the power supply, but don't send them pulses they just stay where they are? Combined with position feedback this could enable a really good "soft start" system, whereby you could read the positions at power-up positions, then gently bring the servos round to your start position?

The soft start feature is exactlyy waht I would use the position feedback for.

Although I find it rather iritating that you can't make the servo power down! I like to conserve battery power when my hexapods sit down by stopping the PWM stream to relax the servo. You would think there would be a setting for this? maybe there is??

This seems to what we are waiting for:

http://www.robonova.de/store/home.php?cat=253

I use an HFP-10 with HS 5475HB, but the HSR 8498HB servos in my RoboNova appear to have even more parameters.

Some descriptions imply the serial protocol is able to adddress multiple servos (128)

Hi Richard, extra parameters sounds interesting. re the link you provided, I guess you mean the HMI servo programmer kit... Is the user manual available somewhere for download? Have you read it? Sandy

Hmm.. Wondered how lonf it would be bofre there was an RS232 version of the programmer.

Looks interesting, anybody have any info on it. There doesn't seem to be anyting on the site.

As Sandy says, a manual would be nice!

M@

If you look to the robosavvy forum you will see that the serial kit is due in a few weeks. To quote:
"The software and cable to program the servos is available in a few weeks. They wanted to ship them at the end of March but had issues. The software is able to program nearly 80 parameters of the servos like deadband, direction of rotation, max speed, etc.
I'm looking forward to it, altough I just need the setting of the direction at the moment
The Hitec HFP-10 Servo-Programmer is not able to talk to the RN-1 servos. "

end quote.

I do wish Hitec would open the kimono and share more of the protocol. The part about the short pulses to give feedback is useful, but gives no concept of the serial capability of these servos.

I have been using the previous HS-5245MG and HS-5475HB, and these are easily programable over a 19.2K async serial port to read and write the eeprom on the Atmel processor. So you can read and change the same parameters as the HFP-10 programmer, and more ! They do not have current monitoring though. The protocol for the HSR servos is different, and I really expect that they can be daisy chained, and entirely serial controlled. It is up to Hitec if they disclose the detail, or a short matter of time before the protocol is reverse engineered,or another supplier is more open.

Expect to be able to 3 wire daisy chain your servos with serial control and full parameter programability within the next 6 months.

Richard

Thanks for the update richard,

Looking forward to that programming lead, I have just received the full shipment of 5995TG servos for our next generation of robot. It would be great if they can be serial controlled.. it would be the obvious step in servo technology. Lets hope Hitec release more info on the protocol soon!

Cheers,

Matt.

Hi Matt,
I see confilicting information on web about the 5995TG.

Since you have some of these, do you program them with the HFP-10 programmer ? I assume they are HSR servos you have.

My HFP-10 (ver 1.02) does not see my HSR 8495HS servos, but have no 5995.

If the HFP-10 works with the 5995TG, then I can help you to read the position over the serial protocol. Also I might then use the 5995 until Hitec release the new serial protocol/interface for the HSR 8495.

Have you tried the position feedback based on the published HMI pulse length protocol ? Does it work ? I don't understand why they only publish this, when the already existing serial capability is so much more accurate

Richard

Hi Richard,

Unfortunately I have not had any time to play with the 5995 servos yet, as I have been in Australia for the last 10 weeks. I will be back home on the 19th May, and will start to look into things then.

I do not have an HFP-10 programmer yet, as Amarang have not had any in stock! I have had one on back order for months. I am informed that this is the programmer that is needed for the 5995 servos. I do recall seeing something about a new firmware version needed on the programmer, maybe this is why it does not talk to your 8495 servos?

It would be great if you could post details of the serial interface. It would be much simpler to use than the bi-dir PWM interface, and as you say more acurate.

If you can send details of the serial interface, I will try both when I am back at the end of May.

cheers,

Matt.

I've spent some time on reverse-engineering the HMI protocol.
Here's what I've learned:
- The yellow wire is talking "TTL serial" at 19.2 kbaud. It's bi-directional, so you need to drive it with an open-collector buffer and a pullup. I connected the serial port on my PC, via a MAX232 chip, and was able to capture bytes moving between the HFP-10 and an HS-5475. I added a 7407 buffer to the data line, and I was able to drive the line and send bytes myself. I used a C++ program on the PC to read/write the bytes.
- Most data is sent in packets of 6 bytes. The first 2 bytes seem to be a 'command', the 3rd byte is 'data', and the 4th byte is a checksum. The 5th and 6th bytes are always 0x2B, but I think they are sent by the servo as an acknowledgement(?).
- Before modifying any params on the servo, there is a large transaction of over 400 bytes sent/received. I *think* what's happening is that the HFP sends some command info, then the servo responds with *all* of its current settings. If you want to change a param, you must know the *current* setting first, which is sent by the servo. For example, to change the SPEED setting, you tell the servo both the current speed and new/desired speed.
- When you select the 'limit' param, there is a continuous stream of packets going back and forth (50 times per second, 12 bytes each). The data appears to be position info, actual/desired.

The main thing I couldn't figure out was how to reproduce the 400-byte 'init' transaction. If I let the HFP send that part, and then used my program to send command packets, I was able to modify the SPEED setting on the servo. But to do anything interesting (without an HFP), it's necessary to make the 'init' transaction work.
There is probably something about the start-up timing that I'm missing. For example, when the HFP does it, it powers up the servo, then about 10 mS later it raises the data line to a TTL high level, then there is a much longer delay, then some data starts to move (since the single wire is bi-directional, it's hard to tell which side is sending what).

If someone else is able to go further with this, I'd like to know how it's done...

Pete

The format is similar to that Pete descibes. The first byte is the command, for instance "a" to read, and "b" to write a parameter. The second byte is the address of that parameter. The 3rd byte is the data and the fourth the checksum. for a write the response is "++". For a read it is "+" and the byte read.
For the endpoint part their is a preamble of "d" commands, then what appear to be " f" to set servo position, and "e" to read the position. The "e" returns two bytes.

For the electrical interface, I use a P MOSFet to power on the servo from DTR. Then a couple more N MOSFET to send and recieve on the serial line. I have a 47K pulldown on the yellow.

The servo I am using is the HS 5475HB

To see which is sending which, I put wires direct onto the Atmel processor.
Hope this helps
Richard

Well we seem to be getting somewhere with this protocol. Thanks for your input Pete and Richard, when I get a chance I will have a play with the 5995TG servo's and write up a protocol document.

Richard, do you have any info on the address byte for the packet?

I'm still not sure if you can daisy chain these servos.. it would seem you would have to set an address byte somewhere, and this protocol only allows for one servo on the serial port. Maybe Hitec will update the servo firmware with a better protocol.

Also very dissapointing that the servo position is only 8bit. I would have thought with these hi precision servos at least 10 or 12bit would have been required?

Hi,

I think it best to start new topic on this, since we are talking about the HFP10 to digital servo protocol. This sems to be different to the HMI protocol which is used by the HSR and Robonova servos. For the HMI we should wait maybe for the serial programming cable. For the standard digital there is still lots to do.