The software version is now 1.10, and the Servo-on/off now works in the HMI protocol.
There is still no programming cable from Hitec, but I have been given a design, which works just fine for me. Unlike my previous cable, this one is just one resistor ! Hitec promised this cable a year ago, and it is still not available
Note these new servos are HMI interface, the HFP-10 does not program them.
I was testing one of these 5990 servos with the HFP-10 programmer in manual test mode and found they are only doing 140° rotation. The box says it’s 180° capable. I have not tested it with pulses beyond 900 to 2100uS that the HFP-10 generates. I’m not expecting it to accept a larger pulse range, mostly because it would be cool. So there is apparently no way to make them 180° capable using standard pulses. I don’t know much about the HMI interface. Does it use the standard servo pulses, or something else?
Hmmm… this is somewhat of a concern, as I was in the process of building a very expensive robot with these servos and the SES based on the advertised information. If these servos can’t go beyond 140 degrees, that will limit their usefulness. A 140 degree shoulder isn’t very cool.
They should take 550microsec to 2450 microsec on PWM the same as they take over HMI, and same as other HSR HMI servos. That is just over 180 degrees, maybe 190.
Aw nuts you stole my answer. hehe Yup I verified that the servo accepts 550uS to 2450uS just now. So it was just the servo programmers manual test mode that was limiting the range. It has a resolution of 0.095°, much better than any of the other digital servos they make!
Has the actual resolution of the servo been checked? A test I’ve used with servos is to attach a thin ~10" bamboo skewer to the servo control horn such that it makes a long pointer. Then send the servo positions in 1us increasing increments while closely watching the end of the pointer. The number of us changes to get a detectable change in the position of the tip of the pointer would be the real world resolution. I doubt that there will be pointer movement for each 1us change.
The processor is still the ATMEGA8, so the the feedback pot is read by a 10 bit A toD and 180 degrees is about 2/3 of the range. So I think the ultimate resolution is between 9 and 10 bits.
Also if you measure the resolution, then you need to take the deadband into consideration.
I started to measure mine, but it broke my test rig on a torque test before the current overload protection could be tested. A serious muscle !
Below is the simple setup I use to find the actual resolution of my servos.
The tip of the bamboo skewer being used as the pointer for detection of the servo movement. My inexpensive servos seem to have he capability to get ~426 discrete positions in ~190 deg of rotation, which would be ~.5 deg of resolution. This would be for conditions where the servo is under no load.
If all you are doing is incrementing in 1uS steps then you are never getting away from the deadband. If you move the servo in larger increments you eliminate the deadband from the equation. For example try moving from 1500 to 1600, then 1500 to 1601, then 1500 to 1602, marking where the pointer goes each time. This procedure should show a better resolution then the incremental method.
I think deadband will always play into the servo resolution equasion, generally independent of the test method. I also think the pot in the servos may be the limiting factor in the servo resolution. One could test the resolution repeatability by marking the pointer position at 1500, then having the servo move from other various positions back to the 1500 position. The final position differences could then be compared to those of the incremental 1us changes. As the bamboo skewers are very light weight, a super pointer could be made by attaching two end to end. A dab of hot glue or similar would be needed to attach to the servo horn to ensure there is no attachment slop that might affect the results and the servo would need to be securely held in place to ensure it doesn’t move. This is a pretty simple test setup to get real world results as opposed to just dividing the timing value range into the available number of rotation degrees in the servo.
Ok, not willing to let it alone I created the equivalent of your test jig. Remember we are talking about the 5990 not the average servo. I made two tests. The first was a 1uS incremental test. We drove it from the SSC-32 with Lynxterm connected. Clicked on the slider and used the arrow keys to increment the pulse one micro second at a time. The result was almost a perfect pattern of 3uS, then 2uS, then 1uS steps required to move the servo. We did this for a few dozen moves and found the average. It was exactly 2uS. The second test was to move from 1500uS to 1600, 1602, 1604, 1606 etc. Going back to 1500uS in between each move. We put a mark where the servo moved to and was able to see that the servo was moving to new positions each time, but it was difficult to measure the accuracy due to the chop stick only being 8" long. I also used full speed to make the moves. If I get more time I would like to use a longer stick, and use a slower speed for the moves. Not sure what this proves other than the fact that this servo kicks butt as far as resolution goes.
Oops I forgot to actually calculate the resolution.
That’s what I love about these forums. The truth is out there, and the facts are what they are. I like testing and finding what works and what doesn’t. There is no marketing trickery or smoke and mirrors involved.
Just to establish a baseline, also perform the same test with the HS-805BB servo. It has about the same torque, so it probably has a similar internal gearing ratios (which probably affect the final resolution capability). This would provide a better picture of analog vs. digital servo resolution. The servo resolution is probably a minor point in typical robots, but being able to develop simple servo performance test methods might be of interest to those who want to persue more serious projects.