But while I wait for the order to come in… I wonder about a semi-software solution as well. That is our current code uses an Initial position for everything… I am wondering if maybe we could/should change this. Maybe turn the turn-on and turn-off code from simply turning on the servos to the new desired sequence and just turn off the servos into a multi-step sequence. Something like:
Turn robot on: Move servos to their assigned init locations. Then move to a desired working position, maybe using a quick tripod 4 gait or the like.
Turn RobotOff: Move servo to current neutral location and then move to startup position again maybe using gait to do this and then turn off servos…
This can also maybe be expanded on. That is each time we change the body height, it recalculates the best neutral position such that the last segment is vertical when touching the ground…
I got your point with the setup. I’m having the same problem with the hybrid. The Tibia is pretty long comparing to the Femur. This also doesn’t make it possible to totally close the legs while the body is on the ground. Also the long Tibia and short Femur makes it a bit chubby and doesn’t give the amount of freedom it should.
About the Hybrid, making the femur longer can easy be done with a long C bracket. This will also increase the total length of the leg so maybe I need to switch to stronger servos then…
I’m not sure If Jim is planning to bring those legs in production. If so, it should be a thing to see if they can be made a bit shorter…
About your setup kurt, I think jim’s idea about the offset brackets will be a good idea. I missed a lot of information the last few months so forgive me if I’m asking silly question but is it possible to shorten the (tibia)tube where the switch is located? This should also make it easier to use the switches for the 4DOF T-hex.
About the code, It’s a real mess with a lot of debug information and I’m not quite sure what the latest status is. Before I moved to my new home I bumped in a lot of math problems to solve the TA story. So that’s where I left my code, got back to the drawing-board and started focusing on the math. I’ll see what I can dig up.
Thanks, playing around with some random stuff right now. New parts should arrive next Tuesday…
Still playing around with the idea of a start-up sequence. I did something like this earlier with the Rover with Arm. When we first initialized the arm, I was having the arm hang up sometimes when it went from rest location to working location, so I put an intermediate startup which first moved it up some and then let it go to the desired location. I did this after having a servo break after it caught up…
On The Hex as well as hybrid, could do this with a fixed sequence. But I do think it might be nice to reconfigure the leg depending on the height we want it. Currently the code just uses the static values contained in InitPosX…Y…Z. Maybe instead we should reconfigure these tables from static word tables into actual computed arrays… Maybe only when the Y changes over a certain delta… So we are not constantly doing this. With this we could have the code such that the foot is logically always flat when the leg is down… Starting to play with the Math and Pep. I think I can start off doing something like:
Desired new Height: Y
The Y from Pep is computed normally something like: Y = FemurLengthCos(90-FemurAngle) + Tibia Lengthcos((90-FemurAngle)+(TibiaAngle - 90))
Note: the 90s cancel out if we want the foot flat we know the whole Tibialength will go into Y so we can compute the needed femur angle
FemurAngle =90 - ACOS(( Y-TibiaLength)/FemurLength)
From that we compute TibiaAngle = -90+FemurAngle
From this we can compute the Z distance: < can fill in if interested…>
So now we have the desired height of the leg and extension, we should be able to use sin/cos to generate the InitPosX and InitPosZ arrays. I don’t think it would be good to simply try to move to these new positions as all of the legs would all drag on the ground… So probably some simple 4 step sequence move 3 legs than the other 3 legs…
Does this look about right? Do you think this is worth it? Or would simple sequences to start and stop be better, that way things like ATLAS could have a startup sequence to hatch and another sequence to get back into it’s egg…
A quick update: I am playing around with adjust the leg positions depending on the body height… I have hacked in a version into the DIY xbee code. I currently don’t do it automatically, but I added code that if I press the “9” key, it does the calculations I mentioned and then adjusts the Leg positions to get it upright. I did try adding code to make it try to move 1 unit in a direction to get it to do 1 set of steps, still need to do more there. Also did not update the single leg mode which still uses the initialX/Z positions… Also did not update the turn off code to restore the initial offsets before turning off…
In case anyone is interested:
; : trying to updating leg positions depending on height
XZLength1 var sword
FemurAngle1H var sword
TibiaAngle1H var sword
...
' We wish to play with the leg positions... to see if I can make them more up and down...
'The Y from Pep is computed normally something like:
' Y = FemurLength*Cos(90-FemurAngle)
' + Tibia Length*cos((90-FemurAngle)+(TibiaAngle - 90))
'Note: the 90s cancel out if we want the foot flat we know the whole Tibialength will go into Y
' so we can compute the needed femur angle
' FemurAngle =90 - ACOS(( Y-TibiaLength)/FemurLength)
'From that we compute TibiaAngle = -90+FemurAngle
GOSUB GetArcCos ((CHexInitY+BodyPosY-cTibiaLength) * c4DEC)/cFemurLength ]
FemurAngle1H = 900 - AngleRad4*180/3141 ; Convert to 1/10 degrees
TibiaAngle1H = FemurAngle1H - 900;
' now legs compute XZ value for how far the leg will be from the body given the above angles...
' should be: CoxaLen + sin(90-FemurAngle)*FemurLength
gosub GetSinCos[900 - FemurAngle1H]
XZLength1 = cCoxaLength + (sin4*cFemurLength )/c4dec ; get our length from body...
' now print this out and see if it looks right..
hserout HSP_DEBUG, "Y: ", sdec CHexInitY+BodyPosY-cTibiaLength, " FA: ", sdec FemurAngle1H, |
" TA:", sdec TibiaAngle1H, " XZ:", sdec XZLength1, " LMX", sdec LegPosX(cLM), 13];
; now lets see what happens when we change the leg positions...
for LegIndex = 0 to 5
gosub GetSinCos[cCoxaAngle1(LegIndex)]
LegPosX(LegIndex) = (cos4 * XZLength1)/c4dec ;Set start positions for each leg
LegPosZ(LegIndex) = -(sin4 * XZLength1)/c4dec
hserout HSP_DEBUG, "(", sdec LegPosX(LegIndex), ",", sdec LegPosZ(LegIndex),") "]
next
hserout HSP_DEBUG, [13]
bPacket(PKT_RJOYUD) = 127 ; Hack see if we can make it walk 1 step to get to new positions...
Note: the Hserouts, are debug only code, in this case on Arc32…
Kurt
I need to get back to the math… Today I noticed a simplified document mentioned on the Robot Forum, that describe some of the math for a 2dof arm… In case anyone is interested you can get it from: kidwaresoftware.com/robot.htm
I didn’t had any robotic time this weekend. I hope to have some free time tomorrow to figure out the body IK part. I’ve got some ideas about how to calculate the body centrepoint from 3 given points in space. Once that’s done it will be exiting to see if everything can be stuffed in the BAP.
I have not updated that the contact code in the last few days as I knew I would be partially rebuilding my robot when the parts arrive (UPS delayed a day - Train late?). The code to make the legs upright at different Ys appears to work pretty well, it should keep the needed pressure on the contacts to be less. Uses the gait engine to get into the new positions. (I move in one direction 1 unit > deadzone)… For the fun I may also play with a startup and shutdown sequence. Trying to figure out why in the DIY code when we shut down we clear a bunch of variables and then call ServoDriverStart/Commit. We don’t run through any of the leg or body calculations so the legs would move to where they already are…
As for code space - The Arc32 works nicely… Might need to work it that for basic Phoenix work a Bap28 can be used but to do more advanced things you need to move up to the Arc32. Later may convert mine back to bap. [size=50]Side note: code fits great on a Arduino Mega as well…[/size]
Kurt
Well I am now slowly rebuilding my Hex. I have a new shiny body to move things into
I am now in the process of rebuilding the legs. After mostly redoing one leg I do believe this will help make it such that the leg can stay closer into the body!
I pretty sure I know the answer, but … With the offset bracket, the angle has changed by 45 degrees, my assumption is that I need to compensate for this. So I think I am going to undo the servo horn and move it three clicks, but I don’t think that is the full correct answer.
That is with the offset bracket. I believe that I need to do the following:
Measure the new femur length. The length is the straight line between the center of the two servo pivot points or about: 58cm pretty close to the same as before.
Zero the femur servos again. The all need to go up some as the offset pushed the end of the femur to be lower than the end near the body. May have to update servo horn positions to make enough room.
Zero the tibia servos. Gut told me earlier that three clicks but may be different as we changed the femur…
Update all of the servo angle Min’s and Max’s.
Does this sound right? Have others done this and know how many ticks to do or are you cheating and using some other form of offsets… Now to find my protractor…
Your method sounds correct. Should be very simple; center all servos (femur+tibia), you might need to click the horn and align the femur axis - tibia axis - tars (tibia end) in the known horizontal and vertical position, then do the calibration.
I had some quality robot time this weekend. I worked on the math for the body IK. I can now subsitude pitch, yaw and X and Z positions from the body with 3 given coxa positions. With the bodyIK part being at 75% I only need to figure out the roll angle and Y position of the body. Then I can finally start implementing the bodyIK part and get the TA up and running. Give me a couple more weeks and this bot will walk over objects
I’ll give an update when the bodyIK is complete and fully tested.
Yep I am having some fun rebuilding the CHR-3 and making every mistake possible… Things like mounting the SSC-32 to the bottom plate, but in the wrong direction by 90 degrees… Moving all 6 legs plus the SSC-32 without unplugging the servos was a challange… But I have everything pretty well back in one piece. Still need to clean up some of the Medusa wiring on top. Pictures… Not anything new or exciting…
The offset brackets will definitely allow me to setup the initial position with the legs closer into the body, which will help!
Most of the Medusa wiring is for the 6 contact switches with LEDS. Need to clean them up sometime. Some other wires on top was because I am lazy. I know that I will need to do more servo offset fixing so I hooked up two 6" extensions to the RS232 jumpers on the SSC-32. When I wish for the SSC-32 to talk to the PC I simply connect these two extensions to each other and when I wish for the SSC-32 to talk to the BB2 (or in this case Arc32), I have another extension wire plugged into 2 IO pins + ground, that I connect to the appropriate cable going to the SSC-32. I was too lazy to find a DPDT switch… Tried then running the software only to find out that the new IDE has problems with HSERIAL… Backed up to using 2.0.0.0 and found that one of my saved offsets was lost, so need to go back and fix that one…
Kurt
P.S. Xan it sounds like you are making great progress on the math, will be fun to see it in action!
Interesting to see that you are combining the ARC-32 and the SSC-32. That combination sounds like a good alternative for my next project too since 31 servos occupies a lot of useful I/O’s on the ARC-32…
Where did you place the LED’s?
Btw, when using the wire mesh guard without using a heat shrinking tube on the end its a good idea to “seal” the end of the mesh guard using a lighter (carefully… ). EDIT: Seal the ends of the mesh guard right after cutting (before you start to cover the wires, of course.).
Thanks, I have been away from this for about a week, playing around with different things, but that one so far was a bust . So soon now!
Currently the LEDS are part(most) of the Medusa look. If you look at the first picture one is easy to see that is toward the front left of the cup another one you can see toward the switch on the left hand side… Not pretty but it shows me when the contact switch makes contact… Maybe someday will either mount the LEDS somehow in the body
The mesh looked better before, I sort-of sealed the sides and then zip tied them, but then I undid that part to redo the servos and the like to change from the the previous leg type to the new one with the contact switch and again when I redid with new bracket rewire contact switch… I don’t have a lighter, so how about a propane torch? Maybe someday I will redo them…
I am trying the Arc32 with the SSC-32 as it is an easy way to experiment with more code space, hardware serial port for debugging and if things work OK and I can reduce the code size back it would be easy to then drop a BB2 back in here with a Bap28. Yep it would free up some Pins on the Arc32, but you also have to remember that not all IO pins on the arc32 can be used for general IO, in particular pins 8-15 and 24-27 can only be used for servos are Analog input.
Hopefully in the next few days I will start playing again. With the new legs I do have the initial position changed and I have the servos zeroed out. The code that hitting the 9 key helps to get the legs back to straight up and down at the current body height appears to be working…
I shared my LegFK sub with yah. I just found out that it has some errors in it. I copied the sub from my hybrid test version of the code. I’m still debugging this part so hold on for an update.
Sounds good. I have not had a chance to play with it yet. I have been playing around with a few other sidetrack projects and it sounds like you are real close to having your stuff working so I was sort-of in a holding pattern.
. So soon now!
Maybe someday I will redo them…