xanadu wrote: »
I think I read about your dive trip in the news.
I have 10 of these - (PDF) http://www.vatronics.com/Upfiles/down/201171847057.pdf
They seem to have a long shaft, if you want I can send some to test out.
DiverBob wrote: »
Tough week so far. I've been having problems getting the HB25 motor controllers to cooperate. I have power going in to them and I'm using code that worked on the test leg but not now. Today I'll tear things apart to validate the power wiring and just power up a single controller.
All the other tests have gone well so far, ADC circuitry and code, RGB lighting and some other general use routines. I'm confused as to why I can't get any output from the motor controllers. I have all day today to figure this one out. It's snowing hard outside and inside seems to be the best place to hang out!
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
PST : "parallax serial terminal"
Pub main | sample
Waitcnt(clkfreq + cnt)
sample := adc.read(1, 1)
pst.str(string(pst#NL, "ADC: "))
waitcnt(clkfreq/100 + cnt)
erco wrote: »
Happy New Year, Bob! Great to see your continued enthusiasm and dedication to this giant project. I'm sure 2014 will see rapid progress to your bot. Just go easy in testing and I'm sure your bot will walk circles around Grant Imahara's hexapod! I think I hear Grant whisper an F-bomb in the video before he yells "phew". http://forums.parallax.com/showthread.php/151632-Spike-the-Spider-Robot?p=1231331&viewfull=1#post1231331
dbpage wrote: »
Have you considered applying the Proportional, Integral and Differential (PID) control algorithm to control the leg positions? Properly applied (which is an art), the "P" adjusts the speed of the motor in proportion to the travel distance, with closer being slower and further being faster. The "I" and "D" (used sparingly) can prevent over acceleration when, say, traveling downhill, and adjust for set point deltas. This would augment or replace your mx + b slope calculation, adding real-time adjustments to outside forces.
For whole body motion, have you considered the following theories in addition to Inverse Kinematics?
- non-holonomic motion planning
- Euler spirals, clothoids or Cornu spirals. (They're used in road/railway engineering to reduce centripetal acceleration on transition curves such as on/off ramps, etc.) https://en.wikipedia.org/wiki/Euler_spiral
I am thinking of the case when your robot begins to dance and rotate very quickly (or perhaps, run), causing centripetal acceleration resulting in issues with precise leg positioning.
Due to internal gearing backlash the motor may start but the ADC will not change for a significant time. This is most apparent when the motor reverses direction. The delay in getting an accurate position reading means the motor tends to overshoot the intended position and then trys to reverse direction to return. This causes the motor to 'hunt' back and forth. I am using a deadband to help reduce the occurance of this but this then reduces the precision that the motor can be postioned to. This will most likely be one of those items that is a trade-off between precision and hunting. Once weight is applied to the leg some of this should be reduced, I've tested this by putting some pressure on the leg
Zoot wrote: »
Our auto-pointing telesope takes into account backlash on direction changes by tracking which direction the motor *had* been moving before stopping. If there is a direction change when the motor restarts, then backlash is presumed when caclulating position (and in your case, you could disregard the lack of change from the ADCs for a short interval while the backlash works itself out). If the motor travels in the same direction it had been when restarting, the position is deemed accurate.