Bit cold, dude. My .sig expresses how I feel about this thread.
Was referring to coordinated motion control.
Motors setting off at different times cannot be considered coordinated....pussy-footing around with factual information doesn't help anyone.
I’ve been working on simplifying testing routines as often I find a problem, go and fix the issue, probably make more changes, and then need to test everything so I can get back to the point I was at before. I end up not testing everything consistently which means some issues only appear to be fixed and come back later. I was writing testing code on the fly for each problem, not good. What I need is a consistent set of test routines so I identified several test situations to test each time I make code changes.
The test routines check feedback from the P1 motor controllers, communications from the P2 to the P1’s and the HB-25 motor controllers, check leg ability to move to specific positions via angle inputs, check leg constraints, check the Inverse Kinematics math, physically move both single and groups of legs, and check IK operation. This set of tests should ensure the base code is in good shape before moving on to new stuff.
I haven’t gotten all of these tests programmed in yet (still debugging the tests!) but I put together a short video of the existing test routines, the resulting leg movements, and the debugging capabilities using Chip’s Debugger and the RGB light show on the hexapod. Hope you like it!
[
I didn’t show all the existing tests in the video, as I was filming you see that I found some math issues, some instances where a leg didn’t actually move to a position, and a handful of other errors that need to be tracked down. I troubleshoot and fix problems by creating a checklist of the problem, list any initial conditions (leg start/end position), and what test identified the issue. This way I can later re-run that test specifically to make sure the problem was corrected using the same conditions that created the problem.
I’m in the unique position of troubleshooting my troubleshooting code….
As I try to narrow down and isolate issues to correct, I noticed something. I was getting a lot of error messages from the P1 controllers about, ‘Encoder not responding’. This particular error came about a while back when a leg would come up against an immovable object (another leg or the software position limits failed), so the motor is trying to move the leg but the leg physically can not move. That’s when motors fuses would blow or the motor overheats and damages the motor brushes. The answer to this condition is to compare the encoder reading to the previous 5 encoder readings as the motor is in its PID loop. 5 times around the PID loop without the encoder changing implies there is a problem so I shutdown the motor, exit the PID loop and export the error. During manual testing on the P1 controller I rarely get this error except when I purposefully block movement.
But now when testing using the P2 master, I’m getting this error often. Thinking it through, the biggest difference is that when manually testing, during each PID loop there are several troubleshooting print commands being sent to the PST that are not active when running via the P2. So I’m suspecting the printing code is introducing a delay that allows extra time for the affected motor to start up, take up any gear backlash, and start to physically move the axis which shows up on the encoder. If true, then when running from the P2, the motors are starting but there isn’t enough time for the physical aspect of the movement to get detected by the encoder before it throws an error.
So, how to fix it? I could measure the actual time the print statements take and use that value as a loop delay. Another option is to increase the number of PID loop cycles before evoking this error (instead of 5 loops, go for 10 non-moving encoder values).
Another related issue I noticed when I did the last video, 2 legs got the encoder error and did not move the femur while the other 4 legs did move the requested position. The right thing to do is to stop all leg movements if any leg is not moving as requested. But what about a situation where a move request happens and the move is just outside the motor’s PID deadband (dead band is set for 5 ticks of the encoder or about 0.44º movement). So if the error value is 6, then the move amount is 0.088º. The PID may not wind up enough to cause the motor to actually start moving (due to very low starting error value) before the encoder not moving error triggers. In this case the fact the one leg didn’t move a degree or two may not be an issue. Maybe I need to break the encoder error into 2 levels, small and large. Small errors could be tolerated but above a given value it requires all legs to stop.
Interesting paper and video. I took a quick look at the C++ code, I’m not a C programmer so it will take some time to digest it all. I like it has a MIT license, could be fun to put together a demo and see what it can do.> @Mickster said:
IF PID_Output > Torque_Limit then PID_Output = Torque_Limit
A stalled axis causes the PID_Ouput to increase rapidly (aka: Following Error)
Craig
I don’t have any means to measure torque output of the motors at this time. At one time I was looking at how to measure motor current but those sensors were out of my budget (since I would need 18 of them!) and I had run out of cogs to act on the data.
I do something along that line, by constraining the PID output (limit PID error based on experimental testing to limit output overshoot and still have fast initial response). There are also constraints on the servo output to the HB-25 motor controllers (1000-1500 msec for movement one direction and 1500-2000 msec for movement the other direction). The PID loop operates fairly quickly and the linear actuators have lots of internal gearing and then the output shaft is turning a captured nut that gives the linear output. I’m becoming more convinced the mechanical delay from the time the motor and gears start to move, which turns into linear movement of the output shaft and that process causes the affected axis to start to rotate, which is finally picked up by the magnetic encoder. I’d rather not put any ‘delays’ in the PID loop, so will be testing increasing the time frame the encoder not changing routine looks for non-changing values.
I am finding that I only get this encoder error on the femur and tibia, both use linear actuators. The coxa is a geared motor that drives a custom gear train and rarely gets an encoder error.
Hi @DiverBob
if you don't like the following, just forget it and sorry. But perhaps you can take something from it? Reasons to write this: I have seen your video now and the motions seem to be relatively slow, but on the other hand you seem to be struggling about control of movements for months now.
I have done some projects now with the propellers and some of them include motion control.
For me it seems, that your system with 6P1 + 1P2 brings very much to much complexity for this project. P2 should be capable of doing this task (control 18 slow axis) with only some primitive means to have more pins. How many FAST pins do you need for each axis? One counter input and one PWM output? At least I would degrade the P1s to very simple in/out chips and to concentrate all development work to the P2. I also think, it would be helpful to take out the P1s and if it is really necessary to have more controllers, use less P2s instead. The reason is, that there are so many differences between P1 and P2.
My experience is, that it is only of benefit, to split tasks, if they are really rather independent. If they are not, it is better to keep them closely together. I have had a setup, where I had a raspi connected to a P1 to control my little lathe. I last year did throw out this P1 and got a very much simpler system which is even faster through some other optimisations.
(I don't know, if it is feasible with this actor mechanics, but it would be very much less complicated to use stepper motors, because in this speed range you won't need a feedback loop. At least not permanently. The only downside here is less efficiency for the battery operated robot.)
For such type of project, where there is no series production but a lot of experimenting and tweaking an interactive language can be very helpful! With the interactive console you can look at variables, change parameters, even change parts of code without the need to recompile everything. While Micropython would be convenient, it is too slow and much too big for P2. Tachyon / Taqoz Forth will give you about the same speed as Parallax SPIN but it has the huge advantage of being interactive. In some papers of the 80ies about Forth there is the statement, that software development with Forth would be 4 times faster than otherwise. For this type of project, I think that can be true. Well, Forth is a bit weird, but you would get used to that. I would be rather astonished, if P2 with Taqoz Forth would be too slow for these 18 axis in a single cog.
As far as I understand, your goal ist to climb stairs. For this, I think it is mandatory to have the possibility to "feel" the stair. Very many stepper controllers have current feedback. This is indeed rather simple. It is just a shunt resistor in the connection to ground, a rail-to-rail opamp and an analog input. https://st.com/resource/en/application_note/an240-applications-of-monolithic-bridge-drivers-stmicroelectronics.pdf (Also you could measure emf voltage to have speed feedback.)
So, while Mickster comes from a background of very fast movements, my direction of view is here, how can you simplify things to go forward more easy. One question would be, if you really need PID at all in this case. Perhaps it is good enough to simply switch off the motor, when the position is in a window of counts around the theory?
Some years back I learned about human movements, that for fast movements there is no feedback loop at all! Instead the human has to learn beforehand, what command to the muscle is needed in that situation. So if you pick up something that has very much less weight, than you thought, your movement will overshoot. Movements with feedback loop by the eye or other sense are VERY much slower.
So perhaps there can be a small number of situations (=load) which define the width of the window to switch off the motor.
@"Christof Eb." said:
1. For me it seems, that your system with 6P1 + 1P2 brings very much to much complexity for this project. P2 should be capable of doing this task (control 18 slow axis) with only some primitive means to have more pins. How many FAST pins do you need for each axis? One counter input and one PWM output? At least I would degrade the P1s to very simple in/out chips and to concentrate all development work to the P2. I also think, it would be helpful to take out the P1s and if it is really necessary to have more controllers, use less P2s instead. The reason is, that there are so many differences between P1 and P2.
My experience is, that it is only of benefit, to split tasks, if they are really rather independent. If they are not, it is better to keep them closely together. I have had a setup, where I had a raspi connected to a P1 to control my little lathe. I last year did throw out this P1 and got a very much simpler system which is even faster through some other optimisations.
(I don't know, if it is feasible with this actor mechanics, but it would be very much less complicated to use stepper motors, because in this speed range you won't need a feedback loop. At least not permanently. The only downside here is less efficiency for the battery operated robot.)
For such type of project, where there is no series production but a lot of experimenting and tweaking an interactive language can be very helpful! With the interactive console you can look at variables, change parameters, even change parts of code without the need to recompile everything. While Micropython would be convenient, it is too slow and much too big for P2. Tachyon / Taqoz Forth will give you about the same speed as Parallax SPIN but it has the huge advantage of being interactive. In some papers of the 80ies about Forth there is the statement, that software development with Forth would be 4 times faster than otherwise. For this type of project, I think that can be true. Well, Forth is a bit weird, but you would get used to that. I would be rather astonished, if P2 with Taqoz Forth would be too slow for these 18 axis in a single cog.
As far as I understand, your goal ist to climb stairs. For this, I think it is mandatory to have the possibility to "feel" the stair. Very many stepper controllers have current feedback. This is indeed rather simple. It is just a shunt resistor in the connection to ground, a rail-to-rail opamp and an analog input. https://st.com/resource/en/application_note/an240-applications-of-monolithic-bridge-drivers-stmicroelectronics.pdf (Also you could measure emf voltage to have speed feedback.)
So, while Mickster comes from a background of very fast movements, my direction of view is here, how can you simplify things to go forward more easy. One question would be, if you really need PID at all in this case. Perhaps it is good enough to simply switch off the motor, when the position is in a window of counts around the theory?
Thanks for the input!
1 - When I started this project only the P1 was available. I quickly determined a single P1 didn’t have enough horsepower to do the math and handle all the inputs and outputs I needed at that time. I was running each motor in its own cog to run DC motors like a servo. It may be possible with smart pins to run everything on a single P2 but I’m not quite ready to abandon all the work I’ve done so far. Besides, the comms between the P2 and P1’s has been worked out pretty well and I don’t believe they are really a factor at this point. At this point the P2 handles all the mathematics and just hands off actual movement to the P1 controllers.
2 - I went with DC motors using linear drives is to reduce power draw. When the motors are powered off, the legs are mechanically locked in place so power is only needed during actual movement. Direct connected steppers would require power all the time otherwise the weight of the robot would cause the steppers to rotate once power is removed. Steppers of a size that could handle this weight are very expensive and use a lot of power. I could potentially replace the DC drive motors with steppers and retain the linear actuator mechanical portion as an option. Or am I misinterpreting how you mean to use steppers?
I’ve actually been looking for brushless motors that might replace the DC motors but haven’t been successful in my search (there is also a budget constraint involved there too!). I would love to experiment with the type of motors that Boston Dynamics uses for their robots, but I imagine they are way out of my price range!
3 - I’m not sure what you mean by interactive console? Between Chip’s new debugger and the logic analyzer, it has become much simpler to figure out what is going on and narrow down errors. I primarily use Spin with some in-line assembly in time critical parts. I have also used FlexSpin but like the Parallax Propellor Tool the best. The Propellor IDE is also very nice but for some reason it doesn’t want to work properly on my setup, haven’t wanted to devote the time to figure out why…
4 - I will look at your link for current feedback. I had looked at some current sensing several years back but the need to have 18 of them coupled with the P1 limitations had me looking for other solutions instead.
5 - I have tried a variety of motor control schemes over the years and the PID loop with the magnetic encoder feedback has given the most precise control of all. Simply turning the motor on and off was one of the first setups, followed by a S-curve algorithm for motor starts and stops. There may have been a few other tests in there too. I’m pretty happy with the results the PID loop as compared with the other options I’ve tried, I’m sure my version of implementing a PID loop could be simplified or coded more efficiently.
I really appreciate your feedback and don’t think I’m discounting what you pointed out. I wanted to let you know the reasoning behind why I am doing things the way I am and how I got to this point. This has been a long project that I have really enjoyed playing with and since no one is paying me to do this, there is no set schedule for completion. I’ve learned a whole lot of new things (CAD/CAM, anodizing, battery tech, software techniques, P2 assembly language, just for starters) along the way. Half the fun of this project is having a problem and figuring out a solution! Once I actually complete this robot and get it walking and eventually able to climb stairs, then I’m not sure what I will do with it at that point! More than likely I‘ll look into more automatous operation but mostly this is a platform that gives me a good excuse to keep on learning new things. I post my progress on this thread just to encourage other robot enthusiasts and get suggestions when I do have an issue.
The technology has advanced over the time I have worked on this project and in some cases I am keeping with the older solutions (P1’s, HB-25) just because everything has already been designed around them. Another consideration is cost, there is some great improvements in motor technology that I would love to incorporate but the cost is way out of my hobbyist budget, especially when I need at least 6 of each thing. The hardware was also designed around using specific form factors and larger motors, steppers, brushless motors, gearing systems, etc in most cases would require extensive modifications to the hardware. So that also limits my ability to make hardware changes. Lastly, there is only one programmer/worker on the production team, me! So that is a limitation as everything is based on my abilities to perform what ever task that needs to be done. Luckily there are a lot of on-line robot and Parallax enthusiasts that have helped with ideas and coding over the years. I wouldn’t be as far along as I am without their help.
2 - I went with DC motors using linear drives is to reduce power draw. When the motors are powered off, the legs are mechanically locked in place so power is only needed during actual movement. Direct connected steppers would require power all the time otherwise the weight of the robot would cause the steppers to rotate once power is removed. Steppers of a size that could handle this weight are very expensive and use a lot of power. I could potentially replace the DC drive motors with steppers and retain the linear actuator mechanical portion as an option. Or am I misinterpreting how you mean to use steppers?
3 - I’m not sure what you mean by interactive console? Between Chip’s new debugger and the logic analyzer, it has become much simpler to figure out what is going on and narrow down errors. I primarily use Spin with some in-line assembly in time critical parts. I have also used FlexSpin but like the Parallax Propellor Tool the best. The Propellor IDE is also very nice but for some reason it doesn’t want to work properly on my setup, haven’t wanted to devote the time to figure out why…
Interactive console means, that you have a serial connection from a terminal window on your PC to P2 and can give commands to the system, like in the shell of linux or MS-Dos. You can start programs, compile them, You can display variables or set them. You don't need to plan simpler things, just type your command. Want to know the position of axis7. Just type "axPos7 " (or whatever the variable name is) "@ . " . If you want to correct the position to 100 units, just type "100 axPos7 ! " Forth was first used to control experiments, it is an experimenters language. Taqoz Forth comes very complete with lots of features. If one motivation for your project is learning new things, you could have a look at murphywong.net/hello/simple.htm .
I would not recommend to use Forth on a PC, where you can use other systems, which have so very mighty libraries. I would also not recommend to use Forth on a project in a big firm for a system for mass production. But for such project like yours here and most of mine, where so much time is experiment, this language is just right. Forth had it's high time, when personal computers had 16k...256k RAM and just some floppy disk as mass storage. Too low memory to run a conventional multitasking system. P2 has got just the right power and amount of RAM now for it. Well, sorry, if the fascination has caught you, it is sometimes hard to understand, why Forth is not used more in such cases.
Good luck with your project!
Christof
Personally, I believe that the motion aspect is going off on crazy tangents and that we need to start over. But I can't seem to structure a post that doesn't come across like I'm some arrogant a$$
Well, Mickster and Christof, you got me thinking about my issues over night (I can’t go to sleep due to all these thoughts running around my head!).
So I spent a few hours coming up with a much simpler motor control solution that I coded and tested. Initial results show it works pretty well, not as accurate as the PID but there are lots fewer things that can go wrong in the code. The PID code has grown over the years as issues were solved or new features were added so there are just too things that can go wrong. I finished coding the Femur and Tibia motor control loops, in many ways they resemble the PID loop in that I still have all the error checking that the P2 side is expecting. I still have to do the coxa and then manually check each axis movement to make sure I didn’t forget anything or find any hidden problems. It has been pretty easy to troubleshoot so far as code size has been reduced by 2/3rds.
@DiverBob said:
Well, Mickster and Christof, you got me thinking about my issues over night (I can’t go to sleep due to all these thoughts running around my head!).
So I spent a few hours coming up with a much simpler motor control solution that I coded and tested. Initial results show it works pretty well, not as accurate as the PID but there are lots fewer things that can go wrong in the code. The PID code has grown over the years as issues were solved or new features were added so there are just too things that can go wrong. I finished coding the Femur and Tibia motor control loops, in many ways they resemble the PID loop in that I still have all the error checking that the P2 side is expecting. I still have to do the coxa and then manually check each axis movement to make sure I didn’t forget anything or find any hidden problems. It has been pretty easy to troubleshoot so far as code size has been reduced by 2/3rds.
Sounds good! Congratulations!
When I have a look at your mechanics, I ask myself, where there is elasticity in your setup? I think, that in the human body or body of animals, there is plenty of deflection which prevents from being hurt and reduces the need for precision of position very much. It seems to be a mixture of controlled position and controlled force. On rough terrain or on grassland, you can't know at what depth the solid ground is.
Just a few thoughts,
Christof
@"Christof Eb." said:
When I have a look at your mechanics, I ask myself, where there is elasticity in your setup? I think, that in the human body or body of animals, there is plenty of deflection which prevents from being hurt and reduces the need for precision of position very much. It seems to be a mixture of controlled position and controlled force. On rough terrain or on grassland, you can't know at what depth the solid ground is.
Just a few thoughts,
Christof
The leg mechanics were built to 0.001 tolerances with bushing and bearings at 0.0005 tolerance. This makes the leg fairly rigid. However, then I added in the Linear Actuators whose connection points have a fair amount of slop (tip of leg can move about 1/4” up and down). The coxa gear train is fairly rigid, that induces less than 0.1” movement side to side measured 6” from the body. So there is some elasticity in each leg measured at the leg tip. Knowing the amount of ‘flex’ at the leg tip allows me to play with the accuracy of leg movements when figuring out straight line paths for the leg tip while moving. I have the leg down sensors for determining where the ground actually is when moving in uneven environments, but for now I’m assuming level ground.
Today I tried to implement the same motor control coding in the coxa as I did for the femur and tibia. Although I got it working, the accuracy was extremely poor as compared to the other 2 axis. I think that’s because linear actuators have a lot of ‘slop’ in the mechanism where the coxa gear train was built to higher tolerances so there is a faster motor response but slow stopping after it gets going. So even short moves resulted in anywhere from 1º to 3º movement after the motor power was removed. After a couple of hours trying to improve its accuracy, I rolled back to the PID control for just the coxa. This gives about 0.4º accuracy very reliably.
More testing tomorrow, update my notes, and then power everything down while we take off for a much needed trip!
Comments
Was referring to coordinated motion control.
Motors setting off at different times cannot be considered coordinated....pussy-footing around with factual information doesn't help anyone.
I’ve been working on simplifying testing routines as often I find a problem, go and fix the issue, probably make more changes, and then need to test everything so I can get back to the point I was at before. I end up not testing everything consistently which means some issues only appear to be fixed and come back later. I was writing testing code on the fly for each problem, not good. What I need is a consistent set of test routines so I identified several test situations to test each time I make code changes.
The test routines check feedback from the P1 motor controllers, communications from the P2 to the P1’s and the HB-25 motor controllers, check leg ability to move to specific positions via angle inputs, check leg constraints, check the Inverse Kinematics math, physically move both single and groups of legs, and check IK operation. This set of tests should ensure the base code is in good shape before moving on to new stuff.
I haven’t gotten all of these tests programmed in yet (still debugging the tests!) but I put together a short video of the existing test routines, the resulting leg movements, and the debugging capabilities using Chip’s Debugger and the RGB light show on the hexapod. Hope you like it!
[
I didn’t show all the existing tests in the video, as I was filming you see that I found some math issues, some instances where a leg didn’t actually move to a position, and a handful of other errors that need to be tracked down. I troubleshoot and fix problems by creating a checklist of the problem, list any initial conditions (leg start/end position), and what test identified the issue. This way I can later re-run that test specifically to make sure the problem was corrected using the same conditions that created the problem.
Bob Sweeney
I’m in the unique position of troubleshooting my troubleshooting code….
As I try to narrow down and isolate issues to correct, I noticed something. I was getting a lot of error messages from the P1 controllers about, ‘Encoder not responding’. This particular error came about a while back when a leg would come up against an immovable object (another leg or the software position limits failed), so the motor is trying to move the leg but the leg physically can not move. That’s when motors fuses would blow or the motor overheats and damages the motor brushes. The answer to this condition is to compare the encoder reading to the previous 5 encoder readings as the motor is in its PID loop. 5 times around the PID loop without the encoder changing implies there is a problem so I shutdown the motor, exit the PID loop and export the error. During manual testing on the P1 controller I rarely get this error except when I purposefully block movement.
But now when testing using the P2 master, I’m getting this error often. Thinking it through, the biggest difference is that when manually testing, during each PID loop there are several troubleshooting print commands being sent to the PST that are not active when running via the P2. So I’m suspecting the printing code is introducing a delay that allows extra time for the affected motor to start up, take up any gear backlash, and start to physically move the axis which shows up on the encoder. If true, then when running from the P2, the motors are starting but there isn’t enough time for the physical aspect of the movement to get detected by the encoder before it throws an error.
So, how to fix it? I could measure the actual time the print statements take and use that value as a loop delay. Another option is to increase the number of PID loop cycles before evoking this error (instead of 5 loops, go for 10 non-moving encoder values).
Another related issue I noticed when I did the last video, 2 legs got the encoder error and did not move the femur while the other 4 legs did move the requested position. The right thing to do is to stop all leg movements if any leg is not moving as requested. But what about a situation where a move request happens and the move is just outside the motor’s PID deadband (dead band is set for 5 ticks of the encoder or about 0.44º movement). So if the error value is 6, then the move amount is 0.088º. The PID may not wind up enough to cause the motor to actually start moving (due to very low starting error value) before the encoder not moving error triggers. In this case the fact the one leg didn’t move a degree or two may not be an issue. Maybe I need to break the encoder error into 2 levels, small and large. Small errors could be tolerated but above a given value it requires all legs to stop.
IF PID_Output > Torque_Limit then PID_Output = Torque_LimitA stalled axis causes the PID_Ouput to increase rapidly (aka: Following Error)
Craig
Worth studying:
https://ruckig.com/#features
Craig
Interesting paper and video. I took a quick look at the C++ code, I’m not a C programmer so it will take some time to digest it all. I like it has a MIT license, could be fun to put together a demo and see what it can do.> @Mickster said:
I don’t have any means to measure torque output of the motors at this time. At one time I was looking at how to measure motor current but those sensors were out of my budget (since I would need 18 of them!) and I had run out of cogs to act on the data.
I do something along that line, by constraining the PID output (limit PID error based on experimental testing to limit output overshoot and still have fast initial response). There are also constraints on the servo output to the HB-25 motor controllers (1000-1500 msec for movement one direction and 1500-2000 msec for movement the other direction). The PID loop operates fairly quickly and the linear actuators have lots of internal gearing and then the output shaft is turning a captured nut that gives the linear output. I’m becoming more convinced the mechanical delay from the time the motor and gears start to move, which turns into linear movement of the output shaft and that process causes the affected axis to start to rotate, which is finally picked up by the magnetic encoder. I’d rather not put any ‘delays’ in the PID loop, so will be testing increasing the time frame the encoder not changing routine looks for non-changing values.
I am finding that I only get this encoder error on the femur and tibia, both use linear actuators. The coxa is a geared motor that drives a custom gear train and rarely gets an encoder error.
Hi @DiverBob
if you don't like the following, just forget it and sorry. But perhaps you can take something from it? Reasons to write this: I have seen your video now and the motions seem to be relatively slow, but on the other hand you seem to be struggling about control of movements for months now.
I have done some projects now with the propellers and some of them include motion control.
For me it seems, that your system with 6P1 + 1P2 brings very much to much complexity for this project. P2 should be capable of doing this task (control 18 slow axis) with only some primitive means to have more pins. How many FAST pins do you need for each axis? One counter input and one PWM output? At least I would degrade the P1s to very simple in/out chips and to concentrate all development work to the P2. I also think, it would be helpful to take out the P1s and if it is really necessary to have more controllers, use less P2s instead. The reason is, that there are so many differences between P1 and P2.
My experience is, that it is only of benefit, to split tasks, if they are really rather independent. If they are not, it is better to keep them closely together. I have had a setup, where I had a raspi connected to a P1 to control my little lathe. I last year did throw out this P1 and got a very much simpler system which is even faster through some other optimisations.
(I don't know, if it is feasible with this actor mechanics, but it would be very much less complicated to use stepper motors, because in this speed range you won't need a feedback loop. At least not permanently. The only downside here is less efficiency for the battery operated robot.)
For such type of project, where there is no series production but a lot of experimenting and tweaking an interactive language can be very helpful! With the interactive console you can look at variables, change parameters, even change parts of code without the need to recompile everything. While Micropython would be convenient, it is too slow and much too big for P2. Tachyon / Taqoz Forth will give you about the same speed as Parallax SPIN but it has the huge advantage of being interactive. In some papers of the 80ies about Forth there is the statement, that software development with Forth would be 4 times faster than otherwise. For this type of project, I think that can be true. Well, Forth is a bit weird, but you would get used to that. I would be rather astonished, if P2 with Taqoz Forth would be too slow for these 18 axis in a single cog.
As far as I understand, your goal ist to climb stairs. For this, I think it is mandatory to have the possibility to "feel" the stair. Very many stepper controllers have current feedback. This is indeed rather simple. It is just a shunt resistor in the connection to ground, a rail-to-rail opamp and an analog input. https://st.com/resource/en/application_note/an240-applications-of-monolithic-bridge-drivers-stmicroelectronics.pdf (Also you could measure emf voltage to have speed feedback.)
So, while Mickster comes from a background of very fast movements, my direction of view is here, how can you simplify things to go forward more easy. One question would be, if you really need PID at all in this case. Perhaps it is good enough to simply switch off the motor, when the position is in a window of counts around the theory?
Some years back I learned about human movements, that for fast movements there is no feedback loop at all! Instead the human has to learn beforehand, what command to the muscle is needed in that situation. So if you pick up something that has very much less weight, than you thought, your movement will overshoot. Movements with feedback loop by the eye or other sense are VERY much slower.
So perhaps there can be a small number of situations (=load) which define the width of the window to switch off the motor.
Just some thoughts, cheers Christof
Thanks for the input!
1 - When I started this project only the P1 was available. I quickly determined a single P1 didn’t have enough horsepower to do the math and handle all the inputs and outputs I needed at that time. I was running each motor in its own cog to run DC motors like a servo. It may be possible with smart pins to run everything on a single P2 but I’m not quite ready to abandon all the work I’ve done so far. Besides, the comms between the P2 and P1’s has been worked out pretty well and I don’t believe they are really a factor at this point. At this point the P2 handles all the mathematics and just hands off actual movement to the P1 controllers.
2 - I went with DC motors using linear drives is to reduce power draw. When the motors are powered off, the legs are mechanically locked in place so power is only needed during actual movement. Direct connected steppers would require power all the time otherwise the weight of the robot would cause the steppers to rotate once power is removed. Steppers of a size that could handle this weight are very expensive and use a lot of power. I could potentially replace the DC drive motors with steppers and retain the linear actuator mechanical portion as an option. Or am I misinterpreting how you mean to use steppers?
I’ve actually been looking for brushless motors that might replace the DC motors but haven’t been successful in my search (there is also a budget constraint involved there too!). I would love to experiment with the type of motors that Boston Dynamics uses for their robots, but I imagine they are way out of my price range!
3 - I’m not sure what you mean by interactive console? Between Chip’s new debugger and the logic analyzer, it has become much simpler to figure out what is going on and narrow down errors. I primarily use Spin with some in-line assembly in time critical parts. I have also used FlexSpin but like the Parallax Propellor Tool the best. The Propellor IDE is also very nice but for some reason it doesn’t want to work properly on my setup, haven’t wanted to devote the time to figure out why…
4 - I will look at your link for current feedback. I had looked at some current sensing several years back but the need to have 18 of them coupled with the P1 limitations had me looking for other solutions instead.
5 - I have tried a variety of motor control schemes over the years and the PID loop with the magnetic encoder feedback has given the most precise control of all. Simply turning the motor on and off was one of the first setups, followed by a S-curve algorithm for motor starts and stops. There may have been a few other tests in there too. I’m pretty happy with the results the PID loop as compared with the other options I’ve tried, I’m sure my version of implementing a PID loop could be simplified or coded more efficiently.
I really appreciate your feedback and don’t think I’m discounting what you pointed out. I wanted to let you know the reasoning behind why I am doing things the way I am and how I got to this point. This has been a long project that I have really enjoyed playing with and since no one is paying me to do this, there is no set schedule for completion. I’ve learned a whole lot of new things (CAD/CAM, anodizing, battery tech, software techniques, P2 assembly language, just for starters) along the way. Half the fun of this project is having a problem and figuring out a solution! Once I actually complete this robot and get it walking and eventually able to climb stairs, then I’m not sure what I will do with it at that point! More than likely I‘ll look into more automatous operation but mostly this is a platform that gives me a good excuse to keep on learning new things. I post my progress on this thread just to encourage other robot enthusiasts and get suggestions when I do have an issue.
The technology has advanced over the time I have worked on this project and in some cases I am keeping with the older solutions (P1’s, HB-25) just because everything has already been designed around them. Another consideration is cost, there is some great improvements in motor technology that I would love to incorporate but the cost is way out of my hobbyist budget, especially when I need at least 6 of each thing. The hardware was also designed around using specific form factors and larger motors, steppers, brushless motors, gearing systems, etc in most cases would require extensive modifications to the hardware. So that also limits my ability to make hardware changes. Lastly, there is only one programmer/worker on the production team, me! So that is a limitation as everything is based on my abilities to perform what ever task that needs to be done. Luckily there are a lot of on-line robot and Parallax enthusiasts that have helped with ideas and coding over the years. I wouldn’t be as far along as I am without their help.
Bob Sweeney
Hi Bob, glad to see, that you appreciate my comment. I had thought about something like this: https://amazon.de/Iverntech-Schrittmotor-integrierter-Bleischraube-CNC-Maschine/dp/B0776F4BKH/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2HAJBPLFGNL7J&keywords=gewindespindel%2BSchrittmotor&qid=1681658843&sprefix=gewindespindel%2Bschrittmotor%2Caps%2C83&sr=8-1-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&th=1
You can buy the spindles separately too to combine them with stronger steppers. These spindles will hold the position without power.
But if you are happy with your actuators, there is no need to change anything. - I also do not see any advantage for brushless motors for such project. Advantage would be lifetime of the brushes, but this is not relevant here. To drive the brushless motors is more complicated.
Interactive console means, that you have a serial connection from a terminal window on your PC to P2 and can give commands to the system, like in the shell of linux or MS-Dos. You can start programs, compile them, You can display variables or set them. You don't need to plan simpler things, just type your command. Want to know the position of axis7. Just type "axPos7 " (or whatever the variable name is) "@ . " . If you want to correct the position to 100 units, just type "100 axPos7 ! " Forth was first used to control experiments, it is an experimenters language. Taqoz Forth comes very complete with lots of features. If one motivation for your project is learning new things, you could have a look at murphywong.net/hello/simple.htm .
I would not recommend to use Forth on a PC, where you can use other systems, which have so very mighty libraries. I would also not recommend to use Forth on a project in a big firm for a system for mass production. But for such project like yours here and most of mine, where so much time is experiment, this language is just right. Forth had it's high time, when personal computers had 16k...256k RAM and just some floppy disk as mass storage. Too low memory to run a conventional multitasking system. P2 has got just the right power and amount of RAM now for it. Well, sorry, if the fascination has caught you, it is sometimes hard to understand, why Forth is not used more in such cases.
Good luck with your project!
Christof
Personally, I believe that the motion aspect is going off on crazy tangents and that we need to start over. But I can't seem to structure a post that doesn't come across like I'm some arrogant a$$
Craig
Well, Mickster and Christof, you got me thinking about my issues over night (I can’t go to sleep due to all these thoughts running around my head!).
So I spent a few hours coming up with a much simpler motor control solution that I coded and tested. Initial results show it works pretty well, not as accurate as the PID but there are lots fewer things that can go wrong in the code. The PID code has grown over the years as issues were solved or new features were added so there are just too things that can go wrong. I finished coding the Femur and Tibia motor control loops, in many ways they resemble the PID loop in that I still have all the error checking that the P2 side is expecting. I still have to do the coxa and then manually check each axis movement to make sure I didn’t forget anything or find any hidden problems. It has been pretty easy to troubleshoot so far as code size has been reduced by 2/3rds.
Sounds good! Congratulations!
When I have a look at your mechanics, I ask myself, where there is elasticity in your setup? I think, that in the human body or body of animals, there is plenty of deflection which prevents from being hurt and reduces the need for precision of position very much. It seems to be a mixture of controlled position and controlled force. On rough terrain or on grassland, you can't know at what depth the solid ground is.
Just a few thoughts,
Christof
The leg mechanics were built to 0.001 tolerances with bushing and bearings at 0.0005 tolerance. This makes the leg fairly rigid. However, then I added in the Linear Actuators whose connection points have a fair amount of slop (tip of leg can move about 1/4” up and down). The coxa gear train is fairly rigid, that induces less than 0.1” movement side to side measured 6” from the body. So there is some elasticity in each leg measured at the leg tip. Knowing the amount of ‘flex’ at the leg tip allows me to play with the accuracy of leg movements when figuring out straight line paths for the leg tip while moving. I have the leg down sensors for determining where the ground actually is when moving in uneven environments, but for now I’m assuming level ground.
Today I tried to implement the same motor control coding in the coxa as I did for the femur and tibia. Although I got it working, the accuracy was extremely poor as compared to the other 2 axis. I think that’s because linear actuators have a lot of ‘slop’ in the mechanism where the coxa gear train was built to higher tolerances so there is a faster motor response but slow stopping after it gets going. So even short moves resulted in anywhere from 1º to 3º movement after the motor power was removed. After a couple of hours trying to improve its accuracy, I rolled back to the PID control for just the coxa. This gives about 0.4º accuracy very reliably.
More testing tomorrow, update my notes, and then power everything down while we take off for a much needed trip!
Bob,
Have you thought about just redoing the entire thing in cast iron, you know, just to dampen the harmonics?
I hope you are joking!