My ‘test stand’ is an old wooden shoe storage box we had for some unknown reason that I repurposed as it was almost the right height when stood on end.
I went down an took some quick photos of the robot from different angles. One nice thing I noticed is that I can access the computers on the top level much easier now! Right now I have the battery being charged and monitoring the charge process using the digital display panel.
My ‘test stand’ is an old wooden shoe storage box we had for some unknown reason that I repurposed as it was almost the right height when stood on end.
The base off an old 5 wheel office chair makes a good starting point for an adjustable height stand. Just add two 24" concentric pipes and a small top. May not even need the pipes if the post the chair comes with is high enough.
well now program all legs to stretch and put a second wooden box under it.
That’s actually a pretty good idea!
Was planning on getting the last 2 legs installed but other duties took up the last couple of days. Finally got to the basement and started work on Leg #3. I had to work on the springs that connected the coxa encoder, they were way to loose so encoder output was all over the place when I was moving the leg manually. After getting that taken care of I installed the leg and started up the calibration routines. I started with the coxa and the leg went to one extreme and stayed there. It would not come off the CW limit, however I could hear the motor turning. Getting a flashlight I found the gear on the motor shaft was slipping. This required me to remove the leg, disassemble the gear train so I could file a flat on the shaft and drill/tap for a set screw on the motor output gear. This was supposed to be machined to be 0.0003” oversized for a friction fit but apparently I didn’t quite get it right. After getting everything put back together I called it a night and will install and calibrate the leg tomorrow instead.
I also got the 5th RoboPi computer tested and installed for Leg #3. Only one more leg controller to finish up for Leg #2!
Yesterday was some fun ending up with me having to yell for the wife to come to my rescue!
To start with I finished up work on Leg #3, installed and calibrated fairly easily (maybe I’m finally getting the hang of it!). So I started in on leg #2, the last one! The mechanical check went well so I tested the RoboPi board, no issues found. Installed the leg and it also went through the calibration routines with flying colors. That’s when the fun started.
I wanted to slowly raise 3 legs in a tripod stance to maximum height so I could get an additional support under the battery base and the test stand. Now the robot is located just behind the programming computer and bench that I normally sit at. It’s at arms reach since I need space for the legs closest to me to move without me being in its path. So I start to raise leg #2 and I entered the wrong command. Instead of raising one leg about an inch, the leg goes to full extension! So now I’m off my chair trying to keep the robot from tipping over. Luckily I had one leg on the opposite side that was just touching the floor so that helped steady it. Now I can just reach my keyboard with one hand. This is where bad decision/mistake comes into play, instead of lowering the leg I decided to raise leg #4 to the same position and get a tripod setup. So I swap the programming plug to the computer board of leg #4. I am just able with one hand to load the program on the computer and type in the command for leg #4 to extend while steadying the robot with the other hand. The problem is now I plugged into the wrong leg controller and got leg #3 extended instead. This totally unbalances the robot requiring 2 hands to keep it from falling over and even worse, now its tipping away from the computer so I can’t reach the keyboard or the stand that I wanted to put under the robot. Now I’m yelling from the basement to try and get my wife’s attention since she had just been down in the basement to say she was heading out! My first bit of luck was that she heard me as she was going out the door and came to my rescue! Together we were able to get the support under the battery box and now it is resting much more securely.
To help reduce future issues from selecting the wrong controller I put some large vinyl numbers beside each controller. Next question is how to prevent stupid decisions in the future! I’m thinking of putting a hook and rope from the ceiling to a pad eye on the robot so it can only tip over from vertical a limited amount. Now that I’ll be working with multiple legs at the same time more often I will need some additional fall protection as programming mistakes will happen it learns to walk.
On a brighter note I did come up with a way to improve data packet transmission by the individual leg computers, just need to program and test it now.
Yeah there is a reason why most of Boston Dynamics prototypes are tethered first.
If you can hang it secure then a big red stop button could pull up all legs before shutting down.
Enjoy!
Mike
I just need to hang a rail along the ceiling with a roller on the rail so it can actually move when it starts to walk! I wonder if that would be a selling point when I finally sell the house? Of course at this point I’m not sure how I’m going to get my metal lathe and milling marchine out of the basement anyway...
Today was a great day, the robot did not fall over! Today I tested the calibration on each leg and each leg operated as designed! This is still based on plugging into each leg controller separately and using the keyboard on the programming computer via the PST interface to send it commands and see how the leg responds.
I changed the input command sequence to $,Leg#,FemurAngle,TibiaAngle,CoxaAngle and tested it on each leg successfully. This is to reduce the amount of time needed for the master to output to each leg. Instead of 3 seperate commands to move one leg, only one command changes leg position.
I need to make up cables to connect all the leg inputs together for serial communications with the master computer serial output. Got figure out how I want to do that so I can test running all legs manually from the master before I let the master start running legs on its own. There will be a seperate 2-way communication loop between the legs and master for everything else except leg movement commands. That interface has to be figured out and coded later. Initially it will just feedback to the master on the current status of each leg and that info will be shown using the 4 RGB LEDs above each leg.
Talked to my wife and she was agreeable to me rigging up a ceiling padeye into a joist and another padeye on top of the robot for the next phase of testing. There is too much of a risk of it falling unexpectedly. This would protect it from damage to it and myself from falls also.
I noticed today that this thread has over over 70.1K views since I started it in November 2011! Thank you for everyone that is still following along to see if I can get this monstrosity working!
I think it is a very good sign that your wife agrees to keep you save and not get smashed by some robot in your basement. I had a couple of wife's in my life (I am a slow learner) and with some of them I would not be sure about that.
But jokes aside, when you start programming gaits and testing them it might be sensible to have some mechanism on the tether-rope to lift the robot off ground fast. No idea yet how, but it seems to make sense.
I have a Irish Wulfhound. Her name is Lilly. She is very gentile and friendly, but still is 225lbs in motion. And in opposite to your robot reacts when you cry. So maybe some sound sensor for stopping the robot is needed, just in case you can't reach the keyboard since it chased you into a corner?
.....
Talked to my wife and she was agreeable to me rigging up a ceiling padeye into a joist and another padeye on top of the robot for the next phase of testing. There is too much of a risk of it falling unexpectedly. This would protect it from damage to it and myself from falls also....
Bob Sweeney
LOL - Just pictured your basement ceiling with "C" channel fastened every two feet to the joists and another "C" channel at 90 degrees with a winch to hang your robot from while it learns to walk. Worlds largest XYZ table?
It’s been a couple of busy days but I verified all the calibration data and the new communications scheme to the legs. Fixed a few issues both in software and hardware that popped up and got all the legs finally installed, copied the leg program to EEPROM, and ready for the next stage.
The only connections to the robot in the photo is the 9v power supply to the master computer (need to wire in a power connector from the DC-DC converter still) and the prop plug cable from the programming computer. The next stage was testing out the master to leg controller communications setup. I made up just one cable that can be seen in the photo below, its the wire that goes around the entire computer deck (I need to make the next cable with a longer wire between the drops, this cable is almost too tight and the connections are not reliable for when this starts moving). It has one connection to the master and a single wire to the each leg controller. This is a one way communications link from the master to the legs only with no leg feedback. I’ll be adding a seperate line just for independent feedback to the master, that coding will be a bit more complex than the master just blasting out movement commands to the legs.
The initial test was to hard code a movement command for single legs and see if they responded. This test was successful and showed that the individual leg controllers were ignoring commands not specifically sent to them.
The next test sent hard coded commands to all six controllers at one time. The results were that only Leg #1, 3, and 5 responded. There was no movement out of leg 2, 4, or 6. After checking all the connections and then thinking about it, I modified the hard coded movement command to include a hard return character after each leg command ($1,900,0,900,CR). After this I got every leg to move to the position shown in the first photo with the exception of Leg #6. I ran out of time to figure out what is happening with #6 but I think that since it was the last leg to have its EEPROM loaded and I may have messed that up. I had to leave the house then for a dive club meeting so I’ll check that tomorrow and try again.
I will get the video camera down stairs again and start videoing the legs moving together so I can post them here. I’ll be programming in some movements to try out the ability of the linear positioners to reliably move a heavy robot. Plus, I want to have some quick and successful movements now, maybe have it moving between a tall narrow stance and a short and wide stance. It’s finally starting to come together, I got excited when I saw more than one leg move at the same time! If I don’t have too many setbacks maybe I’ll have this thing taking its first steps before spring!
Still no name, I always said that I wasn’t going to name it until it took its first step! Unfortunately I really have no names in mind. I’ve had my boat for 12 years and still haven’t named it either, its just ‘the boat’. Apparently I don’t have much imagination! I keep hoping for some inspiration someday. I might have to work harder on this item, things are moving faster to its first step!
I did get Leg #6 to work today so I can command any of the 6 legs via the master computer using the input string $,Leg#, Femur, Tibia, Coxa followed by CR. I’m trying to figure out how to replace the 4 integer values with variables. So far no luck so I posted the question over in the Prop 1 side.
I got a great answer from ersmith over on the Prop1 forum on my question of mixing 4 integers and strings together. He threw together an example code that worked the first time I tried it!
Based on that I put together a quick set of hard-code movements and video’d the results. Unfortunately when I reviewed the video it was extremely out of focus so I had to delete the footage. I found my old GoPro and charged it up, I’ll try and get a quick movement sequence video’d tonight.
In the meantime I started re-adding previously tested code snippets back into this version of the controller software. I was directly entering leg motor angle commands via the keyboard, so I put the IK routines back in. This allows entry of x,y,z distances and seeing how the legs react. I’ll use it to raise and lower the robot body using a command sequence. I don’t have a feedback mechanism running yet, so I’ll use code pauses to allow the motors to catch up. I need to solder together 2 more ‘network’ wires for the feedback loop. Got the wires cut and ready to go, time to apply solder.
I got the camera focus to work today so I put together a short video showing all 6 legs moving under master computer control. This movement is executing a series of pre-programed positions by sending each leg motor position data with a short delay to allow the motors to complete their movements. I still have to make up another network cable for the feedback side and then the legs can send completion and error data back to the master.
You can see some oscillations after movements, I need to tweak the PID values to reduce that overshoot.
I did run into a problem where only leg #6 would move to the femur to a requested position. That was puzzling as everything else worked fine and all the legs were getting the request but weren't acting on it. After sending different femur positions I finally figured out that the problem was code in the individual leg controllers that is supposed to prevent movements where the femur and tibia caused mechanical binding. Leg #6 worked because I had changed the minimum angle only for it during some test earlier and forgot to change it back. I didn't catch it earlier because visually the legs were not close to the point where binding would occur.
I got the IK code routine re-added and started some simple tests of just moving the femur up and down on one and seeing if the tip of the leg stays in the same orientation (x and z plain, y is vertical). At the same time I was printing the movement commands. With this I quickly learned that there are some limits to the values that can be entered into the IK equations! Such as the femur works with a value between 19.0 and 30.0 inches (11 inch height change). Any values outside that cause very bad results in the equations (basically you can't physically create a triangle with some values). The Tibia has some limits also, 0.0 works but the maximum value changes based on the femur position which makes sense. Once I figured that mess out I was able to have the leg up move in 0.25 inch increments for 10 inches. The printed angle movements to the leg were as expected and showed a smooth transition from one extreme to the other. Unfortunately the PID, especially for the tibia, was oscillating way too much so the actual mechanical movement was very jerky. I tried the routine on several legs with basically the same results. This tells me that I need to get back in the PID loop and do some more tuning! The tuning I did was good for manual movements from a keyboard but sending a rapid stream of commands is overwhelming it. So back to the tedious work of tweaking values for the PID again.
Back to calibrating again. It’s time consuming to make the changes to a leg controller, send the program to memory, change the USB to the master, reload the master program and then see how the PID loop value changes affect the leg, then do it all over again to try out another set of values. So I got the idea of pushing the PID values down to the leg I want to test from the master computer instead. So I coded a new leg command: “$,7,leg#,motor#,kp,Ki “, where 7 opens the calibration setup, Leg# 1..6 selects the leg, motor# is 1 - femur, 2 - tibia, 3 - coxa, and then the new integral and proportional values. This should save a lot of time in testing and I can just stay in the master computer program.
While I was testing the above code changes I saw that the tibia magnetic encoder value was jumping around more than seen before. I suspect there may be some voltage fluctuations that are impacting the encoder ADC output. I will research on how best to filter the power into the individual RoboPi computers and see if I can improve the output. I didn’t see this issue earlier as during most of my testing only the test leg was powered up, now all legs are powered up. A temporary fix may be to take an average of 10 encoder readings.
Supper is done so back to the computer for more fun!
For the encoder instability I changed the code to average of 10 samples from the encoder. This reduced the instability, trying this out for a while and see how it goes. While working on the Tibia issue I also found another issue that I was afraid might become a problem and that is the coxa encoder setup.
The spring linkages are not working as well as I had hoped, a leg can move several degrees with little or no encoder change. When I need to move in one-tenth of a degree increments that is a problem. I was also seeing where the motor starts and the leg is moving but the encoder doesn’t register the movement for a short interval and then overshoots the target position causing oscillation.
I shut everything down and got out the thinking cap for this one. The coxa encoder is not centered on the axis of movement like the tibia and femur encoders but is offset and using linkages to move the encoder shaft. The use of springs was an attempt to remove any slack from leg movements. The best method is directly connecting the encoder shaft to the moving leg while keeping the encoder body stationary. I didn’t try this initially as the locations are limited and I didn’t want to make significant structural changes to the leg. I now believe that I can fabricate a encoder holder and shaft connector that can be directly bolted together so any movement of the leg relative to the base would be sensed.
I drew the design up on paper and got all the measurements. I believe I can create all the parts out of delrin using the laser cutter which will be faster than using the CNC mill. Next step is to draw it up in CAD and then laser it and see how it goes. The design I came up with does not need any new holes drilled in the existing leg as it used existing holes.
A bit of a delay but this should make the coxa more accurate.
Spent the day making up CAD drawings and then modifying them. I downloaded the CAD files to the laser and cut all the parts out of delrin plastic. This cuts great with the 100watt laser and makes surprisingly accurate cuts. I have to take the kerf into account but that tends to be fairly consistent.
I got up to the mark III version and this one works! Still have modify a couple of the parts but the version I installed is working.
This is a view of the new coxa encoder assembly with the leg partially disassembled. You can see the encoder and the delrin part that fits over the encoder shaft. This is bolted to the leg mount and is stationary. At the other end of that part is a piece of thin white delrin that connects to the movable portion of the leg
Here the leg has been put back together and installed. I used the thin white delrin piece so it can follow the curve of the leg mount (the gold highlighted part in the middle). As the leg rotates on the coxa axis, the movement is directly transferred to the encoder. I quickly verified the calibration and the leg was moving well with no oscillations for the quick test. A check of the output from the leg didn’t show the symptoms that I was seeing earlier. So right now I’m thinking this idea is a success, only have to make 5 more! I will be lengthening the size of the part that fits over the shaft as I don’t want the white delrin part rubbing on the mounting.
Tomorrow will be time for more testing to make sure there are no surprises. So I will run some of tests to swing the leg back and forth several times to see if any part loosens while under load. Then back to more testing of the IK routines!
The last 2 days were spent working on the coxa encoder mounting upgrades. These are the 6 parts that go into the encoder mounting bracket.
The 3 parts on the left attach to the shaft of the encoder and to the movable portion of the leg. The white plastic piece connects the other 2 parts together. The 3 parts on the right are what the encoder body is mounted to and then it mounts to the robot base.
Here is the stacks of the laser-cut parts ready to go. Actually there was a fair amount of finish work to do at this point. When the laser cuts it vaporizes the material, if the laser is moving slowly in order to cut through the entire piece the upper portion of the cut tends to get wider than the bottom. So there is a bit of an angled cut that needed to be sanded flat on parts that need to be screwed together at right angles. Next was drilling out the holes for tapping, the laser cut small diameter holes to help guide the drill for holes that needed tapped. Holes not being tapped were cut to size by the laser. All the legs had to come off the robot base, again! I had to come up with specific assembly order for the new parts since the installation area is fairly tight and some screws become inaccessible at one point.
After re-attaching the legs again it was back to calibrating the coxa routine again for each leg. I’ve gotten pretty good at it now and it only takes 3-4 tries to get the upper and lower encoder values.
When I left the workshop the battery is being recharged and everything is ready to get back to working with the IK routines tomorrow! We are getting ready to start some house renovations so I’ve got to get as much done as I can before that starts, don’t know how much time I’ll have available during that process!?!
Having fun with Inverse Kinematics! One problem with IK is that it can produce solutions that are not actually possible for the robot leg to move to due to the mechanical design. It is also possible to output nonsensical values where a solution is not mathematically possible. Since the IK formulas are based on triangles, some triangles can not be created so the formula puts out bad data.
To combat this I added a routine to constrain the output to the mechanical limits for each axis. This also prevents nonsense outputs also. For all my testing up to this point I was manually entering the axis angles but with IK the input is distances. So now I’m running a series of calculations to see what positions the leg can be in and the IK works. Once I get the figured out then I can constrain the X and Z values to those that a leg can move within. This can get complicated since the lower the robot is squatting the further out the tibia can move. When the leg is fully extended the tibia can’t be moved more than an inch or two. I’ll have to put this data into a spreadsheet and see if I can come up with a mathematical solution for X and Z axis.
On a bright note I was able to move a leg up and down in the Y direction and watch the X and Z angles change to keep the leg tip in the same position! This would allow me to raise and lower the robot body without the robot moving from its current location. It’s a simple task but one that I could play with at this point.
It took some time but I got a spreadsheet with input values to the IK routine that create valid angles that are compatible with the leg possible positions. It also checks for potential interference between the femur and tibia positions (some positions cause binding).
The allowable region is the area in between the 2 curves.
I’ve been programming in some routines to move the robot body up and down and change the leg stance from wide to narrow (narrow stance is for going through doorways as the robot is only 25” wide). All the testing has been on the test stand, I got an eyebolt in the overhead joist and rigged up a connection on the robot, need to head to Harbor Freight and pick up a simple block and tackle tomorrow. They were closed today due to snow!
I’ll get video of the movements once I get the robot standing on its own with overhead protection!
Got the block and tackle set put up so I was able to slide the test stand out from under the robot and set it on its feet while the legs were in the narrow stance. I found that the robot was leaning excessively to one side. This is due to one of 3 causes;
1: there is enough mechanical ‘slop’ in the linkages that some leg tips end up higher than others for a given position.
2: the leg calibrations for the femur and tibia are not correct so a given angle on one leg is different on another.
3: the IK routines are not as accurate as I thought and need some more work
Right now I’m leaning toward a combination of item #1 and #2. For item #1 I can grab a leg and move it slightly up and down, I never measured the amount that each leg can move like this. On item #2 I made an assumption that the angle limits were the same for each leg as they are identical. I will have to re-measure each legs angles and do it while they are under a load.
In this photo you can see what the narrow stance looks like with a leg in front and the legs on either side are rotated to 30º or 150º so that they are in line with the direction of travel. In this configuration walking involves the tibia moving in and out with the coxa staying in this position. The femur will move to position the leg tip at the floor level.
This is a side view of the narrow stance. In this case the robot body was leaning away from the this viewpoint when the legs were on the ground.
I will move legs around and see if some legs are naturally shorter or taller than the others with the weight of the robot body on them. If this is the case then I can make further mechanical adjustments to the linear actuators (I can change their lengths a small amount by rotating the actuator shafts). I can also program in a ‘fudge’ factor for each leg that needs adjustments.
The block and tackle came with a very slippery poly rope that is very difficult to get a grip on, I need to change that out if I’m going to be raising and lowering this a lot! Unfortunately we are in a serious winter advisory, going to be around -10º tomorrow and most everything is going to be closed. I also need a better way to physically attach the block and tackle to the robot body. I tried using chains rated for the load but the only way to attach them was using 10-32 screws so those started bending when under load.
In the photos I have a rope slung under 2 legs, it really should be under 3 legs for better stability. I would really like to put an eye bolt in the center of the computer deck but the 12v-5v regulator is mounted on the underside of the top aluminum plate. I could re-mount the regulator using standoffs to give room for bolt to attach to the aluminum plate. That would require removal of all the legs and motor controllers to reach that area... not ready to go to all that work just yet!
In the picture I am tying the block and tackle rope off to the lathe, it’s the closest immovable object and at 1500# it should be solid!
no picture of it standing on its own legs yet. But you are getting there. I think some slack in the different legs is not avoidable, as soon as you hit uneven ground you will have to take care of this anyways. The next stuff you need are some tilt sensors to measure where the thing is leaning and maybe some sensors on the foots if they have reached the ground.
But first get it standing and moving on flat ground. Even if leaning sideways. What a wonderful project you have there...
Attaching the rope to the lathe is quite smart, you just need to use the lathe to lift it off the ground, also. Be creative!
I think some slack in the different legs is not avoidable, as soon as you hit uneven ground you will have to take care of this anyways. The next stuff you need are some tilt sensors to measure where the thing is leaning and maybe some sensors on the foots if they have reached the ground.
I designed the legs with the capability to sense the ground. The legs have a 25# spring that can trigger a limit switch once the leg tip has at least 25# of weight on the ground. Another leg sensor measures side forces against the leg; this is a flexible 10K resistor that indicates the direction a leg impact is occurring. I haven’t put those sensors in yet as I planned on just operating on level ground initially. (More information on these senses is available earlier in this thread when I was developing the leg parts)
I noticed when the robot was on its legs and leaning that the center leg and leg the robot was leaning towards had their impact springs compressed but the other leg’s spring had not compressed. My original thoughts in programming the switch was to activate the leg drive downward more (at least for a reasonable distance) until the leg switch activates. In this case, that action would have tipped the robot over. It looks like a tilt sensor is needed to prevent that from happening. I’ll worry about that programming once I’m ready for uneven ground!
Comments
I went down an took some quick photos of the robot from different angles. One nice thing I noticed is that I can access the computers on the top level much easier now! Right now I have the battery being charged and monitoring the charge process using the digital display panel.
The base off an old 5 wheel office chair makes a good starting point for an adjustable height stand. Just add two 24" concentric pipes and a small top. May not even need the pipes if the post the chair comes with is high enough.
Was planning on getting the last 2 legs installed but other duties took up the last couple of days. Finally got to the basement and started work on Leg #3. I had to work on the springs that connected the coxa encoder, they were way to loose so encoder output was all over the place when I was moving the leg manually. After getting that taken care of I installed the leg and started up the calibration routines. I started with the coxa and the leg went to one extreme and stayed there. It would not come off the CW limit, however I could hear the motor turning. Getting a flashlight I found the gear on the motor shaft was slipping. This required me to remove the leg, disassemble the gear train so I could file a flat on the shaft and drill/tap for a set screw on the motor output gear. This was supposed to be machined to be 0.0003” oversized for a friction fit but apparently I didn’t quite get it right. After getting everything put back together I called it a night and will install and calibrate the leg tomorrow instead.
I also got the 5th RoboPi computer tested and installed for Leg #3. Only one more leg controller to finish up for Leg #2!
To start with I finished up work on Leg #3, installed and calibrated fairly easily (maybe I’m finally getting the hang of it!). So I started in on leg #2, the last one! The mechanical check went well so I tested the RoboPi board, no issues found. Installed the leg and it also went through the calibration routines with flying colors. That’s when the fun started.
I wanted to slowly raise 3 legs in a tripod stance to maximum height so I could get an additional support under the battery base and the test stand. Now the robot is located just behind the programming computer and bench that I normally sit at. It’s at arms reach since I need space for the legs closest to me to move without me being in its path. So I start to raise leg #2 and I entered the wrong command. Instead of raising one leg about an inch, the leg goes to full extension! So now I’m off my chair trying to keep the robot from tipping over. Luckily I had one leg on the opposite side that was just touching the floor so that helped steady it. Now I can just reach my keyboard with one hand. This is where bad decision/mistake comes into play, instead of lowering the leg I decided to raise leg #4 to the same position and get a tripod setup. So I swap the programming plug to the computer board of leg #4. I am just able with one hand to load the program on the computer and type in the command for leg #4 to extend while steadying the robot with the other hand. The problem is now I plugged into the wrong leg controller and got leg #3 extended instead. This totally unbalances the robot requiring 2 hands to keep it from falling over and even worse, now its tipping away from the computer so I can’t reach the keyboard or the stand that I wanted to put under the robot. Now I’m yelling from the basement to try and get my wife’s attention since she had just been down in the basement to say she was heading out! My first bit of luck was that she heard me as she was going out the door and came to my rescue! Together we were able to get the support under the battery box and now it is resting much more securely.
To help reduce future issues from selecting the wrong controller I put some large vinyl numbers beside each controller. Next question is how to prevent stupid decisions in the future! I’m thinking of putting a hook and rope from the ceiling to a pad eye on the robot so it can only tip over from vertical a limited amount. Now that I’ll be working with multiple legs at the same time more often I will need some additional fall protection as programming mistakes will happen it learns to walk.
On a brighter note I did come up with a way to improve data packet transmission by the individual leg computers, just need to program and test it now.
If you can hang it secure then a big red stop button could pull up all legs before shutting down.
Enjoy!
Mike
I just need to hang a rail along the ceiling with a roller on the rail so it can actually move when it starts to walk! I wonder if that would be a selling point when I finally sell the house? Of course at this point I’m not sure how I’m going to get my metal lathe and milling marchine out of the basement anyway...
I changed the input command sequence to $,Leg#,FemurAngle,TibiaAngle,CoxaAngle and tested it on each leg successfully. This is to reduce the amount of time needed for the master to output to each leg. Instead of 3 seperate commands to move one leg, only one command changes leg position.
I need to make up cables to connect all the leg inputs together for serial communications with the master computer serial output. Got figure out how I want to do that so I can test running all legs manually from the master before I let the master start running legs on its own. There will be a seperate 2-way communication loop between the legs and master for everything else except leg movement commands. That interface has to be figured out and coded later. Initially it will just feedback to the master on the current status of each leg and that info will be shown using the 4 RGB LEDs above each leg.
Talked to my wife and she was agreeable to me rigging up a ceiling padeye into a joist and another padeye on top of the robot for the next phase of testing. There is too much of a risk of it falling unexpectedly. This would protect it from damage to it and myself from falls also.
I noticed today that this thread has over over 70.1K views since I started it in November 2011! Thank you for everyone that is still following along to see if I can get this monstrosity working!
Bob Sweeney
But jokes aside, when you start programming gaits and testing them it might be sensible to have some mechanism on the tether-rope to lift the robot off ground fast. No idea yet how, but it seems to make sense.
I have a Irish Wulfhound. Her name is Lilly. She is very gentile and friendly, but still is 225lbs in motion. And in opposite to your robot reacts when you cry. So maybe some sound sensor for stopping the robot is needed, just in case you can't reach the keyboard since it chased you into a corner?
just cautious,
Mike
LOL - Just pictured your basement ceiling with "C" channel fastened every two feet to the joists and another "C" channel at 90 degrees with a winch to hang your robot from while it learns to walk. Worlds largest XYZ table?
The only connections to the robot in the photo is the 9v power supply to the master computer (need to wire in a power connector from the DC-DC converter still) and the prop plug cable from the programming computer. The next stage was testing out the master to leg controller communications setup. I made up just one cable that can be seen in the photo below, its the wire that goes around the entire computer deck (I need to make the next cable with a longer wire between the drops, this cable is almost too tight and the connections are not reliable for when this starts moving). It has one connection to the master and a single wire to the each leg controller. This is a one way communications link from the master to the legs only with no leg feedback. I’ll be adding a seperate line just for independent feedback to the master, that coding will be a bit more complex than the master just blasting out movement commands to the legs.
The initial test was to hard code a movement command for single legs and see if they responded. This test was successful and showed that the individual leg controllers were ignoring commands not specifically sent to them.
The next test sent hard coded commands to all six controllers at one time. The results were that only Leg #1, 3, and 5 responded. There was no movement out of leg 2, 4, or 6. After checking all the connections and then thinking about it, I modified the hard coded movement command to include a hard return character after each leg command ($1,900,0,900,CR). After this I got every leg to move to the position shown in the first photo with the exception of Leg #6. I ran out of time to figure out what is happening with #6 but I think that since it was the last leg to have its EEPROM loaded and I may have messed that up. I had to leave the house then for a dive club meeting so I’ll check that tomorrow and try again.
I will get the video camera down stairs again and start videoing the legs moving together so I can post them here. I’ll be programming in some movements to try out the ability of the linear positioners to reliably move a heavy robot. Plus, I want to have some quick and successful movements now, maybe have it moving between a tall narrow stance and a short and wide stance. It’s finally starting to come together, I got excited when I saw more than one leg move at the same time! If I don’t have too many setbacks maybe I’ll have this thing taking its first steps before spring!
Bob
so has your creation a name yet?
curious,
Mike
I did get Leg #6 to work today so I can command any of the 6 legs via the master computer using the input string $,Leg#, Femur, Tibia, Coxa followed by CR. I’m trying to figure out how to replace the 4 integer values with variables. So far no luck so I posted the question over in the Prop 1 side.
Based on that I put together a quick set of hard-code movements and video’d the results. Unfortunately when I reviewed the video it was extremely out of focus so I had to delete the footage. I found my old GoPro and charged it up, I’ll try and get a quick movement sequence video’d tonight.
In the meantime I started re-adding previously tested code snippets back into this version of the controller software. I was directly entering leg motor angle commands via the keyboard, so I put the IK routines back in. This allows entry of x,y,z distances and seeing how the legs react. I’ll use it to raise and lower the robot body using a command sequence. I don’t have a feedback mechanism running yet, so I’ll use code pauses to allow the motors to catch up. I need to solder together 2 more ‘network’ wires for the feedback loop. Got the wires cut and ready to go, time to apply solder.
Bob
You can see some oscillations after movements, I need to tweak the PID values to reduce that overshoot.
I did run into a problem where only leg #6 would move to the femur to a requested position. That was puzzling as everything else worked fine and all the legs were getting the request but weren't acting on it. After sending different femur positions I finally figured out that the problem was code in the individual leg controllers that is supposed to prevent movements where the femur and tibia caused mechanical binding. Leg #6 worked because I had changed the minimum angle only for it during some test earlier and forgot to change it back. I didn't catch it earlier because visually the legs were not close to the point where binding would occur.
I got the IK code routine re-added and started some simple tests of just moving the femur up and down on one and seeing if the tip of the leg stays in the same orientation (x and z plain, y is vertical). At the same time I was printing the movement commands. With this I quickly learned that there are some limits to the values that can be entered into the IK equations! Such as the femur works with a value between 19.0 and 30.0 inches (11 inch height change). Any values outside that cause very bad results in the equations (basically you can't physically create a triangle with some values). The Tibia has some limits also, 0.0 works but the maximum value changes based on the femur position which makes sense. Once I figured that mess out I was able to have the leg up move in 0.25 inch increments for 10 inches. The printed angle movements to the leg were as expected and showed a smooth transition from one extreme to the other. Unfortunately the PID, especially for the tibia, was oscillating way too much so the actual mechanical movement was very jerky. I tried the routine on several legs with basically the same results. This tells me that I need to get back in the PID loop and do some more tuning! The tuning I did was good for manual movements from a keyboard but sending a rapid stream of commands is overwhelming it. So back to the tedious work of tweaking values for the PID again.
Bob
While I was testing the above code changes I saw that the tibia magnetic encoder value was jumping around more than seen before. I suspect there may be some voltage fluctuations that are impacting the encoder ADC output. I will research on how best to filter the power into the individual RoboPi computers and see if I can improve the output. I didn’t see this issue earlier as during most of my testing only the test leg was powered up, now all legs are powered up. A temporary fix may be to take an average of 10 encoder readings.
Supper is done so back to the computer for more fun!
The spring linkages are not working as well as I had hoped, a leg can move several degrees with little or no encoder change. When I need to move in one-tenth of a degree increments that is a problem. I was also seeing where the motor starts and the leg is moving but the encoder doesn’t register the movement for a short interval and then overshoots the target position causing oscillation.
I shut everything down and got out the thinking cap for this one. The coxa encoder is not centered on the axis of movement like the tibia and femur encoders but is offset and using linkages to move the encoder shaft. The use of springs was an attempt to remove any slack from leg movements. The best method is directly connecting the encoder shaft to the moving leg while keeping the encoder body stationary. I didn’t try this initially as the locations are limited and I didn’t want to make significant structural changes to the leg. I now believe that I can fabricate a encoder holder and shaft connector that can be directly bolted together so any movement of the leg relative to the base would be sensed.
I drew the design up on paper and got all the measurements. I believe I can create all the parts out of delrin using the laser cutter which will be faster than using the CNC mill. Next step is to draw it up in CAD and then laser it and see how it goes. The design I came up with does not need any new holes drilled in the existing leg as it used existing holes.
A bit of a delay but this should make the coxa more accurate.
Bob
I got up to the mark III version and this one works! Still have modify a couple of the parts but the version I installed is working.
This is a view of the new coxa encoder assembly with the leg partially disassembled. You can see the encoder and the delrin part that fits over the encoder shaft. This is bolted to the leg mount and is stationary. At the other end of that part is a piece of thin white delrin that connects to the movable portion of the leg
Here the leg has been put back together and installed. I used the thin white delrin piece so it can follow the curve of the leg mount (the gold highlighted part in the middle). As the leg rotates on the coxa axis, the movement is directly transferred to the encoder. I quickly verified the calibration and the leg was moving well with no oscillations for the quick test. A check of the output from the leg didn’t show the symptoms that I was seeing earlier. So right now I’m thinking this idea is a success, only have to make 5 more! I will be lengthening the size of the part that fits over the shaft as I don’t want the white delrin part rubbing on the mounting.
Tomorrow will be time for more testing to make sure there are no surprises. So I will run some of tests to swing the leg back and forth several times to see if any part loosens while under load. Then back to more testing of the IK routines!
Bob
The 3 parts on the left attach to the shaft of the encoder and to the movable portion of the leg. The white plastic piece connects the other 2 parts together. The 3 parts on the right are what the encoder body is mounted to and then it mounts to the robot base.
Here is the stacks of the laser-cut parts ready to go. Actually there was a fair amount of finish work to do at this point. When the laser cuts it vaporizes the material, if the laser is moving slowly in order to cut through the entire piece the upper portion of the cut tends to get wider than the bottom. So there is a bit of an angled cut that needed to be sanded flat on parts that need to be screwed together at right angles. Next was drilling out the holes for tapping, the laser cut small diameter holes to help guide the drill for holes that needed tapped. Holes not being tapped were cut to size by the laser. All the legs had to come off the robot base, again! I had to come up with specific assembly order for the new parts since the installation area is fairly tight and some screws become inaccessible at one point.
After re-attaching the legs again it was back to calibrating the coxa routine again for each leg. I’ve gotten pretty good at it now and it only takes 3-4 tries to get the upper and lower encoder values.
When I left the workshop the battery is being recharged and everything is ready to get back to working with the IK routines tomorrow! We are getting ready to start some house renovations so I’ve got to get as much done as I can before that starts, don’t know how much time I’ll have available during that process!?!
Bob
To combat this I added a routine to constrain the output to the mechanical limits for each axis. This also prevents nonsense outputs also. For all my testing up to this point I was manually entering the axis angles but with IK the input is distances. So now I’m running a series of calculations to see what positions the leg can be in and the IK works. Once I get the figured out then I can constrain the X and Z values to those that a leg can move within. This can get complicated since the lower the robot is squatting the further out the tibia can move. When the leg is fully extended the tibia can’t be moved more than an inch or two. I’ll have to put this data into a spreadsheet and see if I can come up with a mathematical solution for X and Z axis.
On a bright note I was able to move a leg up and down in the Y direction and watch the X and Z angles change to keep the leg tip in the same position! This would allow me to raise and lower the robot body without the robot moving from its current location. It’s a simple task but one that I could play with at this point.
The allowable region is the area in between the 2 curves.
I’ve been programming in some routines to move the robot body up and down and change the leg stance from wide to narrow (narrow stance is for going through doorways as the robot is only 25” wide). All the testing has been on the test stand, I got an eyebolt in the overhead joist and rigged up a connection on the robot, need to head to Harbor Freight and pick up a simple block and tackle tomorrow. They were closed today due to snow!
I’ll get video of the movements once I get the robot standing on its own with overhead protection!
YES, please,
Mike
1: there is enough mechanical ‘slop’ in the linkages that some leg tips end up higher than others for a given position.
2: the leg calibrations for the femur and tibia are not correct so a given angle on one leg is different on another.
3: the IK routines are not as accurate as I thought and need some more work
Right now I’m leaning toward a combination of item #1 and #2. For item #1 I can grab a leg and move it slightly up and down, I never measured the amount that each leg can move like this. On item #2 I made an assumption that the angle limits were the same for each leg as they are identical. I will have to re-measure each legs angles and do it while they are under a load.
In this photo you can see what the narrow stance looks like with a leg in front and the legs on either side are rotated to 30º or 150º so that they are in line with the direction of travel. In this configuration walking involves the tibia moving in and out with the coxa staying in this position. The femur will move to position the leg tip at the floor level.
This is a side view of the narrow stance. In this case the robot body was leaning away from the this viewpoint when the legs were on the ground.
I will move legs around and see if some legs are naturally shorter or taller than the others with the weight of the robot body on them. If this is the case then I can make further mechanical adjustments to the linear actuators (I can change their lengths a small amount by rotating the actuator shafts). I can also program in a ‘fudge’ factor for each leg that needs adjustments.
The block and tackle came with a very slippery poly rope that is very difficult to get a grip on, I need to change that out if I’m going to be raising and lowering this a lot! Unfortunately we are in a serious winter advisory, going to be around -10º tomorrow and most everything is going to be closed. I also need a better way to physically attach the block and tackle to the robot body. I tried using chains rated for the load but the only way to attach them was using 10-32 screws so those started bending when under load.
In the photos I have a rope slung under 2 legs, it really should be under 3 legs for better stability. I would really like to put an eye bolt in the center of the computer deck but the 12v-5v regulator is mounted on the underside of the top aluminum plate. I could re-mount the regulator using standoffs to give room for bolt to attach to the aluminum plate. That would require removal of all the legs and motor controllers to reach that area... not ready to go to all that work just yet!
In the picture I am tying the block and tackle rope off to the lathe, it’s the closest immovable object and at 1500# it should be solid!
Bob
no picture of it standing on its own legs yet. But you are getting there. I think some slack in the different legs is not avoidable, as soon as you hit uneven ground you will have to take care of this anyways. The next stuff you need are some tilt sensors to measure where the thing is leaning and maybe some sensors on the foots if they have reached the ground.
But first get it standing and moving on flat ground. Even if leaning sideways. What a wonderful project you have there...
Attaching the rope to the lathe is quite smart, you just need to use the lathe to lift it off the ground, also. Be creative!
Enjoy!
Mike
I noticed when the robot was on its legs and leaning that the center leg and leg the robot was leaning towards had their impact springs compressed but the other leg’s spring had not compressed. My original thoughts in programming the switch was to activate the leg drive downward more (at least for a reasonable distance) until the leg switch activates. In this case, that action would have tipped the robot over. It looks like a tilt sensor is needed to prevent that from happening. I’ll worry about that programming once I’m ready for uneven ground!
Yeah! Just turn the lathe on if it starts to fall!