I was thinking and sometimes that is dangerous. It is about your communication method.
Your P2 sends commands to the legs to move. The legs move sending results.. I think this is too complicated. You should turn this upside down.
Think alike the mailbox system used in spin to cog communication.
Decoupling for parallel execution not serial. take the comms out of the way of thinking.
Say you have a P2 Hub array with all needed parameters and return values for each leg.
On each leg P1 you also have a HUB array with parameter and return values.
Your serial comms from P2 to P1es just sends each leg its Params and receives current return values writing back into P2 HUB. rinse repeat.
On P1es receive new params, write to own Hub read own Hub write current return values. rinse repeat.
This is as simple as it gets. Send X Hub longs to leg, receive X longs from leg, repeat. constantly. even if nothing needs to move.
On the P2 you need no command encoding, sending, reading ... just read you own HUB variables and write your own Hub variables
On the P1 you need no command encoding, sending, reading ... just read you own HUB variables and write your own Hub variables
And then let each leg P1 figure out the movement, give some start and target sysclocks for the whole movement in the HUB array or such.
On the P2 you now can calculate a movement array with proper spacing and - just write into his own Hub, the legs will go there.
think of it as common shared Hub memory between each P1 and the P2.
Sure you have some Latency, but that latency is constant since your serial comms to and from leg runs all the time the same code without stopping or changing.
We command each joint (motor) to be at a certain position at a certain time and voila, we have synchronisation, courtesy of the P1s' clocks.
P2 doesn't need to constantly monitor the positions of each joint. Whatever it last commanded, should be the actual position. If not, the P1 would show "excess position error" by way of the status byte.
We command each joint (motor) to be at a certain position at a certain time and voila, we have synchronisation, courtesy of the P1s' clocks.
P2 doesn't need to constantly monitor the positions of each joint. Whatever it last commanded, should be the actual position. If not, the P1 would show "excess position error" by way of the status byte.
Craig
Good point, the P2 doesn’t need to actually know the position especially when the leg is transitioning. I have been using that data for troubleshooting and its helped me find some issues. The P2 ignores all the position data until the leg is actually stopped and since this all runs on a separate cog, it doesn’t affect anything else. I’ve actually gotten to a point where all that extra communications is starting to get in the way so this is a good reminder to par it down some anyway.
I’m still mulling over how to get all 3 leg motors to move the leg tip so that each motor stops more or less at the same time. Since the motor operations are independent of each other, motor speeds are different, and on running on separate cogs, coming up with a way to synchronize them has been occupying my thoughts.
One idea is to compare the initial position error values for each motor (shows how far each motor has to move the leg to get to the requested
angle). If for instance the coxa has an error of 200, femur error of 25, and tibia error of 100. Then the femur moves 1 error value for every 4th coxa error value, and the tibia moves 1 error value for every 2nd coxa value (I hope I’m explaining this right!). That gives a way to know how much each motor has to move in relation to the other motors. However each motor doesn’t run at the same speed or even have the same effect on the leg tip at the same rate. For instance, the coxa motor has the fastest impact on leg tip positioning as it can move the leg tip from 0º to 180º in 2-3 seconds (I run this motor at 1/2 speed normally just for control). The tibia motor moves the leg in an out from 0º to 45º but that takes about 10 seconds. The femur moving the leg up and down has the slowest motion of all, 30º to 120º takes around 40 seconds. Normally the leg tip movement commands should be confine the leg tip to moving no more than 10mm at a time. It may be possible to just make the assumption for these very short movements, each motor is more or less synchronized as the PID isn’t going to running any motor full out over the short distance. If that is a valid assumption then I can just forget about everything I wrote in this paragraph!
If the above is true, then if the P2 creates an array of movement commands for a single step that is sent to the leg controller for storage. As the leg mostly completes a movement of all 3 motors, pop off the next movement command on the array stack, and continue the movement before the motors actually stop moving on the previous move. This could result in a smoother transition between all the individual step increments. I will have to work on coming up with some code to test this theory.
@msrobots said:
Your P2 sends commands to the legs to move. The legs move sending results.. I think this is too complicated. You should turn this upside down.
Say you have a P2 Hub array with all needed parameters and return values for each leg.
On each leg P1 you also have a HUB array with parameter and return values.
Your serial comms from P2 to P1es just sends each leg its Params and receives current return values writing back into P2 HUB. rinse repeat.
On P1es receive new params, write to own Hub read own Hub write current return values. rinse repeat.
This is as simple as it gets. Send X Hub longs to leg, receive X longs from leg, repeat. constantly. even if nothing needs to move.
On the P2 you need no command encoding, sending, reading ... just read you own HUB variables and write your own Hub variables
On the P1 you need no command encoding, sending, reading ... just read you own HUB variables and write your own Hub variables
And then let each leg P1 figure out the movement, give some start and target sysclocks for the whole movement in the HUB array or such.
On the P2 you now can calculate a movement array with proper spacing and - just write into his own Hub, the legs will go there.
think of it as common shared Hub memory between each P1 and the P2.
I’m not sure I fully understand what you are saying? Current setup has the P2 sending movement commands to each leg controller when it wants it to move, it doesn’t send anything else until the next movement is needed. The P1’s are always sending the P2 data on current position but other than showing this during debugging, the P2 ignores the return data until it’s ready to send the next movement packet.
With the earlier discussion this may change into the P2 sending batches of movement commands to the leg controllers but the leg controllers won’t respond back unless there is an error or the movement has been completed.
OMG! I've just discovered this thread. It's been around for over 10 years and I haven't noticed.
First, I have to say that all the machining and mechanical work is excellent. I love it. Really great work.
But I think you made a major mistake: It's way too big any way too complex. Don't understand me wrong. I know that reasearch and trying new things is fun even if it fails. But with such a big robot it's going to be really expensive if something turns out not to work as expected. I think the whole drive chain is totally underpowered and overweighted. To walk with reasonable speed you need to extend a leg with >1ft/s and you have to be able to push the whole thing upwards against gravity while standing on only 3 feet. On steep terrain it could happen that even a single leg has to support more than half of the weight.
Developping everything at once from scratch is a nightmare. I think it should be done step by step with a smaller model. I'd start with standard model servos. A single P2 or even a P1 can control 6 x 3 = 18 of those. You can figure out the math to coordinate all legs simultanously. If you want to climb stairs or walk on uneven terrain you have to have sensors that can "feel" the resistance of the ground. Either with force sensors in the foot tips or by measuring the load = current in the motors. I think the algorithms for motion control and terrain adaption is the biggest challange.
As soon as the smaller model works you can scale that up. I'd simply try to build bigger and stronger servos that respond as quickly as possible to a PWM or analogue command. Buffered communication doesn't work, trust me. It has to happen all in real time. As a rough estimate plan for one order of magnitude of speed for each level in the command chain. Roughly speaking, if you want to make one step per second, your position controller needs to have a reaction time of less than 0.1s. Your control loop for the motor velocities should have an update rate or ~10ms and your current amplifier around 1ms or better.
I think those linear actuators you use are designed to open/close windows or to adjust backrest or height of chairs. They are not made for continous operation and will fail quickly if they have to move all the time under load. I'd use some brushless industrial servos to drive ball screws. They cost a little more (something around $100 per 100W motor) but they are powerful, efficient and last long. Check this
Hello ManAtWork, I’m surprised you haven’t seen this thread already!
If you haven’t read all the posts over the years, this is my 2nd hexapod, the first one was less than half the size and was never close to being completed as I didn’t have the tools or knowledge necessary to finish it up. This version was started several years after that failure and I spent 1 year just testing leg mechanisms and other aspects of the project before i was satisfied enough to order the raw materials needed to create this version. It took a couple of years to build the majority of the hexapod and put it through it initial paces. It was not designed to be fast but to have a relatively slow gait. The linear actuators are each rated for moving 300 lbs but will be each sharing a portion of the almost 200 lb total weight. The linear actuators use a screw type mechanism so there is no power drawn unless actually moving. In my testing, the actuators have been strong enough to raise and lower the entire weight without any issues. On more than one occasion I’ve had a single actuator raise the robot when I made errors in coding.
Software development has been the focus for quite a while. There have been several software versions that ended up to be dead ends but each one was a learning experience. Currently there is one P1 controller for each leg running 3 motors using a modified PID controller. I did take a long break until the P2 came out as I was trying to use a P1 to control everything but it didn’t have the horsepower I needed at the time.
If I made a major mistake in the design, it’s a bit too late to making big changes at this point. I have looked into using brushless motors but haven’t found many with the power needed and at a price point I can afford (there are 18 motors that would need changing out along with new motor controllers for each one). I know there are limitations associated with using the brushed motors but I’m not planning on this winning any races so taking it slow is the name of the game. Besides, at this point I’m still working on coordinating all 3 axis motors to synchronize together. Once it actually is able to walk, I’m sure I will be introduced to other issues to solve.
This robot is a fun hobby where I wanted to challenge myself. I’ve had the opportunity to learn lots of new stuff (like CNC programming, metal milling, metal lathe, how to anodize aluminum, P1 and P2 programming, getting microcontrollers to communicate together, Inverse Kinematics mathematics, learning to use lots of new tools). I don’t regret the path I have taken, even the wrong turns have been educational. This thread has turned into more of a blog of the progress of the robot, both the good and bad parts.
Hey Bob,
Just throwing this out there but NOT suggesting that you switch direction:
The miniature hydraulics that I've been looking at on Aliexpress have piqued my interest. I have much experience with closed-loop hydraulics as well as electrics.
Ironically, I hold the patent on the 100%-electric CNC tube bending machine and I have dozens in production around north America. Today, all the big manufacturers have gone this way.....I was never a fan, however
Still can't beat hydraulics for compactness/robustness and positioning is a no-brainer. Ideally, I would love to come-up with an integrated unit where the servo-motor drives a small pump for each cylinder. This solution already exists but is needlessly expensive. I came across a Japanese machine-tool that uses this method and it blew me away; silent, compact, no excess heat, precise and clean. No gear-train and therefore no backlash to compensate for.
@Mickster said:
The miniature hydraulics that I've been looking at on Aliexpress have piqued my interest. I have much experience with closed-loop hydraulics as well as electrics.
Ironically, I hold the patent on the 100%-electric CNC tube bending machine and I have dozens in production around north America. Today, all the big manufacturers have gone this way.....I was never a fan, however
Still can't beat hydraulics for compactness/robustness and positioning is a no-brainer. Ideally, I would love to come-up with an integrated unit where the servo-motor drives a small pump for each cylinder. This solution already exists but is needlessly expensive. I came across a Japanese machine-tool that uses this method and it blew me away; silent, compact, no excess heat, precise and clean. No gear-train and therefore no backlash to compensate for.
Hydraulics was an option that I checked out when I first started the project but there were few options for small scale and it was all hideously expensive! So I kept with what I knew!
Comments
Following your progress since years and love it.
I was thinking and sometimes that is dangerous. It is about your communication method.
Your P2 sends commands to the legs to move. The legs move sending results.. I think this is too complicated. You should turn this upside down.
Think alike the mailbox system used in spin to cog communication.
Decoupling for parallel execution not serial. take the comms out of the way of thinking.
Say you have a P2 Hub array with all needed parameters and return values for each leg.
On each leg P1 you also have a HUB array with parameter and return values.
Your serial comms from P2 to P1es just sends each leg its Params and receives current return values writing back into P2 HUB. rinse repeat.
On P1es receive new params, write to own Hub read own Hub write current return values. rinse repeat.
This is as simple as it gets. Send X Hub longs to leg, receive X longs from leg, repeat. constantly. even if nothing needs to move.
On the P2 you need no command encoding, sending, reading ... just read you own HUB variables and write your own Hub variables
On the P1 you need no command encoding, sending, reading ... just read you own HUB variables and write your own Hub variables
And then let each leg P1 figure out the movement, give some start and target sysclocks for the whole movement in the HUB array or such.
On the P2 you now can calculate a movement array with proper spacing and - just write into his own Hub, the legs will go there.
think of it as common shared Hub memory between each P1 and the P2.
Sure you have some Latency, but that latency is constant since your serial comms to and from leg runs all the time the same code without stopping or changing.
Speed (velocity) = dp/dt
Increase dp and we increase velocity.
We command each joint (motor) to be at a certain position at a certain time and voila, we have synchronisation, courtesy of the P1s' clocks.
P2 doesn't need to constantly monitor the positions of each joint. Whatever it last commanded, should be the actual position. If not, the P1 would show "excess position error" by way of the status byte.
Craig
Good point, the P2 doesn’t need to actually know the position especially when the leg is transitioning. I have been using that data for troubleshooting and its helped me find some issues. The P2 ignores all the position data until the leg is actually stopped and since this all runs on a separate cog, it doesn’t affect anything else. I’ve actually gotten to a point where all that extra communications is starting to get in the way so this is a good reminder to par it down some anyway.
I’m still mulling over how to get all 3 leg motors to move the leg tip so that each motor stops more or less at the same time. Since the motor operations are independent of each other, motor speeds are different, and on running on separate cogs, coming up with a way to synchronize them has been occupying my thoughts.
One idea is to compare the initial position error values for each motor (shows how far each motor has to move the leg to get to the requested
angle). If for instance the coxa has an error of 200, femur error of 25, and tibia error of 100. Then the femur moves 1 error value for every 4th coxa error value, and the tibia moves 1 error value for every 2nd coxa value (I hope I’m explaining this right!). That gives a way to know how much each motor has to move in relation to the other motors. However each motor doesn’t run at the same speed or even have the same effect on the leg tip at the same rate. For instance, the coxa motor has the fastest impact on leg tip positioning as it can move the leg tip from 0º to 180º in 2-3 seconds (I run this motor at 1/2 speed normally just for control). The tibia motor moves the leg in an out from 0º to 45º but that takes about 10 seconds. The femur moving the leg up and down has the slowest motion of all, 30º to 120º takes around 40 seconds. Normally the leg tip movement commands should be confine the leg tip to moving no more than 10mm at a time. It may be possible to just make the assumption for these very short movements, each motor is more or less synchronized as the PID isn’t going to running any motor full out over the short distance. If that is a valid assumption then I can just forget about everything I wrote in this paragraph!
If the above is true, then if the P2 creates an array of movement commands for a single step that is sent to the leg controller for storage. As the leg mostly completes a movement of all 3 motors, pop off the next movement command on the array stack, and continue the movement before the motors actually stop moving on the previous move. This could result in a smoother transition between all the individual step increments. I will have to work on coming up with some code to test this theory.
I’m not sure I fully understand what you are saying? Current setup has the P2 sending movement commands to each leg controller when it wants it to move, it doesn’t send anything else until the next movement is needed. The P1’s are always sending the P2 data on current position but other than showing this during debugging, the P2 ignores the return data until it’s ready to send the next movement packet.
With the earlier discussion this may change into the P2 sending batches of movement commands to the leg controllers but the leg controllers won’t respond back unless there is an error or the movement has been completed.
No "more or less" about it. We're talking sample accurate. Late (early) here. Will reply in a few hours.
Craig
OMG! I've just discovered this thread. It's been around for over 10 years and I haven't noticed.
First, I have to say that all the machining and mechanical work is excellent. I love it. Really great work.
But I think you made a major mistake: It's way too big any way too complex. Don't understand me wrong. I know that reasearch and trying new things is fun even if it fails. But with such a big robot it's going to be really expensive if something turns out not to work as expected. I think the whole drive chain is totally underpowered and overweighted. To walk with reasonable speed you need to extend a leg with >1ft/s and you have to be able to push the whole thing upwards against gravity while standing on only 3 feet. On steep terrain it could happen that even a single leg has to support more than half of the weight.
Developping everything at once from scratch is a nightmare. I think it should be done step by step with a smaller model. I'd start with standard model servos. A single P2 or even a P1 can control 6 x 3 = 18 of those. You can figure out the math to coordinate all legs simultanously. If you want to climb stairs or walk on uneven terrain you have to have sensors that can "feel" the resistance of the ground. Either with force sensors in the foot tips or by measuring the load = current in the motors. I think the algorithms for motion control and terrain adaption is the biggest challange.
As soon as the smaller model works you can scale that up. I'd simply try to build bigger and stronger servos that respond as quickly as possible to a PWM or analogue command. Buffered communication doesn't work, trust me. It has to happen all in real time. As a rough estimate plan for one order of magnitude of speed for each level in the command chain. Roughly speaking, if you want to make one step per second, your position controller needs to have a reaction time of less than 0.1s. Your control loop for the motor velocities should have an update rate or ~10ms and your current amplifier around 1ms or better.
I think those linear actuators you use are designed to open/close windows or to adjust backrest or height of chairs. They are not made for continous operation and will fail quickly if they have to move all the time under load. I'd use some brushless industrial servos to drive ball screws. They cost a little more (something around $100 per 100W motor) but they are powerful, efficient and last long. Check this
Hello ManAtWork, I’m surprised you haven’t seen this thread already!
If you haven’t read all the posts over the years, this is my 2nd hexapod, the first one was less than half the size and was never close to being completed as I didn’t have the tools or knowledge necessary to finish it up. This version was started several years after that failure and I spent 1 year just testing leg mechanisms and other aspects of the project before i was satisfied enough to order the raw materials needed to create this version. It took a couple of years to build the majority of the hexapod and put it through it initial paces. It was not designed to be fast but to have a relatively slow gait. The linear actuators are each rated for moving 300 lbs but will be each sharing a portion of the almost 200 lb total weight. The linear actuators use a screw type mechanism so there is no power drawn unless actually moving. In my testing, the actuators have been strong enough to raise and lower the entire weight without any issues. On more than one occasion I’ve had a single actuator raise the robot when I made errors in coding.
Software development has been the focus for quite a while. There have been several software versions that ended up to be dead ends but each one was a learning experience. Currently there is one P1 controller for each leg running 3 motors using a modified PID controller. I did take a long break until the P2 came out as I was trying to use a P1 to control everything but it didn’t have the horsepower I needed at the time.
If I made a major mistake in the design, it’s a bit too late to making big changes at this point. I have looked into using brushless motors but haven’t found many with the power needed and at a price point I can afford (there are 18 motors that would need changing out along with new motor controllers for each one). I know there are limitations associated with using the brushed motors but I’m not planning on this winning any races so taking it slow is the name of the game. Besides, at this point I’m still working on coordinating all 3 axis motors to synchronize together. Once it actually is able to walk, I’m sure I will be introduced to other issues to solve.
This robot is a fun hobby where I wanted to challenge myself. I’ve had the opportunity to learn lots of new stuff (like CNC programming, metal milling, metal lathe, how to anodize aluminum, P1 and P2 programming, getting microcontrollers to communicate together, Inverse Kinematics mathematics, learning to use lots of new tools). I don’t regret the path I have taken, even the wrong turns have been educational. This thread has turned into more of a blog of the progress of the robot, both the good and bad parts.
Bob Sweeney
@DiverBob
Hey Bob,
Just throwing this out there but NOT suggesting that you switch direction:
The miniature hydraulics that I've been looking at on Aliexpress have piqued my interest. I have much experience with closed-loop hydraulics as well as electrics.
Ironically, I hold the patent on the 100%-electric CNC tube bending machine and I have dozens in production around north America. Today, all the big manufacturers have gone this way.....I was never a fan, however
Still can't beat hydraulics for compactness/robustness and positioning is a no-brainer. Ideally, I would love to come-up with an integrated unit where the servo-motor drives a small pump for each cylinder. This solution already exists but is needlessly expensive. I came across a Japanese machine-tool that uses this method and it blew me away; silent, compact, no excess heat, precise and clean. No gear-train and therefore no backlash to compensate for.
Craig
Hydraulics was an option that I checked out when I first started the project but there were few options for small scale and it was all hideously expensive! So I kept with what I knew!