I like using FP, and you certainly will have to “round off” to uS for the servo pulse width!
FP can be costly in processor time. Look-up tables take up memory, and can only provided limited resolution.
A 4DOF leg is long! One should consider the linear resolution out at the tip of the foot desired, and work it back to an angular movement. This will be limited by the resolution of the servo. No use doing much more then 2X this resolution. Is this a degree? I don’t know off hand. But by using scaled integer math, say a word to handle the values right down to the pulse width value, which in order to be sent to the SSC32 (and what the servo actually resolves) is going to need a byte. Do the math!
Your calculation approach sounds correct. Use FP, carry out the calculations all the way down to the final byte for the PWM, and then optimize as needed. This way, you’ll be able to verify that your calculations are correct.
Xan’s current code is roughly 20k…I think when I was done modifying it it was 21k or something “this was after Zenta got done modifying the code before I monkeyed with it”
But that leaves you roughly 10k of program space for your lookup table.
I’m actually unsure what happens if you define all the variables in memory at initial start up like lets say 9k worth of variables what kind of delay you would see if for instance you had a led flash the moment after you defined the variables.
…
Would you even see a perceptual delay when initial turn on of the bot board?
One processor idea I had was to have a pda transmit data to the ssc32 via hard link or bluetooth wireless or strapped ontop of your robot. 400mhz-600mhz vs 16mhz? … you can be sloppy in code while your learning and optimize it later. you hit the 16mhz ceiling quite quickly!
Depends on the compiler and uP, but constants usually stay at some location above or below the code in Flash, variable data would be bulk copied from Flash into RAM, which doesn’t take very long at all. And this is all done in setup before control is passed to main (C description, but probably the same for Basic), so you’d be hard pressed to code in for an LED. We don’t really care about any initial start-up delay. It’s the real time delays that we’re worried about.
Yes, if you can develop code off-bot first you might have an advantage. Trouble is, embedded code like Atom Basic tends to be considerably different in that it has all the support for the hardware built-in, something that you can’t simulate easily on a PC or PDA! If you can abstract to only the high-level calculations that are independent of hardware, you might be OK.
10K is a huge table! the compiler might not even be able to handle it! The current practice exhibited in the Powerpod or Xan’s code is a 128 byte table. I suppose two tables, one expanded for more definition at one end of the sin/cos curve, and integrated together might be useful. I don’t know if I’ve seen an example of that or not. I’d prefer to use a compiler that has full ANSI floating point support, and sufficient power to use it.
Assuming the leg positions are fixed and (obviously) known, then some of the trig values that are calculated over and over again might be put into a table by leg, and that could considerably speed up the the calculations. And a symmetrical arrangement of legs suggests that many angles and even solutions will be either the same or simple mirror images, and hence there are additional calculation savings to be gained there.
Another thought (unproven), it might be possible to limit the number of steering angles that are calculated for, rather then a continuous range. Again, some canned values could suffice, saving calculations.
Well, I wouldn’t go so far as to be sloppy… but you’d have the room to test multiple solutions, and then decide on the best.
My comment about 10k was just to illustrate the amount of room left in the Atom after xan/zenta’s phoenix code which still leaves a lot of room for other stuff.
I think honestly there’s enough room for a look-up table with .5 degree accuracy, that would be more then plenty for small scale robots.
For the hardware that I have is
A Phoenix, Atom Pro, T7C transmitter and receiver with all 7 channels fed into the atom pro reading via Pulsin and some code zenta sent me that Ive been modifying the last couple months doing individual leg control and tossing ideas into it seeing what i can get it to do.
doing pulsin reads however really sucks cpu time to the point where I can physically start seeing issues with the gait when the cpu stumbles around, which is why this lookup table seems to be the hot ticket, might actually make terrain adaption 100% smoother.
Sorry for the off topic post, but I wanted to let you know we are working on a device, the RC Reader, that grabs up to 8 channels of RC pulses and converts to high speed serial TTL data that can be quickly read from an Atom. Another I/O pin to let you know if data has changed. This will simplify things, or at least speed them up. Still in prototype stage. No ETA.
I definitely think so. Using a syncwrite, you can set the position of 24 servos in only 54 bytes, at 1MBps and 50Hz syncwrites thats only about 2.5% of the channel’s capacity. There’s quite a few videos of Issy running around on youtube: youtube.com/user/lnxfergy
Reading back data is always a little slower than writing data on the AX-12, but you can’t even do that with an HS645…
Issy was built for mech warfare 2009. He uses 12 AX-12 servos, a number of bioloid brackets, and SES brackets and tubes for the leg uprights. He’s powered by an AVR-based arbotiX robocontroller. I’m using a pair of XBEE radios to control him (either through my PC, or handheld controller that I built). Power comes from an 11.1V Lipo.
About the wires, yep, I leave him plugged in while running around the lab, although his 11.1V Lipo (2200mAH) gives about 40-60 minutes of runtime (when he’s not carrying all of that mech gear).
As for the bioloid brackets, they are just fine in plastic - it’s a very durable plastic. I’ve only broken one bracket, it was intentional, and I had a really hard time getting it to snap (I had a screw strip out doing something stupid, and the only way to get it out was to snap the bracket around it…)
I’ve still quite a few plans for Issy. I’m currently building a smaller center chassis and different leg uprights to scale him down a little, in order to fit the rules for the Trinity Fire Fighting Competition. His IK implementation is slowly coming along…
