Here is a link to a short video of the feedback loop from the leg controller to the master computer in action. The information from the leg controller is sent back to the master computer using a format of '$,1,2,3' where 1 is the leg number, 2 is the item, and 3 is the command. So a entry of '$,6,2,6' tells the master computer that leg 6 Tibia is moving out. The 6 command correlates to the color Yellow in this instance. Each leg has 4 RGB LEDs assigned to it. 3 LEDs are used for showing leg information, mainly leg direction and error conditions. The 4th LED is used for general purposes such as when the leg down switch is activated. Right now it shows either yellow (one of the motors is in motion) or green (all motors are stopped, waiting for next command).
Time to start to test another leg controller and then attach the another leg to the body. The current master computer is hardwired for a single leg since that has been my focus so it is time to also modify the code for multiple legs. It may be time to put the base Leg Inverse Kinematics code in the master computer and start learning about how to best implement that code.
Bob: Did you ever make a small scale bot with servos, or did you jump right in full size?
I've done a few small robots using gear motors but never did any with servos. This hexapod is much bigger and more complex than anything I've tried before. It's been mostly fun so far, I've learned new things, meet and talked to a lot of people I wouldn't have met otherwise.
No posting for last week since I was indulging myself in my other hobby, this time it was diving under the ice in one of the local lakes! However, over the week I got to working on the tedious job of soldering sensor connectors to the 3 pin servo connectors that connect into the RoboPi leg controllers. 2 are completed, 4 to left to finish.
I also started back into my research into Invererse Kinematics (IK) by reviewing code from several people that have implemented it into their Hexapods. Since I'm using Paul Krasinski's transmitter, I plan on adapting his hexapod's IK code (which is written in SPIN) for my needs. I've spent the last couple of days reviewing Paul's and other implementations of IK code and have seen that the core of IK code is very similar in each file. I have a lot of work cut out for me as I want to understand the reasons for some of the common code elements I'm seeing as some of it isn't obvious to me. The trig for determining the X, Y and Z positions of the foot is straight forward but I haven't been able to wrap my mind around how it integrates into the gait control. Time for more reading and studying. Sometimes I feel I'm just on the verge of having the lightbulb light up but so far it's been just flickering! It doesn't help that the coordinate system that everyone uses is different as I'm used to seeing for running my CNC tools!
I would like to slowly add elements of the code to my code, see the results and then slowly add more. I want to understand how everything integrates together otherwise I won't be getting meaningful output. It would be too easy to not add in things that are required for proper operation.
The 2nd leg is attached, haven't tested it in place yet, need to write a new calibration program to get all the ADC readings for each axis. Got to wire in a couple of switches so I can manually move the axis to their extreme positions and take the readings.
No photos this week unless you want to see my soldering bench. Will be working on more soldering when I get tired of studying.
Slowly putting some IK calculations into the program. Been spending some time troubleshooting values that don't make sense right now. I'm not at the point of hooking up the leg controller, got to get some data out that makes sense first. Its slow but I'm getting there.
Thanks for the encouragement! After getting a good nights sleep, I'm ready to hit the programing after I get back from my morning Raquetball session! Got some ideas to try out for making sense of the numbers.
I think my numbers problem may just be a display issue as I'm working with long variables in floating math. So there may be some conversion issues instead of actual problems. I tend to remember seeing something like this a long time ago but don't remember what the fix was. It had something to do with using the UART's .DEC() command when transmitting the float value back to the monitor. Do you need to truncate the float before transmission? If I don't hear anything here, I'll have to check some old code and see if I still have an example somewhere.
Bob I don't know if this will help but here is a snippet of code I use to read floating point #'s from a sensor to use with Spin.
Edit: A floating point long has 4 bytes to be transmitted - this sensor is transmitting the most significant byte first.
repeat l from 0 to 2
a := fds.rx
b := fds.rx
c := fds.rx
d := fds.rx
case l
0 : h := a << 24 | b << 16 | c << 8 | d 'roll x sensor x
1 : j := a << 24 | b << 16 | c << 8 | d 'yaw z " y
2 : k := a << 24 | b << 16 | c << 8 | d 'pitch y " z
X_Axis := fm.fround(fm.fmul(h, SENSOR_SCALE)) 'this matches jasons itg gyro oreintation igx, igy, igz xaxis
Z_Axis := fm.fround(fm.fmul(j, SENSOR_SCALE)) 'to 3space module 11/28/13 zaxis
Y_Axis := fm.fround(fm.fmul(k, SENSOR_SCALE))
Bob I don't know if this will help but here is a snippet of code I use to read floating point #'s from a sensor to use with Spin.
Edit: A floating point long has 4 bytes to be transmitted - this sensor is transmitting the most significant byte first.
repeat l from 0 to 2
a := fds.rx
b := fds.rx
c := fds.rx
d := fds.rx
case l
0 : h := a << 24 | b << 16 | c << 8 | d 'roll x sensor x
1 : j := a << 24 | b << 16 | c << 8 | d 'yaw z " y
2 : k := a << 24 | b << 16 | c << 8 | d 'pitch y " z
X_Axis := fm.fround(fm.fmul(h, SENSOR_SCALE)) 'this matches jasons itg gyro oreintation igx, igy, igz xaxis
Z_Axis := fm.fround(fm.fmul(j, SENSOR_SCALE)) 'to 3space module 11/28/13 zaxis
Y_Axis := fm.fround(fm.fmul(k, SENSOR_SCALE))
After doing some more experimentation today I figured out that I'm not getting the right input values, thus bogus outputs. This was found by running through the IK calcs with a calculator and seeing the output there vs the displayed values. I started to back out of this code and rather than trying to adapt Paul's code to my hex, I'm starting with writing a very basic IK routine where I fully understand the calculations. I may even manually put a leg in a specific location and take the X,Y coordinates from that and use those to troubleshoot. Either way its time to stop, my mind has turned to mush and I'm making too many mistakes to make it worthwhile. I've got to hit it in the morning and go on until the SuperBowl starts. Since we are supposed to get a good snowstorm tonight, it'll be easier to stay home!
Taking a break now but I figured out what I was doing wrong. The test values for the height were not valid, the numbers I used were out of the range of the trig calculations. Trig is all about triangles, the triangle I was describing doesn't exist!
I did some measurements on the test leg this morning, got a valid height number based on the actual height, plugged this number into the calcs by hand and got valid outputs! I then manually calculated some specific movement values for a 1 inch change of foot position and got values that make sense. A problem that I can see right now is that my leg controller works on whole angle numbers and I was getting most of my angle changes in a tenth of a degree. I can get leg responses down to single degree movements for the tibia and femur. The Coxa doesn't give me even that level of response, it takes a 2-3 degree change in the input to get a response. The only way to fix this that I can think of is to change the feedback pot from measuring the actual Coxa movement and measure the motor rotation instead. That would give a better range of values for the feedback loop.
I'm going to continue on with the programming and see how well everything moves with the IK added, run a few tests and see how smooth the action is. Next thing is to program in the calculations. Taking some time for lunch and then back into the basement until the next break, which will be shoveling about 4-6 inches of snow off the driveway.
IK is certainly a mind boggling subject. I want to remind you of the equations I posted in my mini hexapod thread. I also posted the Spin code interpreting the equations.
I'll need to review the geometry of your robot, because I'm not sure the joints are the same as most servo hexapods.
I just watched the video in post #27. I don't think the usual IK equations are going to work for your robot. I think some of the length constants used in the IK formulas need to be converted to length variables since the geometry of your leg is so different.
Do you have a diagram showing the leg movements? I'm willing to help a bit (if you want it) trying to come up with some IK code to move your legs but my attempts to derive my own IK equations fell short and I ended up using the equations I linked to above. Maybe these IK equations can be modified so they can be applied to your legs' geometries? I'm willing to give it a try.
IK is certainly a mind boggling subject. I want to remind you of the equations I posted in my mini hexapod thread. I also posted the Spin code interpreting the equations.
I'll need to review the geometry of your robot, because I'm not sure the joints are the same as most servo hexapods.
I just watched the video in post #27. I don't think the usual IK equations are going to work for your robot. I think some of the length constants used in the IK formulas need to be converted to length variables since the geometry of your leg is so different.
Do you have a diagram showing the leg movements? I'm willing to help a bit (if you want it) trying to come up with some IK code to move your legs but my attempts to derive my own IK equations fell short and I ended up using the equations I linked to above. Maybe these IK equations can be modified so they can be applied to your legs' geometries? I'm willing to give it a try.
I'd sure like to see your robot up and walking.
Just did a second check of my equations using MS Excel to model the formulas and values, luckily came up with the same results!
Any volunteered help is accepted! Here are the leg constants I'm working with (in inches):
Coxa: 2.6
Femur: 6.0
Tibia: 24.6
I came up with my own drawings of the leg but after a lot of reflection I decided that the leg parts, the way they connect, and the angles are still the same as the standard servo driven Hexapod. I just have to look at the main pivot point on the leg, the knee from the femur and tibia to get essentially the same layout. The parallogram below these parts can can be ignored for the calculations. The motors are in different locations but they cause the same movements as a directly connected servos. I'll post my IK formulas and drawing after I program them in and tested. My formulas are then the same as everyone else's, I changed some of the variable names around to make more sense to me.
Haven't gotten much further than the last posting, the float math is kicking my butt. I've gotten all the formulas written down and test by hand but the output from the programmed calculations isn't what I expect. I'm troubleshooting by sending the float variables to the monitor serially. The displayed numbers are not coming up correctly so I'm having issues continuing the troubleshooting. Can anyone recommend a good propellor object for displaying float values correctly on a terminal?
It doesn't help that I had a violent encounter with a racquetball racquet earlier this week resulting in an ER visit, lots of stitches tony lip and 2 missing front teeth. The pain meds make my head a bit fuzzy so it's harder to concentrate on the programming side. I may have to take a break for a while until the dental reconstruction work gets done and I get back from vacation. I was hoping to have the basic IK in and tested so I could start working on programming the tripod gait before I left.
The morning meds are starting to kick in so time to take a break and find something mindless to do for a while.
At this point I may just cut and paste Duane's IK solution in and see how that works out.
Can anyone recommend a good propellor object for displaying float values correctly on a terminal?
Using FloatString.spin's floattostring(x) method will print floating point #'s to the terminal. Hope this helps.
Edit: Regarding IK I defer to anyone else.
Con
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
Obj
pst : "Parallax Serial Terminal"
fs : "FloatString"
Var
long x
Pub Main
pst.start(115_200)
x := 0.25
pst.Str(fs.floattostring(x))
Using FloatString.spin's floattostring(x) method will print floating point #'s to the terminal. Hope this helps.
Thanks for the suggestion, I forgot all about that object. That got me poking around the OBEX and I saw the F32 code for FP calcs and read up on the threads on it. Started to do some testing using these objects and am now getting some consistent results that match my manual calculations. Taking a short break for dinner and then I'll put in the more difficult calculations and see what I come up.
Sorry to hear about your injury. It sure sounds awful. I hope the pain subsides soon.
I don't know how you're doing with your program size. I was starting to run low on RAM in my hexapod and so I tried moving the PASM sections of several objects to EEPROM. This is a technique I've wanted to try for a while but this is the first time I've actually done it. It ended up working pretty well. The call table used by F32 presented an extra challenge since it requires being compiled with the PASM section. I got around this by copying the compiled table to the terminal and then using the output from the terminal as the new call table.
Moving PASM to and from EEPROM is a bother so I wouldn't suggest it unless you're running short of RAM. Remember to leave a couple of hundred of "Free/Stack" longs in your program so cog #0 has room to work.
Make sure and let us know if we can help with the IK stuff. I'm working on adding tilt to my IK code so hopefully my mind will be back into trigonometry mode soon.
I just remembered something. Excel's ATan2 function and F32's ATan2 function take the x and y inputs in reverse order from each other. Maybe this is why your numbers don't agree between the PC and the Propeller?
Sorry to hear about your injury. It sure sounds awful. I hope the pain subsides soon.
I don't know how you're doing with your program size. I was starting to run low on RAM in my hexapod and so I tried moving the PASM sections of several objects to EEPROM. This is a technique I've wanted to try for a while but this is the first time I've actually done it. It ended up working pretty well. The call table used by F32 presented an extra challenge since it requires being compiled with the PASM section. I got around this by copying the compiled table to the terminal and then using the output from the terminal as the new call table.
Moving PASM to and from EEPROM is a bother so I wouldn't suggest it unless you're running short of RAM. Remember to leave a couple of hundred of "Free/Stack" longs in your program so cog #0 has room to work.
Make sure and let us know if we can help with the IK stuff. I'm working on adding tilt to my IK code so hopefully my mind will be back into trigonometry mode soon.
I just remembered something. Excel's ATan2 function and F32's ATan2 function take the x and y inputs in reverse order from each other. Maybe this is why your numbers don't agree between the PC and the Propeller?
Today the swelling and pain has gone down considerably so I only had one pain pill, left me with a much clearer head also!
I got all my Prop-generated numbers to match my manual numbers finally! Now I need to copy the test code into the master prop. Found out that my Activity board isn't responding anymore, power lights aren't even on. Time for some more troubleshooting! In the meantime I luckily had another Activity board so I was able to plug that in to do my testing. I need to move all the wiring over to the new board so I can figure out what happened with the old board.
I read your other thread on moving data to EEPROM, sounds intriguing. I will be coming back to you later if that starts to become an issue.
Duane, one of the many things that still get me is setting up the gait. On your hex, if X is the direction of travel then Y is the distance the foot is from the Coxa. How are you setting the total step length (X), and are you then breaking the X value into a series of discrete motions? Or am I completely off in left field? I've been studying Paul K. Spin code but it hasn't sunk in yet, wondered if you might have a nugget that will set off the lightbulb in my head....
Duane, one of the many things that still get me is setting up the gait. On your hex, if X is the direction of travel then Y is the distance the foot is from the Coxa. How are you setting the total step length (X),
I define the step length as a multiple of other leg parts.
' Leg Frame
F_DEFAULT_X = F_COXA + F_FEMUR
F_DEFAULT_Y = 0.0
F_DEFAULT_Z = F_TIBIA
F_DEFAULT_STRIDE_LENGTH = F_DEFAULT_X * 0.7 '2.0 ' Stride is now distance traveled after one
' full cycle.
I could define the stride length as some distance in millimeters but by defining it in terms of leg sections, I can more easily share the code between my large hexapod and my small one.
I had started with the stride being twice the length of the coxa plus femur but the legs kept hitting against each other. The "0.7" is still probably too long since at full speed (when the stride is also full length) the legs still bump against each other.
and are you then breaking the X value into a series of discrete motions?
I am. The program calculates the x, y and z coordinates for each foot at 50Hz. This is what I call the "Path" loop. The path loop calculates where the feet should be.
I originally intended to have the feet move in an arc if the robot was moving in an arced path but the math was frying my brain so I resorted to just having the initial and final positions on a step fall on the arc's surface.
The points in between the initial and final positions are computed with a simple linear equation.
I think my type of robot control strategy is more math intensive than whatever is considered "normal". Years ago, I did some computer animation and rather than using the usual keyframes to define an objects motion, I wanted to compute the position of each part in a frame from some algorithm.
Each "frame" of my hexapod's animation is computed based on some algorithm. I'm not sure if this is the best way to control robots but so far, I like the outcome.
Or am I completely off in left field? I've been studying Paul K. Spin code but it hasn't sunk in yet, wondered if you might have a nugget that will set off the lightbulb in my head....
I think Paul's results show his code works well. I purposefully haven't spent much time looking at Paul's code since I wanted to figure out how to do this myself.
I haven't posted my code since in it's present state it's a convoluted mess. I'm willing to post my hexapod code warts and all if you or anyone else would like me to. I have a feeling I'll be posting my code in the next couple of days. I may just put it up on my GitHub repository.
I've decided to post the code I used in the last YouTube video since it was reasonable stable. I'll post it to my hexapod thread right after making this post.
Thanks for the code information Duane! I'll be reviewing it on vacation during my slow times! So there won't be much updating of my code for a bit. But, I know I'll still be studying yors and Paul's code. Maybe with enough time it will all come together and I'll get that Aha moment where it all becomes crystal clear! I've powered down and disconnected the lab and machine shop, no more programming for a while, time to think about warm water, lots of scuba diving and underwater photos to add to my collection.
I had some spare time on vacation and was just checking the Robotics forum for new stuff and saw this thread has hit over 50,000 views since I started this in 2011! I never expected to see this much interest in my little project or people willing to follow along with my ramblings for so long.
The original 3 year project plan isn't too far off schedule. The first year was prototyping a test leg, 2nd year was the primary build of all legs and body (with some anodizing sneaking in there too) and the 3rd year was to be programming. Well, the programming is taking longer than originally expected but is still coming along and I'm into year 4 now. The individual leg program is in good shape, communications between the master and slave computers is basically figured out. Now it's time to introduce then inverse kinematics part into the master computer and getting multiple legs to coordinate with each other.
After I get back it will be time to hit the spin code hard and get things moving along. I would like to see the first steps taken before summer so I can train it to climb stairs soon afterwards. That's about the only way to get it out of the basement short of disassembling it! The trick will be teaching it to get into the back of the SUV on its own so it can go on trips!
Time to return to warm water and diving, see you next week!
I'm having to follow your project to live vicariously. Too many projects going on outside my machine shop and workbench to get anywhere with my bot. I swear, a house will try to bury you financially sometimes. It's never one thing that goes wrong, it's 5, and they all either require weeks of time or 3+ zeros to fix.
I've loved following this thread. Keep the updates coming!
... I would like to see the first steps taken before summer so I can train it to climb stairs soon afterwards. That's about the only way to get it out of the basement short of disassembling it! The trick will be teaching it to get into the back of the SUV on its own so it can go on trips!...
Yes. Size does matter. Weight also. I guess air travel is out of question. Alas I would like to see a video of it walking towards TSA guys...
Hi Bob
I've been following you all the way on this project.
Have you started thinking about the rubber water isolation socks that fit over your bot?
A video of your bot walking on the floor of the big lake would absolutely make my day!
Hi Bob
I've been following you all the way on this project.
Have you started thinking about the rubber water isolation socks that fit over your bot?
A video of your bot walking on the floor of the big lake would absolutely make my day!
Nice thought! Actually it should be able to walk through at least 24" of water before the leg down sensor gets wet. Beyond that it's beyond design basis... I'm just about done with vacation, 21 days in Maui with lots of diving, whale watching, eating lots of fish, have done me in! Ready to get back to the real world and my toys. Time to get some programming done instead of just reading about it.
Back from vacation but saw a neat item at Trossen Robotics, a low cost LIDAR unit. So I just had to get one and a pan-tilt mechanism to mount it on. I put it together tonight, saving powering it up for this weekend when I have more time. I saw in the Sensor forums that some people have already tried this out, I'll use their code to get it started.
I want to mount this inside the 1 ft diameter clear acrylic 'head' that goes on top of the robot. The pan and tilt module is less than 5" tall, I need to add another 3 inches to the base to get it aligned with the centerline of the head. The pan-tilt unit seems fairly well made and light weight, it came with servos, plenty of hardware, and even metric Allen wrenches for the bolts. The LIDAR unit is very small, runs on 5v with a max range of 40 meters. That's a lot more distance than I need even if I have the robot outside.
My next steps this weekend is to power everything back up and check out the last version of the IK equations again. It's time to program in a way to manually enter the x,y, z values from the serial monitor and see how the leg moves. After that, check on the repeatability for a given position. This will let me know how accurately my leg controller software is responding. If all goes well, getting the radio transmitter joysticks to transmit the x and z positions with a potentiometer controlling the y (height). I don't suspect I'll get all that done this weekend but it's a basic plan.
It's always fun to come back to old code after you haven't played with it a while. In this case I saw that I'd saved the working code to EEPROM as the monitor immediately displayed the expected outputs. However, when I went looking for the actual code on the computer, I couldn't find the original spin file. So it was like starting over again. I finally got the code running all the IK equations with the expected outputs for the manually entered inputs. I created a new test file and verified it was saved in the expected folder with a name that is fairly obvious even to me.
Now, back to the original plan, set up the ability to enter from the terminal the desired x,y,z values and verify the output. Then I'll be ready to copy this code back into the master controller code and start doing the same test with the leg moving to the input values.
Didn't get around to playing with the LIDAR unit, I think this is a neat gadget that fits right in with the hexapod. I'll see if I can give it some time during the week.
Comments
Time to start to test another leg controller and then attach the another leg to the body. The current master computer is hardwired for a single leg since that has been my focus so it is time to also modify the code for multiple legs. It may be time to put the base Leg Inverse Kinematics code in the master computer and start learning about how to best implement that code.
Progress!
I also started back into my research into Invererse Kinematics (IK) by reviewing code from several people that have implemented it into their Hexapods. Since I'm using Paul Krasinski's transmitter, I plan on adapting his hexapod's IK code (which is written in SPIN) for my needs. I've spent the last couple of days reviewing Paul's and other implementations of IK code and have seen that the core of IK code is very similar in each file. I have a lot of work cut out for me as I want to understand the reasons for some of the common code elements I'm seeing as some of it isn't obvious to me. The trig for determining the X, Y and Z positions of the foot is straight forward but I haven't been able to wrap my mind around how it integrates into the gait control. Time for more reading and studying. Sometimes I feel I'm just on the verge of having the lightbulb light up but so far it's been just flickering! It doesn't help that the coordinate system that everyone uses is different as I'm used to seeing for running my CNC tools!
I would like to slowly add elements of the code to my code, see the results and then slowly add more. I want to understand how everything integrates together otherwise I won't be getting meaningful output. It would be too easy to not add in things that are required for proper operation.
The 2nd leg is attached, haven't tested it in place yet, need to write a new calibration program to get all the ADC readings for each axis. Got to wire in a couple of switches so I can manually move the axis to their extreme positions and take the readings.
No photos this week unless you want to see my soldering bench. Will be working on more soldering when I get tired of studying.
Watching with great interest. I'm sure there are others watching in awe while you do this great project.
It has to be the greatest mechanical project combined with the Propeller.
Sorry I can't help with IK or PID. I'm still in the learning stage myself.
Keep up the great work!
Jim
I think my numbers problem may just be a display issue as I'm working with long variables in floating math. So there may be some conversion issues instead of actual problems. I tend to remember seeing something like this a long time ago but don't remember what the fix was. It had something to do with using the UART's .DEC() command when transmitting the float value back to the monitor. Do you need to truncate the float before transmission? If I don't hear anything here, I'll have to check some old code and see if I still have an example somewhere.
Edit: A floating point long has 4 bytes to be transmitted - this sensor is transmitting the most significant byte first.
repeat l from 0 to 2 a := fds.rx b := fds.rx c := fds.rx d := fds.rx case l 0 : h := a << 24 | b << 16 | c << 8 | d 'roll x sensor x 1 : j := a << 24 | b << 16 | c << 8 | d 'yaw z " y 2 : k := a << 24 | b << 16 | c << 8 | d 'pitch y " z X_Axis := fm.fround(fm.fmul(h, SENSOR_SCALE)) 'this matches jasons itg gyro oreintation igx, igy, igz xaxis Z_Axis := fm.fround(fm.fmul(j, SENSOR_SCALE)) 'to 3space module 11/28/13 zaxis Y_Axis := fm.fround(fm.fmul(k, SENSOR_SCALE))After doing some more experimentation today I figured out that I'm not getting the right input values, thus bogus outputs. This was found by running through the IK calcs with a calculator and seeing the output there vs the displayed values. I started to back out of this code and rather than trying to adapt Paul's code to my hex, I'm starting with writing a very basic IK routine where I fully understand the calculations. I may even manually put a leg in a specific location and take the X,Y coordinates from that and use those to troubleshoot. Either way its time to stop, my mind has turned to mush and I'm making too many mistakes to make it worthwhile. I've got to hit it in the morning and go on until the SuperBowl starts. Since we are supposed to get a good snowstorm tonight, it'll be easier to stay home!
I did some measurements on the test leg this morning, got a valid height number based on the actual height, plugged this number into the calcs by hand and got valid outputs! I then manually calculated some specific movement values for a 1 inch change of foot position and got values that make sense. A problem that I can see right now is that my leg controller works on whole angle numbers and I was getting most of my angle changes in a tenth of a degree. I can get leg responses down to single degree movements for the tibia and femur. The Coxa doesn't give me even that level of response, it takes a 2-3 degree change in the input to get a response. The only way to fix this that I can think of is to change the feedback pot from measuring the actual Coxa movement and measure the motor rotation instead. That would give a better range of values for the feedback loop.
I'm going to continue on with the programming and see how well everything moves with the IK added, run a few tests and see how smooth the action is. Next thing is to program in the calculations. Taking some time for lunch and then back into the basement until the next break, which will be shoveling about 4-6 inches of snow off the driveway.
I'll need to review the geometry of your robot, because I'm not sure the joints are the same as most servo hexapods.
I just watched the video in post #27. I don't think the usual IK equations are going to work for your robot. I think some of the length constants used in the IK formulas need to be converted to length variables since the geometry of your leg is so different.
Do you have a diagram showing the leg movements? I'm willing to help a bit (if you want it) trying to come up with some IK code to move your legs but my attempts to derive my own IK equations fell short and I ended up using the equations I linked to above. Maybe these IK equations can be modified so they can be applied to your legs' geometries? I'm willing to give it a try.
I'd sure like to see your robot up and walking.
Just did a second check of my equations using MS Excel to model the formulas and values, luckily came up with the same results!
Any volunteered help is accepted! Here are the leg constants I'm working with (in inches):
Coxa: 2.6
Femur: 6.0
Tibia: 24.6
I came up with my own drawings of the leg but after a lot of reflection I decided that the leg parts, the way they connect, and the angles are still the same as the standard servo driven Hexapod. I just have to look at the main pivot point on the leg, the knee from the femur and tibia to get essentially the same layout. The parallogram below these parts can can be ignored for the calculations. The motors are in different locations but they cause the same movements as a directly connected servos. I'll post my IK formulas and drawing after I program them in and tested. My formulas are then the same as everyone else's, I changed some of the variable names around to make more sense to me.
Bob
It doesn't help that I had a violent encounter with a racquetball racquet earlier this week resulting in an ER visit, lots of stitches tony lip and 2 missing front teeth. The pain meds make my head a bit fuzzy so it's harder to concentrate on the programming side. I may have to take a break for a while until the dental reconstruction work gets done and I get back from vacation. I was hoping to have the basic IK in and tested so I could start working on programming the tripod gait before I left.
The morning meds are starting to kick in so time to take a break and find something mindless to do for a while.
At this point I may just cut and paste Duane's IK solution in and see how that works out.
Using FloatString.spin's floattostring(x) method will print floating point #'s to the terminal. Hope this helps.
Edit: Regarding IK I defer to anyone else.
I don't know how you're doing with your program size. I was starting to run low on RAM in my hexapod and so I tried moving the PASM sections of several objects to EEPROM. This is a technique I've wanted to try for a while but this is the first time I've actually done it. It ended up working pretty well. The call table used by F32 presented an extra challenge since it requires being compiled with the PASM section. I got around this by copying the compiled table to the terminal and then using the output from the terminal as the new call table.
Moving PASM to and from EEPROM is a bother so I wouldn't suggest it unless you're running short of RAM. Remember to leave a couple of hundred of "Free/Stack" longs in your program so cog #0 has room to work.
Make sure and let us know if we can help with the IK stuff. I'm working on adding tilt to my IK code so hopefully my mind will be back into trigonometry mode soon.
I just remembered something. Excel's ATan2 function and F32's ATan2 function take the x and y inputs in reverse order from each other. Maybe this is why your numbers don't agree between the PC and the Propeller?
Today the swelling and pain has gone down considerably so I only had one pain pill, left me with a much clearer head also!
I got all my Prop-generated numbers to match my manual numbers finally! Now I need to copy the test code into the master prop. Found out that my Activity board isn't responding anymore, power lights aren't even on. Time for some more troubleshooting! In the meantime I luckily had another Activity board so I was able to plug that in to do my testing. I need to move all the wiring over to the new board so I can figure out what happened with the old board.
I read your other thread on moving data to EEPROM, sounds intriguing. I will be coming back to you later if that starts to become an issue.
Duane, one of the many things that still get me is setting up the gait. On your hex, if X is the direction of travel then Y is the distance the foot is from the Coxa. How are you setting the total step length (X), and are you then breaking the X value into a series of discrete motions? Or am I completely off in left field? I've been studying Paul K. Spin code but it hasn't sunk in yet, wondered if you might have a nugget that will set off the lightbulb in my head....
Bob Sweeney
I define the step length as a multiple of other leg parts.
' Leg Frame F_DEFAULT_X = F_COXA + F_FEMUR F_DEFAULT_Y = 0.0 F_DEFAULT_Z = F_TIBIA F_DEFAULT_STRIDE_LENGTH = F_DEFAULT_X * 0.7 '2.0 ' Stride is now distance traveled after one ' full cycle.I could define the stride length as some distance in millimeters but by defining it in terms of leg sections, I can more easily share the code between my large hexapod and my small one.
I had started with the stride being twice the length of the coxa plus femur but the legs kept hitting against each other. The "0.7" is still probably too long since at full speed (when the stride is also full length) the legs still bump against each other.
I am. The program calculates the x, y and z coordinates for each foot at 50Hz. This is what I call the "Path" loop. The path loop calculates where the feet should be.
I originally intended to have the feet move in an arc if the robot was moving in an arced path but the math was frying my brain so I resorted to just having the initial and final positions on a step fall on the arc's surface.
The points in between the initial and final positions are computed with a simple linear equation.
PUB LineAlgorithm(legIndex) | fFrame frameCount[legIndex]++ 'fFrame := F32[PATH].FFloat(frameCount[legIndex]) if frameCount[legIndex] == activePeriod frameCount[legIndex] := 0 fTargetX[legIndex] := fInitX[legIndex] fTargetY[legIndex] := fInitY[legIndex] fTargetZ[legIndex] := fInitZ[legIndex] elseif frameCount[legIndex] < halfPeriod fFrame := F32[PATH].FFloat(frameCount[legIndex]) fTargetX[legIndex] := F32[PATH].FAdd(fInitX[legIndex], F32[PATH].FMul(fFrame, fDxGround[legIndex])) fTargetY[legIndex] := F32[PATH].FAdd(fInitY[legIndex], F32[PATH].FMul(fFrame, fDyGround[legIndex])) fTargetZ[legIndex] := F32[PATH].FAdd(fInitZ[legIndex], F32[PATH].FMul(fFrame, fDzGround[legIndex])) elseif frameCount[legIndex] == halfPeriod fTargetX[legIndex] := fFinalX[legIndex] fTargetY[legIndex] := fFinalY[legIndex] fTargetZ[legIndex] := fFinalZ[legIndex] elseif frameCount[legIndex] < threeQuarterPeriod fFrame := F32[PATH].FFloat(frameCount[legIndex] - halfPeriod) fTargetX[legIndex] := F32[PATH].FSub(fFinalX[legIndex], F32[PATH].FMul(fFrame, fDxGround[legIndex])) fTargetY[legIndex] := F32[PATH].FSub(fFinalY[legIndex], F32[PATH].FMul(fFrame, fDyGround[legIndex])) fTargetZ[legIndex] := F32[PATH].FSub(fFinalZ[legIndex], F32[PATH].FMul(fFrame, fDzUp[legIndex])) elseif frameCount[legIndex] == threeQuarterPeriod fFrame := F32[PATH].FFloat(frameCount[legIndex] - halfPeriod) fTargetX[legIndex] := F32[PATH].FSub(fFinalX[legIndex], F32[PATH].FMul(fFrame, fDxGround[legIndex])) fTargetY[legIndex] := F32[PATH].FSub(fFinalY[legIndex], F32[PATH].FMul(fFrame, fDyGround[legIndex])) fTargetZ[legIndex] := fMidStepZ[legIndex] else fFrame := F32[PATH].FFloat(frameCount[legIndex] - halfPeriod) result := F32[PATH].FFloat(frameCount[legIndex] - threeQuarterPeriod) fTargetX[legIndex] := F32[PATH].FSub(fFinalX[legIndex], F32[PATH].FMul(fFrame, fDxGround[legIndex])) fTargetY[legIndex] := F32[PATH].FSub(fFinalY[legIndex], F32[PATH].FMul(fFrame, fDyGround[legIndex])) fTargetZ[legIndex] := F32[PATH].FAdd(fMidStepZ[legIndex], F32[PATH].FMul(result, fDzDown[legIndex]))I think my type of robot control strategy is more math intensive than whatever is considered "normal". Years ago, I did some computer animation and rather than using the usual keyframes to define an objects motion, I wanted to compute the position of each part in a frame from some algorithm.
Here's the algorithm I came up with for a walking Lego minifigure.
Each "frame" of my hexapod's animation is computed based on some algorithm. I'm not sure if this is the best way to control robots but so far, I like the outcome.
I think Paul's results show his code works well. I purposefully haven't spent much time looking at Paul's code since I wanted to figure out how to do this myself.
I haven't posted my code since in it's present state it's a convoluted mess. I'm willing to post my hexapod code warts and all if you or anyone else would like me to. I have a feeling I'll be posting my code in the next couple of days. I may just put it up on my GitHub repository.
I've decided to post the code I used in the last YouTube video since it was reasonable stable. I'll post it to my hexapod thread right after making this post.
The version posted was reasonably well tested. Once I've tested my latest additions, I'll upload the code to my GitHub account.
The original 3 year project plan isn't too far off schedule. The first year was prototyping a test leg, 2nd year was the primary build of all legs and body (with some anodizing sneaking in there too) and the 3rd year was to be programming. Well, the programming is taking longer than originally expected but is still coming along and I'm into year 4 now. The individual leg program is in good shape, communications between the master and slave computers is basically figured out. Now it's time to introduce then inverse kinematics part into the master computer and getting multiple legs to coordinate with each other.
After I get back it will be time to hit the spin code hard and get things moving along. I would like to see the first steps taken before summer so I can train it to climb stairs soon afterwards. That's about the only way to get it out of the basement short of disassembling it! The trick will be teaching it to get into the back of the SUV on its own so it can go on trips!
Time to return to warm water and diving, see you next week!
Bob Sweeney
I've loved following this thread. Keep the updates coming!
Yes. Size does matter. Weight also. I guess air travel is out of question. Alas I would like to see a video of it walking towards TSA guys...
Enjoy!
Mike
"RETURN MY MASTER'S SHOES..... YOU HAVE 10 SECONDS TO COMPLY"
I've been following you all the way on this project.
Have you started thinking about the rubber water isolation socks that fit over your bot?
A video of your bot walking on the floor of the big lake would absolutely make my day!
Nice thought! Actually it should be able to walk through at least 24" of water before the leg down sensor gets wet. Beyond that it's beyond design basis... I'm just about done with vacation, 21 days in Maui with lots of diving, whale watching, eating lots of fish, have done me in! Ready to get back to the real world and my toys. Time to get some programming done instead of just reading about it.
I want to mount this inside the 1 ft diameter clear acrylic 'head' that goes on top of the robot. The pan and tilt module is less than 5" tall, I need to add another 3 inches to the base to get it aligned with the centerline of the head. The pan-tilt unit seems fairly well made and light weight, it came with servos, plenty of hardware, and even metric Allen wrenches for the bolts. The LIDAR unit is very small, runs on 5v with a max range of 40 meters. That's a lot more distance than I need even if I have the robot outside.
My next steps this weekend is to power everything back up and check out the last version of the IK equations again. It's time to program in a way to manually enter the x,y, z values from the serial monitor and see how the leg moves. After that, check on the repeatability for a given position. This will let me know how accurately my leg controller software is responding. If all goes well, getting the radio transmitter joysticks to transmit the x and z positions with a potentiometer controlling the y (height). I don't suspect I'll get all that done this weekend but it's a basic plan.
Enjoy
John Abshier
Now, back to the original plan, set up the ability to enter from the terminal the desired x,y,z values and verify the output. Then I'll be ready to copy this code back into the master controller code and start doing the same test with the leg moving to the input values.
Didn't get around to playing with the LIDAR unit, I think this is a neat gadget that fits right in with the hexapod. I'll see if I can give it some time during the week.