Actually got all three axis to move at the same time for the first time! I'm setting up some manual IK tests where I use excel to calculate some leg position values, put these values in an array that the program steps through. This will test how smoothly the leg can respond to the inputs.
In preparation for IK testing I've been doing additional tweeting of the motor ramp routines to improve their response, especially when then the amount of movement is small. So far the Coxa and femur routines will allow as small as a 1-2 degree change. I'll be working on the tibia routine next.
I also discovered last night that I had the input angle for the femur routine backwards, the full up position should be 137 degrees, not 38 degrees. So that required a bit of re-work to get that corrected. This would have caused some serious positioning issues when the IK routines run.
I also programmed a special case for the femur routine such that if 200 degrees is entered, the leg is fully retracted which puts the robot at a minimum height for traveling. Of course that required another change to get it out of this position since both positions are outside of its normal movement range.
Another puzzle to be solved yet is programming in movement limits for the tibia and femur. At the extreme ends of movement of the femur the tibia movements can cause mechanical interference. I need to graph out where these limits are and then figure out how to keep the leg out of those regions.
I will get some more video of the tests, especially the IK testing when I get to that, possibly this weekend.
Both good and bad today programming. I got the tibia motor routine tweaked to now run on as small as a 1-2 degrees change on the input angle. That was the good part of today. The bad part was setting up an array to run all three motors and simulate a simple stepping motion. Totally disasterous, motors were not moving as expected and although when individually controlled they work fine, together they go all over the place. After fooling with that for a couple of hours it was time for a break. So I put the motor controller assemblies back on and attached the computer deck. Seeing it partially put together helps but it's time for a break and hit it again tomorrow.
I'm good and confused now! I have each motor running in its own cog and successfully tested all three motor movements individually. However when more than 2 motors run at the same time the routines become erratic and aren't moving as expected. I re-charged the main motor battery last night just in case low battery voltage to the motors was an issue (shouldn't be a problem, battery voltage was still > 12 volts with 2 motors running).
I'm trying to devise some method of testing that can pinpoint where the problem lies. The input to each motor routine is a word global variable that the motor routines continuously monitor for changes. If the value in the variable changes then the motor control routine acts on based on the change. So each motor routine is completely seperate from each other. The only items shared are the propellor board and battery.
I identified another problem that is also going to require some thought. The standard IK routines for the angle of the tibia won't work in my design. This is because the tibia and femur motors are moving a parallelogram. As the tibia motor moves, this changes the angle between the lower portion of the leg (tibia and one side of the parallelogram) and the adjacent side of the parallelogram (femur). IK routines are based on this being a fixed angle, however on my design, movement of the femur also changes the tibia angle. A parallelogram ensures that the angle of the tibia is constant in regards to the opposite side. So this is going to require a different means of calculating the tibia angle for this situation.
If you are using three instances of the same object to control each leg, take a look for any variables in the DAT section that are hub based.
Variables in VAR sections are unique for each instance of an object, but variables in DAT sections are shared, so if you have three instances (one per motor) they could be clobbering each others globals.
This is not an issue for DAT section variables that are cog-based, but is a big potential problem for hub-based DAT data.
After a lot of testing I determined the software problem laid in the routine that calculated the new position for each motor to move to. The routine was not taking into account that 3 separate cog routines could be calling it at the same time. The fix for this issue also provided an answer for another problem! I thought I was getting this parallel processor programming stuff down pretty well but I'm breaking new ground for myself and having to learn new ways of handling software problems. Thank goodness for these forums for the ability to ask questions! I've been using the Prop forum for many of my programming issues and resolutions.
After some quiet time thinking about the problem I decided that I didn't need to go through the entire slope calculation each time an input angle changed. So using the formula for the slope of a line, (y2-y1)/(x1-x2), I calculate this value once during startup and store the value for each motor in 3 global variables. Since this is also the only place that Floating Point math is used, I can then stop the FP cog and repurpose the spare cog for something else. The results of the formula gives the change in ADC value for each degree of motion. This makes for a simple integer calculation that is performed when the input angle changes. Now there is no 'shared' functions between the motor cogs and it is behaving much better.
The current problem is that the tibia has decided to move to one extreme of motion and won't move from there. Troubleshooting shows that no matter what input angle is entered, the calculation is using 0 as the input angle. Now that I know where the problem is, I need to figure out the corrective action.
The initial base leg programming has taken quite a bit longer than I expected, but it is essential that this stuff be bullet proof before I start trying to coordinate 6 legs for walking. The ramp routines are working pretty good, all the individual motor tests went pretty well with a 1-2 degree accuracy. My testing is now more in verifying all 3 motors work together now and making a software adjustments as needed. Not too much to even video now, just endless time running a routine, watching the leg movements and then analyzing the output text for errors and anomalies. This has also provided a good running workout of the leg movements, so far I've only come across a couple of mechanical issues that required attention.
The tibia problem is fixed, had to do a work around with a local variable that was being set to -1 value after an if statement that checked to see if the value was >0. Couldn't figure out why the value was changing so I created a copy of the variable from just before the if statement and used the new variable for the rest of the routine.
After fighting the issues around running all three motors on seperate cogs I took a few days to see if I could create a motor run routine in a single cog where all 3 motor speeds would be determined, the motors started and then just loop through this one main routine while monitoring each motor. That experiment hasn't been turning out too well! Even setting up the environment for a single motor has required a lot of local variables to hold all the parameters used. I want to give it another shot but what I've experienced so far shows that the code is complex and hard to troubleshoot.
Not much to show for progress this week, I've got all three motor routines running mostly right. It's the little issues that I'm working on code for now like determining the correct values for the mechanical inertia, the ramp cut offs, and a couple of error flags that shouldn't be popping up as often as they are doing.
The motor done flag is giving me fits right now. For testing I'm stepping through an array in the main cog that is supposed to wait until all motor done flags are complete before getting the next set of 3 values. Since this routine is a simple routine and not much that can be wrong with it, I'm concentrating on the motor done flags. I need to add some print statements for troubleshooting in order to see if a motor done flag is being reset prematurely.
Not much to show for physical changes on the robot, still need to solder the 6 new prop boards together and start using them. Working on the communications between the boards will be a fun programming exercise. Someday I'll get all this working, the mechanical design was easy compared to this phase!
The motor done flag is giving me fits right now. For testing I'm stepping through an array in the main cog that is supposed to wait until all motor done flags are complete before getting the next set of 3 values. Since this routine is a simple routine and not much that can be wrong with it, I'm concentrating on the motor done flags. I need to add some print statements for troubleshooting in order to see if a motor done flag is being reset prematurely.
I got the motor done flag print statements entered and tested. It exposed some unexpected program operations that I was able to resolve. I didn't get a chance to run the array that runs all 3 motors so troubleshooting that comes after test each of the motor routines again...
For a change of pace I started soldering the first of six RoboPi lite kits. The on-line instructions are pretty good so far and the kit is fairly easy to put together. I'll get this done and then install the boards on the computer deck. I guess this means I have to work out the computer power distribution system soon. The computers will have their own battery power supply independent of the motor power. The battery will either be down in the motor battery area or mounted up on the computer deck. Although each computer board has an onboard regulator I want to have a single high efficiency switching regulator to drop the 12v battery down to around 6v. I will be looking for a DC-DC switching reg that meets those requirements soon.
I feel that I'm making progress, it just isn't as visible as when you are bolting parts together! There will be some slowdown coming up here as it's time to hit the neglected Honey Do list for spring and getting ready for the diving season. I have a new rebreather to get training on and the upgrades to the boat are just about ready for some in water testing! Too many hobbies and not enough time, this thing called work is also getting in the way...
The first RoboPi board is complete, soldered and tested! I'm removing the test prop board and mounting the RoboPi board on the computer deck. Then re-connect everything and see how she goes. In theory the application will run exactly the same! That particular test may have to wait a week as I have to prepare for my rebreather cross over course next weekend.
The only other things that got done this week was drilling the computer deck for the new computer boards and gluing the acrylic 'head' to its collar piece. When I disassembled the computer deck, I found the hot glue isn't sticking to the RGB light strips so that will have to be revisited.
Those RoboPi's look pretty slick and flexible. I may get one just for the giggles of using it with one of my many Pi - Rev B's collecting dust. On your mount for the board, are you just using double-sided tape to a plate? I've been worried that the tape might be partly conductive or static-y so I have been a little hesitant to do that. Would be a little easier to test ideas out that way though rather than designing up a full mount. The world would be 100x easier if mounting holes were created on a 1 or 1/2 inch grid. Don't know about you but I get tired of making adapters to mount boards.
Those RoboPi's look pretty slick and flexible. I may get one just for the giggles of using it with one of my many Pi - Rev B's collecting dust. On your mount for the board, are you just using double-sided tape to a plate? I've been worried that the tape might be partly conductive or static-y so I have been a little hesitant to do that. Would be a little easier to test ideas out that way though rather than designing up a full mount. The world would be 100x easier if mounting holes were created on a 1 or 1/2 inch grid. Don't know about you but I get tired of making adapters to mount boards.
I like that the I/O for the prop is all on 3 pin headers, simple to plug in stuff where needed. Even the ADC inputs use the same 3 pin header. The kit came with nylon standoffs, I used a bare circuit board to mark the computer deck wall panels for the mounting holes and drilled part way through the plastic. Once they were tapped it was easy to screw in the standoffs. Each board is held up by 2 standoffs, I would have preferred 3 mounting points but this will work. The boards are mounted vertically on the walls to leave more interior space for the battery and anything else I want to put in there. I'll post some photos once I reassemble the computer deck with the boards in place and wired up.
Don't feel bad. The RPi's mechanical layout is an abomination. Something protrudes from every side and the mounting arrangement has been lamented since day 1. At least it has mounting holes now!
It's been a while since I posted last; it's been a busy 3 weeks, I got my certification for my new rebreather, the boat changes are done, and the robot isn't getting its usual attention! Not only that but the weather is finally looking like spring so diving, bike riding and yard work are taking up time. With the nicer weather it's harder to get motivated to go work in the basement.
I took care of some simple tasks that I kept putting off like replacing the power switches with better quality switches that have LED lights in the switch. I'm also setting up to install the charging circuits for the gel cells, working on coming up with a nice looking installation that fits in with the rest of the layout.
I have to reinstall the computer deck so I can run the wires up to the RoboPi controller board. Then I'll run a quick test of the board with the motor app. If all works well then it's time to hook up the master computer and start testing communicating between 2 props. This is a new area of programming for me so I'll be looking over old threads on the Prop forum for ideas. The master will have the IK routines and just send the motor position commands in degrees of motion to the leg controllers. There will be some kind of an acknowledgement and finish signal along with status information during the move. This hardware setup also introduces a new wrinkle in that the robot is too tall for me to see into the computer deck so I have to use a step ladder to reach the controller boards! The problems of being too short never end...
Still a lot of soldering to do, many connectors to set up and 5 more RoboPi kits to finish. I want to hook up anther 2 legs and start moving 3 legs at a time also. I'll be monitoring battery voltage and current draw so I can get an idea of the expected runtime and whether or not I'll need to add another gell cell.
That's the status update for now. I'm planning on attending the Prop show this fall so the goal is to have some coordinated movement to show this year. That's still a few months off but a lot of work to be done yet.
... the weather is finally looking like spring so diving, bike riding and yard work...
At least the activities keeping you away from your robot sound like fun....ok, except for the yard work!
Still a lot of soldering to do, many connectors to set up and 5 more RoboPi kits to finish.
I hear what you mean about the soldering - I finished a RoboPi this weekend and it has like 250+ solder joints....You'll need a couple rainy weekends to get that done!
It sounds like you are making progress. I hope there's an Expo someplace nearby this year so I can see the beastie again!
Trying to figure out why my RoboPi ADC wasn't working, finally realized the Data in and out pins aren't tied together on the prop. Looks like I have to use another ADC Driver since JonnyMacs 3208 driver has them tied.... I'll have to check out the driver in the Mikronauts.com software and see how easy it will be to add/convert my code.
RoboPiObj.spin (can be downloaded as RoboPiObj.zip on the product page) configures an MCP3208 driver properly for the board... I got the driver from Obex.
Please note, the ADC is set up for 0-5V
I am back in Vancouver now, please let me know if you have any questions.
Trying to figure out why my RoboPi ADC wasn't working, finally realized the Data in and out pins aren't tied together on the prop. Looks like I have to use another ADC Driver since JonnyMacs 3208 driver has them tied.... I'll have to check out the driver in the Mikronauts.com software and see how easy it will be to add/convert my code.
Thanks for the info. That's the first place I checked was your website to see what driver you were using.
I need to put it in and modify the code now to use it, then testing all over again... O_o
This gives me some work to do, I want to get the code running on the RoboPi board by the end of the weekend. Time to go back to my testing and calibration routines to learn and adjust to the differences.
Thanks for the info. That's the first place I checked was your website to see what driver you were using.
I need to put it in and modify the code now to use it, then testing all over again... O_o
This gives me some work to do, I want to get the code running on the RoboPi board by the end of the weekend. Time to go back to my testing and calibration routines to learn and adjust to the differences.
Changing the crystal freq worked, been using a 5 MHz crystal so long I didn't even think of that as the reason for the jumbled outputs. Put in the new ADC routine, seems to be having a couple of issues I need to sort out. I need to rig a couple of switches on the RoboPi board so I can manually control the motors for troubleshooting.
Finally some success! I am using the Parallax Developer Board as a power supply for the RoboPi until I can get a nice modular switching power supply for the 12v to 5v for the RoboPi's. This also lets me easily wire in some LEDs and switches for testing. Once I got the switches wired up I was able to update my calibration routines and figured out what I was doing wrong with the ADC object. Now I've got the program running correctly or at least I'm back to where I was when I pulled out the development board!
Tonight will be spent troubleshooting a couple of error conditions that stop the motor routines from accepting any new inputs. Just have to see where and how this error breaks out of the master Repeat. If I have time after that I want to start working on the prop to prop communications and get some of the basics figured out there. I believe I can continue to use the Parallax Serial Terminal (PST) object which will simplify monitoring the comms between the props.
I haven't been spending much time on the robot later, too many summer type things to do instead! The one thing I have been doing is working on the prop to prop communications part. The master prop will send a packet consisting of a start character, leg number, command and parameter (T,1,1,90). The leg number will be 1-6, command is 1-4 (1 - femur, 2 - tibia, 3 - Coxa, 4 - other), and parameter is the motor angle.
Right now I am using the Parallax Serial Terminal (PST) to manually send the packet to the leg computer for testing. This will be replaced by the master computer later. On the leg computer the incoming packet has to be parsed out into its individual components. I'm slowly working on the parsing routine, not having a lot of luck so far but I haven't spent a lot of time actually programming so far. Mostly I've been searching the Parallax user forms searching for good examples in spin for the best way to do this.
With a lot of help from over on the Prop forum side I got the parsing routines to work for all motors on the leg. I ended up using a sequence of $,leg#,command,parameter (example: $,1,1,90 means leg 1, move femur to 90 degrees). With that done I started work on programming my Q4 digital transmitter to send data to the Xbee reciever. Unfortunately it seems the prop board that has the Xbee on it isn't being recognized. I need to troubleshoot this but its late, I'll try again tomorrow. Its a new Parallax board, never used so it should be good!
Comments
In preparation for IK testing I've been doing additional tweeting of the motor ramp routines to improve their response, especially when then the amount of movement is small. So far the Coxa and femur routines will allow as small as a 1-2 degree change. I'll be working on the tibia routine next.
I also discovered last night that I had the input angle for the femur routine backwards, the full up position should be 137 degrees, not 38 degrees. So that required a bit of re-work to get that corrected. This would have caused some serious positioning issues when the IK routines run.
I also programmed a special case for the femur routine such that if 200 degrees is entered, the leg is fully retracted which puts the robot at a minimum height for traveling. Of course that required another change to get it out of this position since both positions are outside of its normal movement range.
Another puzzle to be solved yet is programming in movement limits for the tibia and femur. At the extreme ends of movement of the femur the tibia movements can cause mechanical interference. I need to graph out where these limits are and then figure out how to keep the leg out of those regions.
I will get some more video of the tests, especially the IK testing when I get to that, possibly this weekend.
Bob
Bob
I'm trying to devise some method of testing that can pinpoint where the problem lies. The input to each motor routine is a word global variable that the motor routines continuously monitor for changes. If the value in the variable changes then the motor control routine acts on based on the change. So each motor routine is completely seperate from each other. The only items shared are the propellor board and battery.
I identified another problem that is also going to require some thought. The standard IK routines for the angle of the tibia won't work in my design. This is because the tibia and femur motors are moving a parallelogram. As the tibia motor moves, this changes the angle between the lower portion of the leg (tibia and one side of the parallelogram) and the adjacent side of the parallelogram (femur). IK routines are based on this being a fixed angle, however on my design, movement of the femur also changes the tibia angle. A parallelogram ensures that the angle of the tibia is constant in regards to the opposite side. So this is going to require a different means of calculating the tibia angle for this situation.
If you are using three instances of the same object to control each leg, take a look for any variables in the DAT section that are hub based.
Variables in VAR sections are unique for each instance of an object, but variables in DAT sections are shared, so if you have three instances (one per motor) they could be clobbering each others globals.
This is not an issue for DAT section variables that are cog-based, but is a big potential problem for hub-based DAT data.
After some quiet time thinking about the problem I decided that I didn't need to go through the entire slope calculation each time an input angle changed. So using the formula for the slope of a line, (y2-y1)/(x1-x2), I calculate this value once during startup and store the value for each motor in 3 global variables. Since this is also the only place that Floating Point math is used, I can then stop the FP cog and repurpose the spare cog for something else. The results of the formula gives the change in ADC value for each degree of motion. This makes for a simple integer calculation that is performed when the input angle changes. Now there is no 'shared' functions between the motor cogs and it is behaving much better.
The current problem is that the tibia has decided to move to one extreme of motion and won't move from there. Troubleshooting shows that no matter what input angle is entered, the calculation is using 0 as the input angle. Now that I know where the problem is, I need to figure out the corrective action.
The initial base leg programming has taken quite a bit longer than I expected, but it is essential that this stuff be bullet proof before I start trying to coordinate 6 legs for walking. The ramp routines are working pretty good, all the individual motor tests went pretty well with a 1-2 degree accuracy. My testing is now more in verifying all 3 motors work together now and making a software adjustments as needed. Not too much to even video now, just endless time running a routine, watching the leg movements and then analyzing the output text for errors and anomalies. This has also provided a good running workout of the leg movements, so far I've only come across a couple of mechanical issues that required attention.
Bob
After fighting the issues around running all three motors on seperate cogs I took a few days to see if I could create a motor run routine in a single cog where all 3 motor speeds would be determined, the motors started and then just loop through this one main routine while monitoring each motor. That experiment hasn't been turning out too well! Even setting up the environment for a single motor has required a lot of local variables to hold all the parameters used. I want to give it another shot but what I've experienced so far shows that the code is complex and hard to troubleshoot.
I guess you hit my most often done mistake with if ...
never do this
IF A>=B
it will bite you. Use
IF A=>B
same is with <= (don't) use =<
if you have the equal sign on the end it will change A
Enjoy!
Mike
The motor done flag is giving me fits right now. For testing I'm stepping through an array in the main cog that is supposed to wait until all motor done flags are complete before getting the next set of 3 values. Since this routine is a simple routine and not much that can be wrong with it, I'm concentrating on the motor done flags. I need to add some print statements for troubleshooting in order to see if a motor done flag is being reset prematurely.
Not much to show for physical changes on the robot, still need to solder the 6 new prop boards together and start using them. Working on the communications between the boards will be a fun programming exercise. Someday I'll get all this working, the mechanical design was easy compared to this phase!
Bob
I got the motor done flag print statements entered and tested. It exposed some unexpected program operations that I was able to resolve. I didn't get a chance to run the array that runs all 3 motors so troubleshooting that comes after test each of the motor routines again...
For a change of pace I started soldering the first of six RoboPi lite kits. The on-line instructions are pretty good so far and the kit is fairly easy to put together. I'll get this done and then install the boards on the computer deck. I guess this means I have to work out the computer power distribution system soon. The computers will have their own battery power supply independent of the motor power. The battery will either be down in the motor battery area or mounted up on the computer deck. Although each computer board has an onboard regulator I want to have a single high efficiency switching regulator to drop the 12v battery down to around 6v. I will be looking for a DC-DC switching reg that meets those requirements soon.
I feel that I'm making progress, it just isn't as visible as when you are bolting parts together! There will be some slowdown coming up here as it's time to hit the neglected Honey Do list for spring and getting ready for the diving season. I have a new rebreather to get training on and the upgrades to the boat are just about ready for some in water testing! Too many hobbies and not enough time, this thing called work is also getting in the way...
Bob
The only other things that got done this week was drilling the computer deck for the new computer boards and gluing the acrylic 'head' to its collar piece. When I disassembled the computer deck, I found the hot glue isn't sticking to the RGB light strips so that will have to be revisited.
Stay tuned, more coming soon!
I wish the Pi had more than two mounting holes as well.
When mounted on a Pi, the 2x13 pin stacking header also provides extra mechanical support.
I needed to limit RoboPi to the Raspberry Pi mechanical layout, so I could not readily add extra mounting holes.
I took care of some simple tasks that I kept putting off like replacing the power switches with better quality switches that have LED lights in the switch. I'm also setting up to install the charging circuits for the gel cells, working on coming up with a nice looking installation that fits in with the rest of the layout.
I have to reinstall the computer deck so I can run the wires up to the RoboPi controller board. Then I'll run a quick test of the board with the motor app. If all works well then it's time to hook up the master computer and start testing communicating between 2 props. This is a new area of programming for me so I'll be looking over old threads on the Prop forum for ideas. The master will have the IK routines and just send the motor position commands in degrees of motion to the leg controllers. There will be some kind of an acknowledgement and finish signal along with status information during the move. This hardware setup also introduces a new wrinkle in that the robot is too tall for me to see into the computer deck so I have to use a step ladder to reach the controller boards! The problems of being too short never end...
Still a lot of soldering to do, many connectors to set up and 5 more RoboPi kits to finish. I want to hook up anther 2 legs and start moving 3 legs at a time also. I'll be monitoring battery voltage and current draw so I can get an idea of the expected runtime and whether or not I'll need to add another gell cell.
That's the status update for now. I'm planning on attending the Prop show this fall so the goal is to have some coordinated movement to show this year. That's still a few months off but a lot of work to be done yet.
Bob
It sounds like you are making progress. I hope there's an Expo someplace nearby this year so I can see the beastie again!
Please note, the ADC is set up for 0-5V
I am back in Vancouver now, please let me know if you have any questions.
I need to put it in and modify the code now to use it, then testing all over again... O_o
This gives me some work to do, I want to get the code running on the RoboPi board by the end of the weekend. Time to go back to my testing and calibration routines to learn and adjust to the differences.
I answered your other question in the RoboPi thread, you need to set _xinfreq for 6.250MHz
Tonight will be spent troubleshooting a couple of error conditions that stop the motor routines from accepting any new inputs. Just have to see where and how this error breaks out of the master Repeat. If I have time after that I want to start working on the prop to prop communications and get some of the basics figured out there. I believe I can continue to use the Parallax Serial Terminal (PST) object which will simplify monitoring the comms between the props.
That's it for now!
The 12000mAh packs last for 8h-10h for a Pi+RoboPi combo, so they would last a LOOOONG time for six RoboPi's!
http://www.ebay.ca/itm/12000mAh-Power-Bank-External-Battery-Backup-USB-Charger-For-Cell-Phone-Universal-/181374579709?pt=US_Cell_Phone_PDA_Batteries&var=&hash=item2a3ac473fd
Definitely higher quality, but a lot more expensive:
http://www.patriotmemory.com/product/indexp.jsp?source=0&prodgroupid=264&prodline=6&group=FUEL&catid=100&src=6
Both work great for robotics!
I've heard, but not experienced, that some of the inexpensive ones may have a noisy output. Some filtering would cure that!
Right now I am using the Parallax Serial Terminal (PST) to manually send the packet to the leg computer for testing. This will be replaced by the master computer later. On the leg computer the incoming packet has to be parsed out into its individual components. I'm slowly working on the parsing routine, not having a lot of luck so far but I haven't spent a lot of time actually programming so far. Mostly I've been searching the Parallax user forms searching for good examples in spin for the best way to do this.