See Initial Comments on Walking Engine
Because the Hi-Tec HSR-5995TG "Robot Servos" have different travel and signal characteristics than "standard" servos, the GaitPIC chip won't work, and the Nomad_Walking_Demo.bsp program will need some "adjustments".
The servos are "interesting". I started by checking out the spec sheets on the Hi-Tec sight, and found that the "normal" servos are listed at +/- 40 to 45 degrees, and the "robot" servos at +/- 90. This means that they should move twice as far for a given offset from center.
I also found that they (the robot servos) don't travel with the full range of pulse widths. less that 550 or greater than 950, and you don't get any extra movement. This may be able to be adjusted with the servo programmer from Hi-Tec, and I may be ordering one at some point. Besides throwing some things off, this also makes the movement "coarser". If I can get the full range of pulses to be effective, I should have more refined control of the servos.
Initially, I had the robot assembled with the vertical piviot in the hole closest to the servos. At least with the wall wart power supply, this was a little marginal. If the robot were "over" the legs, it worked OK, but if things got off center, even the robot servos didn't have enough "oomph" to keep things moving, and it started to look like a drunken spider. I moved the pivots to the second hole out, and all is well. I also had to re-center about half the horizontal servos. Once this was completd, the "even" directions worked as written in the demo program, but the "odd" directions (heading in between legs) didn't work well at all. The robot just tended to go nowhere, and rotate slightly.
When I started working on changing the code to get the robot to walk, I learned a few things about gait design. I don't know how well I'll get the communicated here, but I'll give it a try.
First, in order to experiment, I put the Nomad "on a pedistal" so that it could walk in place, and I could watch the legs move. With this setup, I was able to hold a steel rule under the "foot" and see how long each "step" was, and watch how the foot moved. I also used the Parallax PSCI application to move the servos "by hand" to determine settings for part of the gait. For this free software, see the PSC Software for PC link at the bottom of that page.
For those not familar with the normal gait used by a hexapod, it basically involves using two sets of 3 legs (alternate legs in each set). While one set is on the ground and "propelling" the 'bot, the other set is lifting and "resetting". This mimics the way most insects "walk" (as opposed to "hop" or "jump"). By always having 3 alternate legs on the ground, you are also assured a stable platform in the form of a tripod.
For the demo walking engine, each "step" has 3 phases for each set of legs. I labeled them in the D2 Section of the code as Plant, Propel and Lift. CrustCrawler's labels are Start, End and Mid Reset. Using my terms, the Plant puts the legs down at the "front" of the step.
This is analagous to us placing a foot forward, and steping down with our heel when we walk. The Propel stage actually moves the leg "back" and the robot forward. The Lift stage lifts the leg and returns it to the horizontal position where the next Plant will take place. The coordinated sequence is Plant Set 1, Lift Set 2, Propel Set 1, Plant Set 2, Lift Set 1, Propel Set 2, Repeat...
As far as individual steps go, as I was manipulating the legs with the PSCI I also noticed that in an ideal world, the horizontal and ankle movement would be better coordinated so that each "Propel" stroke would be a straight line. To do this syncronization would require that the ramp speeds of the two servos were adjusted so that both servos started the strokes at the same time, and took the same time to make the full movement. As each servo will be making a different angular movement in most cases, this level of coordination is not practical with the gait engine used in the demo program. In addition to timing, it also helps with the coordination of the horizontal movement is all to one direction or the other of center. If the horzontal movement traverses the center point, the ankle would need to move one direction from the start of the stroke to the center, and then reverse direction for the balance of the stroke in order make a straigh line path.
To make the new gait pattern for the D2 (Odd directions) area, I determined that I would start with a 1.5 inch stroke. I then used the PSCI software to put the leg in a start position and move it to a finish position. The values from the PSCI need to be divided by 2 for use for the actual values passed to the PSC.
For the "center legs" I had the horizontal stroke go from center "back", and moved the ankle so that the start and end points were in a straight line parallel with the direction of travel. The "front" legs move from center back, and the "rear" legs from forward back to center.
I got the walking code basically working by doing the following:
I currently have "Raise" defined as 750 and "Lower" at 550. I initially tried 900 for the "Raise", but this made the robot appear to "stomp" more than was really necessary. If walking over uneven terrain, the higher leg lift (900) might work out better for getting over some obstacles.
The D1 data section for the "even" directions (in line with a leg) worked without further modifications.
The D2 data for the "odd" directions (heading in between legs) was re-worked from scratch. Initially, I had the "front" and "rear" sets of legs swing out to the sides (see Comments on Gait Design above), and then walk from there. This posed problems with changing directions, so I re-worked things so that the legs work from a centered postion.
The current code is not perfect, and the robot seems to move faster in the Even directions. I've gotten far enough, and have learned enough to move on, so I don't know if I'll do much more on this particular gait engine. The final current code can be viewed/downloaded from here: Nomad_Walking_Demo_RobotServos.bsp.