The only point I tried to make concerning offsets all pertain to the core use of offsets in the simplest form. The ability to make everyones robots “as close as possible” to each other. This is the reason everyone can share code. Before software offsets we had to do it in hardware. We used to make the holes elongated so you could rotate the servo till the leg was in the right position, then tighten it down. Although technically the best solution, it had it’s own set of problems…
The fundamental nature of offsets does not permit large offsets. Offsets are done at the center of rotation. When the offset is implemented it will reduce the range of the servo it’s applied to. For example if a servo requires an offset of -50 to be properly aligned, telling the SSC-32 to send 1500 results in the SSC-32 actually sending 1450. The effective range then becomes 550 to 2500, not 500 to 2500. Sending positions below 550 would result in the offset being ignored.
If the offset were +50 the effective range would then become 500 to 2450. Sending values over 2450 would result in the offset being ignored as well. However, there is sufficient range in the 500 to 2500 spread to achieve a 180° from most standard sized servos, even with the +100 / -100 (15°) offset implemented.
Everything is a trade off. For example with with the phoenix legs, you can not get proper alignment of the legs with the servo horns in their standard horizontal/vertical position with the ±100 limits, so you have two choices. One is you take off the horns, rotate them over to the next spline (15 degrees) and then do your adjustment of the legs (Step 13 in the assembly guide). The plus of this approach is that you still have the normal 180 degrees available to you with ±90 degrees in both directions. The other is to relax the ±100 offset somewhat such that you can do this without having to modify the servos. However as you mention this will not allow you to go ±90 degrees after this. The question I can not answer is with this other approach could I still get the full range in both directions? I don’t know.
But in the end the way you described works great, so might as well stick with it.
I forgot to answer your post. With the old powerpod program with earlier versions of the SSC-32 firmware, the SSC-32 offset registers was not available so you had to use the PO commands to set up the zero points. However with the newer firmware, you are better off to setup your offsets as mentioned and then you can remove the startup code that did the PO commands.
Now if your question was, can I use the offsets that you are currently using in the powerpod program as a good starting point to know what the SSC-32 registers should be set to, my first guess would be yes. You could build a basic program with your current offsets. You could then use the “R” command, specifying the correct register for the offset of each servo you are using and to the SSC-32 and also to set the correct bit in register 0 to enable it. This is all described in the SSC-32 manual: lynxmotion.com/images/html/b … m#ssc32reg I have done this in some programs I have tried to build in a servo zero offset finding function into my program as I am embarrassed to say that I normally don’t do a very good job when I am assembling a robot as I am too much in a hurry to see it run.
But it probably is much easier to simply go back to current tutorial for the CHR-3 and use Lynxterm to find the correct offsets using the values in your powerpod program as a quick start and lent Lynxterm do the dirty work of setting the appropriate registers.
Ah ha! This is a terminology problem. The change in Step 13 is not an offset change. The offset only moves the output shaft into calibration. Edit: I botched the rest of this. It should have been… In step 13 we are manually adjusting the leg to be as close as possible to the desired position for the calibration to be done in the tutorial. End edit…
This has been bugging me since the T-Hex thread. The facts are, the +/- 100 offset pulse is sufficient to calibrate any servo to a known aligned state. Doing so will limit the range on one side or the other. The range should still be enough to achieve 180° on the effected servos.
I hope I didn’t offend by over explaining this. I knew there was still something confusing some…
Thanks for your help Kurt its clear for me. The mistake that I had was that the 2.0 code “load” the offsets from the register. In the next time I would put the offsets to the SSC-32 register and test the 2.0 code on my CH3-R.
I’ve been putting this off for my IK code and have started to troubleshoot (lots of serial out/print to screen debug codes) mine as well…
I think there’s a fundamental problem with limits when using an IK code tailored for Phoenix to the CH3-R bots.
Can someone please give me some bullet points on the core differences of what the differences were at the low-level (non-limit type of fuctions, trig functions to convert angle to pulse, anything on the body-rotation side)?
OMG, my problem was completely unrelated to everything that was found by you guys. It was error between keyboard and chair, perhaps one of my biggest blunders…
I group my servos 0 to 5 clockwise, and I’ve accidentally flip flopped group 3 and 5
For example with with the phoenix legs, you can not get proper alignment of the legs with the servo horns in their standard horizontal/vertical position with the ±100 limits, so you have two choices. One is you take off the horns, rotate them over to the next spline (15 degrees) and then do your adjustment of the legs (Step 13 in the assembly guide). The plus of this approach is that you still have the normal 180 degrees available to you with ±90 degrees in both directions. The other is to relax the ±100 offset somewhat such that you can do this without having to modify the servos. However as you mention this will not allow you to go ±90 degrees after this. The question I can not answer is with this other approach could I still get the full range in both directions? I don’t know.
