Next large robot



  • Machining more parts, lots of soldering, and starting to re-assemble the legs with the upgrades installed. It’s going to be several more days to finish this up but then I should be able to start testing 2 legs together and see if the gait engine works right, ie both legs move the right direction. Of course each leg has to be calibrated first which is a tedious project. Here are some photos of progress.
    These are the arms that are used by the coxa encoder to move the shaft as the coxa motor moves. It’s a slightly different design from the test version but it should be more reliable. The test version had issues with the spring wires popping out of the arm, this solves that issue.
    These are the encoder housings with the wiring harness installed.
    These are the coxa encoders mounted. Mods to this part included drilling the hole for the encoder and cutting 1 inch off the back of the mount to allow more room for the sensor plugs and wires that are mounted directly behind the piece. Some wires were getting pinched and the extra length wasn’t needed on this mount.
    Here is a fully wired encoder in its housing. The other encoders still need their shafts cut down to 1/4” and soldering the wiring harness to the encoder. Initial calibration is connecting to a program to determine the output value to make sure the output doesn’t cross zero in the expected rotation range.
  • Testing the encoders with a simple calibration program now that the electrical connections have been made. Out of 15 encoders, 5 did not work at all. On a whim I swapped the CS and CLK lines and the ‘failures’ started to work correctly. Not sure how I could have made that serious a soldering mistake on 30% of the encoders, I started cutting the CS and CLK wires and swapping them. I got down to the coxa encoders and just by chance noticed that some of the pre-wired connectors that I have been using have the 2 outside wires on the connector swapped! So when I was soldering and using the wire color to match up to my schematics, the wires were not correct at the connector end. That explains some of the other issues I have had using these connectors in other locations, I never thought to look at the order of the wires in the connector itself.
    Now that’s sorted out I can continue with the initial calibration and start installing the encoders.

    Bob Sweeney
  • I had to throw away the coxa encoder arms that I made earlier. When I installed the arms I found several problems with the new design including the fact that they were almost impossible to install in the space available. Back to the drawing board and I reduced the length of the arm down to 1.5 inches and increased the width of the slots on the ends of the arm to 0.125 inches. I also drilled 2 more holes in the support plate to allow a hex wrench easier access to the screws that hold the springs to the movable portion of the leg. The screw connection for the spring may need some adjusting also, the spring is sitting at an angle and it should be level, may make some custom spacers to elevate the point where the springs connect to the leg. The springs I am describing are custom springs made using 0.54” music wire that was wound on a jig to get the correct spring length and connectors for the hold down screws.
    I also mounted the femur and tibia encoder housings on one leg. I found that I was getting some interference from the head of a bolt that didn’t allow the encoder to turn smoothly. That was fixed by adding a thin washer on the encoder to push the encoder shaft away from the bolt head. Also the friction fit discs that slip on the encoder shaft had to be discarded as they were too thick. I figured it would be faster/easier to use the lathe to fabricate new parts rather than figuring out how to reduce the thickness from 0.25 to 0.21 inches.
    Leg # 2 is now put back together, will be working on finishing up the other legs now that I have good measurements for the needed parts. The remaining legs should go a bit faster.
  • DiverBob wrote: »
    ... The springs I am describing are custom springs made using 0.54” music wire that was wound on a jig to get the correct spring length and connectors for the hold down screws....

    DiverBob, is that decimal in the right place? Half-inch music wire? Post a picture!

  • DaveJenson wrote: »
    DiverBob wrote: »
    ... The springs I am describing are custom springs made using 0.54” music wire that was wound on a jig to get the correct spring length and connectors for the hold down screws....

    DiverBob, is that decimal in the right place? Half-inch music wire? Post a picture!

    Oops, you are right, it should be 0.054 diameter! Half inch might be a bit hard to bend by hand...
  • I got leg #1 mechanicals updated and attempted to install the leg on the body. Unfortunately I discovered that the wiring harnesses I created for the encoders is about 2-3 inches too short. I got the bundled 6 wire cable length correct but the connectors were too short to reach the sensor plugs. Thats when I remembered that I cut the plug wires shorter by about 4 inches. So to get around this SNAFU that I created for myself, I wanted to see what the easiest fix would be. By swapping the positions of the sensor plugin board and the motor power board I was able to get the plugs close enough that I could plug in the sensors. The disadvantage of this was that I could see that the motor wires could potentially interfere with the coxa encoder movement, plus I was worried that the encoder wires are still tight and coxa movement could damage the wires. All the other potential solutions I thought of were either fairly extensive or too complicated. So the best answer I have is to go back and solder in the extra length of wire that I cut off. So that is about 120 solder connections to make again..... Unfortunately this was a self imposed problem this time.
    3264 x 2448 - 1M
    3264 x 2448 - 1M
  • Bob,
    Did you ever get those harnesses rewired?
  • RS_Jim wrote: »
    Did you ever get those harnesses rewired?
    I haven’t posted in a while as I was in Maui diving for a while and since then I’ve been busy completing with laser project commitments (I got more orders than expected for a series of Great Lakes shipwreck maps I created) so the robot has been ignored. I will have time opening up starting in May so I will start fixing the wiring harnesses. Then I can get back to programming again, just about ready to test 2 leg movement. Of course by that time something else will happen/break and I’ll be fixing/modifying that also. In the course of testing the leg movements I found that the coxa reduction gear bronze bushing would fall out occasionally. This is a flanged bushing and the flange is on the underside of the part so gravity tends to help this problem. The fix would be fairly easy but time consuming, just machine a recess for the bushing on the ‘top’ of the part and then it can’t fall out. Unfortunately that involves a lot of disassembly, set up and cutting on the mill so I’ve just resorted to putting the bushing back in and try to pin it in place (unsuccessfully).
  • Glue?
    Jealous of dining in Maui. Only diving I have ever done is 10 days in the Bahamas.
  • RS_Jim wrote: »
    Jealous of dining in Maui. Only diving I have ever done is 10 days in the Bahamas.
    I haven't found a glue that would stand up to the forces that would be exerted on the bushing. I just need to do the correct fix, too many times I try a 'shortcut' and usually I regret it later. The rest of this month is filled with some traveling and other projects so the robot stays on the back burner for a bit longer. I am committed to getting this thing to walk eventually, I retired and its actually harder to find time to work on it!
    My wife and I dive for 3 weeks in Maui every other year with the Caribbean as our choice on the off years. I dive year round, Great Lakes shipwreck diving season should be getting started shortly (waiting for the early storms to start to calm down now) and I'll be out diving most weekends off my boat.

  • Just a quick note to say this thread isn’t dead, its just summer.... The robot is still a work in progress, just less progress during the summer due to too many other distractions! I do manage to spend a bit of time on it but nothing major is happening at this time. The focus is re-wiring the magnetic encoder wiring harnesses to add the extra length needed so the leg can move freely. Thats a boring job so it keeps being put off! I do play with some other minor tweaks and run the software from time to time to fine tune the movements, still haven’t gotten 2 legs to run at once but it’s on the testing listing after the wiring update....
    Back to summer fun, new RV so we are traveling around and seeing the things we missed during our younger years!

  • This has been the longest break from working on the robot since I started but summer is winding down so we won’t be traveling much until spring rolls around again in Michigan. So theoretically that means I should have more time to get back to work on the robot after I get caught up on the Honey-Do list!
    I broke down and re-wired all the wiring harnesses that were too short by adding about 4 inches of extra wire to the harness length. Now that that chore is complete I am adding the tibia and femur encoders to the remaining 5 legs starting tonight. It’s been so long since I worked on this last that I have to disassemble the working leg to see what mods I added to it so I can make sure the remaining legs get the same changes added. The main battery has been charged back up and I can try out the coding again on the operating leg. Time to see if it is still operating the same way as I left it.
  • Welcome back. Been wondering if thé Wiring had overwhelmed you. I am looking forward to new progress updates.
  • It’s good to be back! I occasionally would get back on the forum to read and see what was new but didn’t spend a lot of time here. Good to see the P2 is alive, I wonder if I could use one of those in place of the 7 P1’s being used by the robot?

    I installed the encoders on one leg and decided that as long as I had it partially disassembled for that task, I would go ahead and finally fix the problem where the bronze bushings in the coxa gear train would fall out. This involves removing the bottom plate and taking the bushings out. Since the bushings are flanged, the fix is to simply insert the bushings back into the the existing holes but with the flanges on the top side of the plate so gravity and friction hold them in place. No machining necessary! The flanges only stick up .034 and don’t interfere with the gears. All this time I thought I would have to re-machine a new flange area, coming back with a fresh perspective helped me see past my prior assumptions.
    Wiring addition
    Bottom gear plate, view from bottom with bushings inserted from top
    Bushing flanges hold bushings in place
    Reduction gear assembly with bottom plate removed. Plenty of space for the flanges to rest on top of plate without interfering with the gears.
    Bottom plate re-installed.
    Coxa encoder installed. You can see the shaft that moves the encoder as the coxa moves.
  • Three legs are complete and installed. Working on #4 tonight. I had to read my own entries on this thread to see what additional changes I had to install for this leg. The other 2 legs already had most of the updates installed so the next 3 will be slower. Got the bushings fixed and now I’m setting up the coxa encoder so I have to create 2 more of my custom wire ‘springs’. Luckily the jig I made was still beside the vise, now to locate the music wire again and do some bending.
    I haven’t turned on the computer and looked at the program yet, I’ll get these mechanical updates completed before I start programming again. Of course now I have to come back up to speed on my program, I believe I was about ready to run with 2 legs at the same time.
  • Leg #4 has all the updates installed and is ready to mount on the robot body. Starting on the next leg, it may go a bit faster since I was also making all the upgrade parts for the other legs too.
  • Go Bob, go,

    You still have a chance to have this thing walking it's first step before Chip finishes the final P2.

    still betting on you...

  • I got leg #5 finished, need to connect it to the robot next. One last leg to upgrade and all 6 are done. Still have to solder up the last 2 RoboPi boards as leg controllers.
    I will have to come back up to speed on my leg software, its been a while since I did anything with it. I’m hopeful that this won’t take too much time, I’ve got to calibrate each leg, programming several props to talk to each other will be interesting....
    I think the P2 rollout will be first!
  • Leg #5 is connected to the body now, started upgrades on the last leg. Unfortunately when I was cleaning up with the shopvac I accidentally vacuumed up some of the parts I had made. I couldn’t find them in the vacuum bag, its mostly full of sawdust, plastic shavings and aluminum scrap, about 10 lbs worth. After a while of trying to find the parts (you’d think they would be near the top?) I finally gave up and started to re-create them fresh.

    I didn’t like to look of the wire harness on each leg so I used some 1/4” split loom plastic to encase the wires. Now it looks much nicer, need to zip tie the wires to the leg also.

    I’ll get some fresh photos of the hexapod once its all put back together, its been a while since its been assembled this much, I think it was at the last Unofficial Parallax Expo in Findlay, Ohio. I miss having those get together, it was fun to see other like minded people and the projects everyone came up with!

  • Leg #6 upgrades are complete and it is attached to the body. This is the first time all legs have been attached since the last Parallax Expo. The top dome is still empty, haven’t had time to work on the Lidar unit and cameras that will be placed in there eventually.
    Here is another view of the power control panel with the Lascar PanelPilot display configured to show main battery voltage.
    Next step is to start the leg calibration process. For this I have a program that moves each axis of the leg to the extremes of each axis and records the minimum and maximum encoder values. It does this some 10 times per axis so I can compare values and see if there is any variance. Any thing more than a couple of counts off indicates the encoder is sticking or something is loose. If that happens then I have to troubleshoot the movement and figure out a fix. The upgrades I put into each leg should eliminate that problem but the routine is still good for finding the unexpected.
    But before I start calibrating I am going to be studying the old leg code and running it on the first installed leg. Got to make sure I haven’t forgotten anything that needs attention in the code.

  • Now that is a robot I wouldn't want coming after me!
  • What's the weight as we see it now?
  • Publison wrote: »
    What's the weight as we see it now?
    Each leg is 26 lbs x 6 = 156lbs. I haven’t weighted the body with battery but I would estimate it to be around 50 lbs for a total weight of just over 200 lbs. One of these days I will get a completed weight. Luckily each linear motor can move 300 lbs and since they move in groups of three there shouldn’t be any issues. Several times during testing when the test leg program misbehaved it was easily picking up the whole side of the robot off the test stand before I could hit the stop.

  • Never seen a pic of the whole bot! Impressive!!
  • In between getting ready for Thanksgiving and everything else I finally finished soldering the last 2 RoboPi computer boards for the robot.
    Now I have all 6 leg controllers and master computer completed.
  • Powered up the test leg for the first time in a while, loaded the latest program, guess what it still works! After running a few movements through the manual input option I noticed saw some issues again that had been bothering me the last time I was here. This time I was able to recognize that the PI controller was pushing the motor speed due to Integral windup thus causing overshoot. This time I quickly found a solution that had been eluding me previously. I couldn’t remove or reduce the Integral portion as that is needed to enable motor moves when the requested move is a very small value. So I came up with an new default ‘max’ value for the integral value and after a bit of experimentation along with finding a Ki multiplication factor, the leg moves as expected with small or large input values.
    The next item on the troubleshooting list is figuring out how to improve the communications link between the leg controller and the master. The current setup has the feedback loop from the legs to the master as part of the master loop. However the master loop spends most of its time sitting and waiting for input from the master so it doesn’t send any info back to the master until after it receives new input from the master. I realized that since I am only using 6 cogs now so I am thinking about setting up a dedicated cog just for output serial communications to the master and leave the existing input comms where they are now. I’ll look into that more tomorrow.
    It didn’t take as long as to come back up to speed on the leg controller as I thought it might. The PID setup has simplified the code considerably and makes it easier to see what is going on as compared to the earlier versions of the code.
  • DiverBob, I just have to say this is awesome, I never realized the scale of the full robot! I also got one of those RoboPi boards from Bill and wondering what I should do with it (have it figure out how to use it, really.) Looks like you are putting yours to great use! Please keep the great updates and photos coming, it has been really something to follow the progress.
  • Working on coding today, specifically made some changes to all the PI loops to keep them the same, the only differences between them are the Kp and Ki multiplier values.
    Next stop was setting up a new cog for feedback communications to the master. Once I set this up and moved the feedback code to the new cog for execution. Of course once I see it in code I start thinking about ways to improve it. Right now the setup would be that each leg has its own feedback loop to the master and each one is sent to a separate input pin on the master. The master could have one cog dedicated to reading the 6 separate inputs sequentially and storing the incoming values so that other cogs can access the data as needed.
    My thought is that with no synchronization between the legs, data can be lost from a leg that is reporting an error condition while the master is busy reading/writing another leg’s data.
    A method to synchronize is to use a single master feedback input pin that all the legs are connected to. The master sequentially queries each leg and the prompted leg uploads its data. I already send an identifier and leg number via the feedback loop (‘$,’ is used to indicate a string, followed by a numeric indicator (1-6) representing the leg number (the rest of the string is another number, 1-9 to to indicate the leg source, such as 1 is Femur, 2 is Tibia, 3 is Coxa, which is then followed by a data value). This requires monitoring and sending code (much like what is currently in the main loop). Especially since its in its own cog so I can’t just can’t call the PUB in the main loop (I can just copy them with a different name but I hate to duplicate things like that!). I love tha parallel processing of the P1 but situations like this where multiple processors need to share the same code can be a pain at times. I’m sure there is an easier way of doing this but I don’t know it!
    Still thinking of alternatives and will be doing some searches in the P1 discussion forums tonight.

  • I'm not too clear on what you mean in that last paragraph. Are you sending actual pasm/spin code between the cogs or prop chips, or are you sending data that results in some specific code being executed?
  • kwinn wrote: »
    I'm not too clear on what you mean in that last paragraph. Are you sending actual pasm/spin code between the cogs or prop chips, or are you sending data that results in some specific code being executed?
    My setup has 6 leg controllers and one master computer. The master computer sends leg commands to the individual legs using a format like this: $,6,2,900. That command translates as move leg 6 tibia motor to 90.0º position. Once the command is sent the leg then executes the command. Each leg controller also generates information related to the commanded movement that needs to be sent back to the master for display or further operations. The format for that command is similar to the incoming command; $6,4,1. This translates in the master as coming from leg 6, error #1 identified.
    Right now I have the leg controller wired directly to two separate pins on the master for signal transmission and reception. Now I am in the process of adding in the additional leg controllers and I need to come up with a good communications system. At one point I was going to have each leg controller connecting to separate master pins (6 transmit and 6 receivers) but I don’t really like that solution. I’ve since been thinking of using a single master transmit and receiving lines instead. Since I already use a leg identifier in the data stream both directions, I can wire the master to leg as a single wire to each controller and use the existing data format so each leg can pick up the data it needs.
    I’m thinking about using a similar setup for the feedback loop. For the longest time I did not have any extra cogs available on the leg controllers but with the code improvements there are a couple of unused cogs now. I can set up a dedicated cog just for sending data back to the master over a single wire that connects to all the legs. This is a trickier process than the master sending out to the individual legs as all 6 legs could transmit back to the master and interfere with each other. My idea is to have the master control the data coming into it by sending a query to each leg in turn and the leg then send its data. That would eliminate the interference issue at the expense of additional code and wiring complexity, since I have to have a dedicated transmit line from the master.
    So what I’m trying to do is figure out if this is the best way to approach this problem or if there is a better way I haven’t seen yet. I hope that explains the process better, I kind of clouded the issue earlier when talking about some of the difficulties running parallel processes.
Sign In or Register to comment.