I thanked everyone over on the Prop 1 forum but I decided to go ahead and try another approach to setting up the communications from the legs back to the master.
My master board is a Parallax Activity Board which is handy due to the breadboard mounted on the circuit board (and XBee socket!). However it has lots of addtional circuits so the number of easily available I/O pins is limited to P0 through P15. I can also get to the P16 and P17 pins via the servo connection so there are 18 total I/O pins to use. I use 3 pins for the RGB lights and 2 pins for the master to leg communications. To implement a star configuration from the master to the legs I need 2 dedicated lines (Rx and Tx) per leg, or 12 I/O pins total. That uses up all the available I/O pins on the master computer (without hacking the circuit board at least). Quick question, since I am only using the Rx line on the master, is it possible to tie all the Tx lines during port setup to the same master pin in the software instead of having 6 unused serial connections?
I added another 4port serial object, actually used a different 4port object to link in. After moving all my hardwired connections around for the RGB and master to leg communications (then testing to make sure I didn’t mess it up!) I am starting with a single leg setup and will add additional legs as I verify operation. So that should keep me busy today.
Coming up on a short get away from home, time for a visit to my favorite electronics surplus store, Skycraft Surplus, down in Orlando Florida and pick up some supplies! Time to get away from this cold Michigan weather for bit. I want to get as much done on the robot before summer since I won’t have much time available to work on it due to traveling.
Odd that it doesn't work. I had all 5 of my P1 boards communicating with each other over a single wire (plus common ground of course). Only difference between what you are trying to do and my setup was that I used a different pin.
My boards were basically set up the same way just without the in-line resistor. I have 2 seperate lines for transmitting from the master to slaves, one worked and the other one didn’t.
One line is for movement commands from the master. The other was going to be for coordinating when the leg computers could send feedback to the master. I set it up this way since movement commands are intermittent since they have to wait for signals from the legs when a movement had completed before sending the next movement. I wanted the feedback from the legs to be continuous during movement with updates back to the master. Right now I’m just sending back motor direction and when a motor stops, but I will be adding additional sensors for the master to react too such as when a leg touches the ground or encounters an obstacle. Thats why I want continuous monitoring from the legs.
Since I am going to change the code from a ring network to a star configuration the master will only have one transmit line to all the legs but all the legs will have their own Tx line into the master.
Getting to work on coding the star network for the robot. I started with the last version of the master and leg software that worked before I started the ring network setup. Setting up the leg software was pretty easy, just pushing the motor status flags out via the 4 port serial object. The master software is turning out to be a bit trickier. I got the first 2 legs (#3 & #4) connected and outputting status flags to the RGB lights, very pretty! At this point I had to add another copy of the 4 port serial object. Since I know the software has to be different in name and internally, I used another 4 port serial object that someone else modified. I connected the next leg (#5) up to it and now only leg #3 works, leg #4 stopped displaying and leg #5 isn’t showing up on the new serial port either. O-scope shows good signals coming out the of the legs, so the problem has to be in the master software.
Got to the point where I wasn’t getting anywhere troubleshooting so called it a day and will start early tomorrow to figure this out. I will add some more debug statements to the terminal to help figure out the problem. I have a hunch its in the master receive routine code where I tell it to use another object to retrieve data from #5.
The star network configuration is working! Ran into a few issues to resolve but managed to figure it out. I did change to using the same 4port serial object and just changed the name and version number in the code. Wiring inside the computer level is getting messy, I need to take some time and clean that up some, getting hard to stick the o-scope probe in there without disturbing everything. Plus I have more sensor wires to bring up there eventually.
Here is a photo of the RGB feedback lights in action, currently all green since all legs are at the requested position. This is just for looks/troubleshooting, the real information I want out of this is when a motor has stopped moving.
Finally got the 50amp connectors in the mail, need to wire these into the battery along with a master fuse. Huge connectors but these shouldn’t melt!
I did run into some problems finishing up this code, mostly issues with leg #5 where it was the only leg that wasn’t consistently outputting data to the master despite using the same code as the other legs. I added some more debugging code and then the computer couldn’t see the propellor chip on the board. The green power LED on the board was lit but no response. I cycled the power (unfortunately there is no manual reset on the boards, I may have to see about adding something to the circuit) but still no response. I was starting to get worried that I had damaged the chip. When I disconnected Leg#5 power connector I saw that the power LED was still lit? So I measured the power coming from the power plug and it was 0volts. Come to find out the fuse had blown and power was being backfeed to the board at 1.7volts, just enough to power the LED but not enough to do anything else. After running to the store to get more fuses, replaced the burnt out fuse, re-installed the program and everything started working!
Next step is to use that new feedback network to also get leg angle data. One item that’s needed especially after startup is knowing where each leg is physically located. Small hexapods have a startup routine where they can just move their legs to a default position from wherever they are. I can’t do that safely and don’t want to damage a leg(s) by unexpected movements. The leg controllers already calculate current leg angles for each motor so it was a matter of getting that data to the master computer. I created another buffer to load and transmit the 3 angles right after the motor status flags are sent. The master computer looks for this other data dump and stores it in arrays. Now the data can be used to figure out how to safely get the robot to a default starting position after power up.
I got one leg setup and returning the right angle data, next step is adding all the other legs and make sure it doesn’t adversely impact leg motor status data.
OK. having 2 4-port serial objects in the master is way better then a ring wiring. I did not know that you had a spare COG, cool. Mike
I would still like to know why I couldn’t get the ring network code to work right, I may need that capability at some point to free up I/O pins. The bad thing now is that the master doesn’t have any open I/O pins left for me to use, all the other pins on the Activity Board are wired into other circuits that I’m not using. That’s not a problem now but may become an issue at some point when I add other sensors. I’ll just cross that bridge when I get to it.
I’ll free up another cog by getting rid of floating point calculations and doing everything in integer math soon. I really could use the speed increase! My initial observations with some simple movements is showing a definite speed issue with the leg response. I’m putting together a simple lower the body and raise it back up again movement using Inverse Kinematics (IK) so that the feet stay in one place as the body moves (this will be better tested code than the earlier video where the robot tried to fall over!). It’s a simple movement yet requires IK to keep the leg tips in one place so all motors will be engaged. I wrote the base code but it isn’t complete yet but the leg movements are slow and jerky as its waiting for the calculations for each leg to complete. I will video this once its running and then re-do everything in integer math and then run the same routine. I would expect a significant speed difference with integer math.
All the legs are returning angle data to the master. With that information I spent the evening working on Forward Kinematics equations and getting them down on paper. This is the reverse of Inverse Kinematics where you start with the angles and work back to the X,Y, and Z position data. It took a while to figure out the equations but it came out to 9 steps to get from the Femur, Tibia and Coxa angles to the X,Y, and Z distance values.
I still have to test the equations and verify that I didn’t make any math mistakes and then program the code. At this time I only need to calculate this once during initial startup so the code knows exactly where each leg tip is located. Then the program can safely move the legs to whatever position is needed.
Kinematics! And to thing that I got excited after learning right triangle trig! This is another level of math man!
Math was my college major.... Its funny how if you don’t use it how fast it goes away in the mind! I have to google the basic trig functions and identities. The good thing is that once I see them again I still remember how to use them!
My first pass on the formulas was a bust, came up with very wrong values for X,Y and Z after manually plugging in numbers on a calculator. So I re-examined everything and found that I made a bad assumption on figuring out one angle inside the parallelogram. Then it took some time to figure out how to get the initial angles correct. This added another step to the process so now there are 10 math steps to take to arrive at a solution. I still have something not quite right, the X and Z values are within tolerances (+/- 0.5”) but the Y value (height) is off by almost 1.3 inches. So I’m not sure how the X and Z are right with the Y being that far off.
I need to get a yardstick and measure the actual height since I got the angle numbers from the robot feedback routine after I told it to move to a specific location. If the equations were correct I would expect the X,Y, and Z output would closely match the input X,Y, and Z values.
I will move the robot into some other positions and see if it is a consistent error or not. However that will have to wait, heading tomorrow to sunny Florida for a winter break!
Sunny Florida has sun but its cold down here! 34º overnight! I shouldn’t complain, it was 12º back home and snowing. Anyway I had a successful scavenger hunt at Skycraft Surplus, one find that I’m looking forward to working on is a hand-held digital o-scope kit. The display model looked pretty nice so I figure I can always use another toy for monitoring signals on the robot if my bench top o-scope isn’t nearby.
I brought all my Forward Kinematics equations with me, trying to verify that I didn’t make any other poor assumptions on calculating the angles and leg positions. So far everything looks good. I’m looking forward to start programming the calculations in once I get back. This might be a good items to start with converting over to integer math to speed up the calculations.
Time to post an update! Since I’ve gotten back from our trip I’ve been working on the Forward Kinematics equations. I programmed them into the master computer with a lot of debugging print statements for troubleshooting. Of course the first round came up with X,Y, and Z values that weren’t even close to the values I had the master move to the legs too. The idea is that the Forward Kinematics output should take the actual encoder values, convert them to angles and then convert those angles back to X,Y and Z values that match what I put in originally.
I found a couple of math errors (using Radians instead of Degrees messed me up for a while until I figured out the calculator I was using wasn’t on the right setting...). Today I started over from scratch and did a step by step approach on paper showing the information that I had and the information that I needed to calculate. I think I finally got close, just have to figure out a couple of inconsistencies that aren’t making sense yet. I find that if I write everything out long hand, in pencil, on paper first I tend to make fewer mistakes.
I will have to post the calculations and assumptions (need to draw up the angles and lengths that go into the calculations also), that helps me understand what I’m doing and makes it easier to find bad assumptions.
Still working on the math, had to take a couple of days away from it since I kept making the same assumptions. I believe this is pretty close to being right, so I’ll code the formulas in and see what kind of values I get out of the other end of the routine.
I programmed in the formulas from the previous entry into the master controller and discovered a couple of math errors that I was able to correct (math was right, just selected the wrong values to put into the formula). The next issue was that the output values for some of the steps didn’t come close to matching what I manually came up with using a calculator. After breaking each formula down to its basic steps and printing out the results I found that the Sine and Cosine values weren’t coming out right. Thats when I realized that the calculator is using Degrees and the Floating Point object assumes that SIne and Cosine inputs are in Radians. Once that was cleared up the calculated position outputs were a very close match for the entered values.
Did some more experimenting with using the Motor Done flags to control program speed vs. using pauses in the program. That went well and should help with program execution on other routines. I created a routine to control the coxa motor speed from the master. When the coxa moves it creates a pretty big jerk to the robot so now I can reduce the overall speed which reduced the amount of jerkiness. The leg controllers were already setup with motor speed control, just needed to call it up from the master.
Since I had created a routine that changes the height of the robot while keeping the X and Z leg positions the same, now I need a routine to move all the legs to a specific X and Z position while keeping the height constant. This item is what requires knowing where the legs are currently located so I can see what legs are currently on the ground so legs can be lifted and moved to the new position so they can take up the robots weight. Then the remaining legs can be lifted and moved to the new position. Between these two routines I can adjust the robot height and leg position. The other purpose is to be able to move the robot to a default position after startup regardless of the leg positions it was left in previously.
I got tired of moving the wood test stand in and out so I replaced it with a hydraulic motorcycle lift. It works pretty good however the top of the stand is too big so it interferes with the leg movements so I had to add an old paint can to give it some extra lift away from the top. Between this and the block and tackle I think I’m in good shape for avoiding an accidental robot fall.
The last few days have been spent creating and troubleshooting various movement routines that run on the master computer. I added some additional safeguards to the code for moving the body up and down while the feet remain in place. Another routine allows me to move the feet around while maintaining the height constant. I re-visited a routine to move the legs to a narrower stance so that it will be able to travel through doorways while walking and updated that with additional safeguards.
Tonight was spent getting started with initial setting up of a gait program for all the legs. All my testing so far has been with a single leg making the movements needed to walk. Now I have to add in the other 5 legs. First thing needed is map out the coordinates for each leg in relation to the center of the robot body. The original CAD files have the dimensions of the main body as a starting point. Then each leg is located in relation to the center of the robot body so the individual leg coordinates can be coordinated together.
Another thing to do this week is installing some of the cool gadgets I got from Skycraft Surplus! I found a 75 amp shunt so I can start measuring total current draws off the battery and figure out what kind of battery life to expect (and determine if I need to look into Lithium power cells sooner than later). I’d like to get 1-2 hours of runtime if possible. Another item I got was a nice white LED array to install inside the main motor deck. Now its so dark in there that when I remove a leg I need a flashlight to see anything inside there, this light will be controlled by a manual switch and should make it much easier to trace wires inside that area. I also have a Lascar Electronics 4.3” color touch panel that I started programming. This would replace the existing Lascar 2.5” display panel as it provides a lot of additional options for display (4 voltage inputs, several digital inputs, output alarms, etc.) This way I can monitor main battery voltage and current, DC-DC converter output, and generate alarms in case of low voltages or high current levels.
I found out a few things that need correction from doing testing with the robot standing on its own feet that haven’t been revealed until this point.
First, the robot is ‘wobbly’ in that it rocks from side to side too easily. This comes from the fact that the bottom piece of the legs uses o-rings between it and the mounting block, it is not a solid connection. The plan had been to use this as a method of measuring side forces if the leg hit something. I used several very high density o-ring as spacers but with the weight of the robot they allow too much motion. I expect that I will have to figure out how to hard-mount the leg bottoms into the connector block. Maybe look into strain gauges for measuring side forces instead.
The second item is that the leg bottom switch mechanism is not going to work as designed. The switch is supposed to be activated when the leg has placed at least 25 lbs of force on the surface, however that only works if the leg is mostly perpendicular to the surface it is touching. As the leg is extended the switch isn’t getting activated. Plus, if I make the changes discussed in the first item then the leg isn’t going to move at all.... Time to revisit this problem, I think the switch is going to have to be mounted down at the tip of the leg to allow it to activate. Just have to come up with a mechanism that attaches to the leg tip now.
Thirdly, with all the legs down and touching the ground there is some variance in the amount of pressure they are exerting, mainly some legs tend to take up more weight than others for the same input position from the master computer. This could be a calibration issue when excessive such as when one leg is still in the air when all the others are on the ground, but mostly its just slight differences how each leg reacts to motion requests. This is mostly seen in the Femur control, although the Tibia shows some angle issues also. I need a ‘tweaking’ factor to the femur/tibia that can be applied from the master computer to compensate for this situation. Just another calibration to perform!
Back to the workshop for another day of work! Got a lot to do before my summer break!
Today was a hardware day, started out working on hardware issues noted in the previous posting. First job was making a space for the new shunt on the power output from the battery. The shunt is 0.1 ohms, makes calculating amps easy. I don’t have anything connected to the shunt for measuring the voltage drop yet.
This is the new 50 amp power disconnect for the battery. It seems pretty heavy duty and it will be fun to get that thing apart next time! The smaller disconnect on the right is for power to the 12v to 5v DC to DC converter used by all the computers for power and isolation from the voltage swings when the motors are operating.
This is the new 12v LED light for the inside of the robot. The next photo shows it installed and it lights up the interior very nicely. I need to add a switch but couldn’t decide where to mount it. So in the meantime I used an extra 2 pin connector that I can manually disconnect when it isn’t needed.
No pictures but I used the metal lathe to turn a new connector for the leg so the leg doesn’t have any extra flex in it. Didn’t try it out tonight, if it works then I need to make 5 more. Still thinking on how to create some method of signaling when the leg is on the ground.
Finished up the 6 new solid leg connectors on the lathe and installed them on the legs. It has a more solid feel to it now. There is still some movement due to the coxa gear train has some slop in them but for now it is acceptable. So now I’m ready to get back to programming.
I’ve been thinking how to mount and trip a microswitch from various angles based on how much the tibia is extended. I’ve looked for switches that can activate when a front or side load is placed not the switch, so far I haven’t found any candidates.
The other issue mentioned before is coming up with some method of adjustment for legs that even after calibration are not setting on the ground at the same angle as the other legs or with the same amount of pressure on the ground. I think I want to have a adjustment routine based in the master that I can determine how much out a particular leg is as compared to the other legs. Then that value can be sent to the individual leg so that when a movement command is received it automatically applies the adjustment. By having the adjustment value saved in the master computer that avoids having to reprogram individual leg programs for something as simple as a variable change.
Been thinking on the calibration adjustment idea and came up with a solution I trying out.
I already have the individual leg controllers reporting back to the master the angles each motor is at. Once I run the Inverse Kinematics routine I have the requested motor angles. By using the IK routine, then have all the legs go to that position, after the motors stop I can get feedback on the actual angles the motors stopped at. I wrote a routine to compare the two values, actual vs. requested, and if the difference is more than 1, save the +/- difference in an array. The results of the array are used to add or subtract from the next calculated IK output before the next movement request is sent. I have some more experimenting to do to see how well it works and how often I should run the routine. Right now I’m only running it on startup but I want to see how the error values change over time. So far it looks promising, when I sent a movement command, the errors were determined and when I sent the same movement command I saw the legs adjust themselves to more closely match the request.
Still working on ideas for sensing when the leg tip has touched the ground. I’ve been looking for mechanical mechanisms that can trip a microswitch reliably from a variety of angles between 10º and 90º, but haven’t found anything useful yet. One idea is to not use a micro-switch but instead use the flexible resistors I was going to use for side impacts instead. Create a rounded shape for the leg foot that one of these resistors can be attached to. This could be the means of being able to sense a wide variety of angles that the foot is capable of touching the ground with. I’m not sure how durable they are in the long run. I also need some means of protecting the resistor from abrasion from direct contact with the ground and how would that impact the resistance readings.
The idea of real time error correction is genius, and this is an excellent use for it! As for footpad switches, you could maybe use the flexi-force pressure sensors sold by Parallax or similar units.
Tried to do some testing of the automatic calibration programming but kept running into an issue where leg #5 and #6 tibia motors were not moving as far as needed. I figured I had an individual leg calibration issue. On leg #6 I moved the tibia from one extreme to the other and the low end encoder was off a bit. Fixed that setting and moved on to Leg #5. I got it to move to the extreme position and then it just refused to move. Finally I disconnected the motor from the leg and the motor would not operate with voltage applied to the power plug.
This required me to disassemble the motor on the linear drive and I found the carbon brushes were not contacting the commutator. So some quick repair work to remove the brushes, run a small file inside the plastic brush holder to and freed up the obstructions so the brushes moved freely again. Re-assembled the motor and verified it worked before putting it back on the robot so I could finish the calibration.
I need to buy a couple of replacement drive motors, one of these days I’m going to get one that I can’t fix. There was some evidence of heat damage, as the motor itself was cool I believe this occurred before I added the additional program steps to reduce the probability of having a locked rotor situation.
I’ll get back to testing the auto calibration routines in the morning....
I accidentally left the robot on for several hours and while working on it later that night I started getting odd behaviors. It turned out that the battery was down to 7.5v, hopefully that didn’t damage the battery too badly. I got it back on the charger overnight and it was good this morning.
The auto-calibration mode seems to be working fairly well, it gently tweaks the output from the master to the leg controllers. I limited the routine to allowing no more than a +/-5º change, anything more than that implies that the individual leg calibration is off. As part of the testing I started using the motor done flags coming into the master from the legs to signal when a motor movement is complete. I ran into the situation where a leg would get close but still not make it to the deadband because the motor isn’t getting enough power to move. So I made a slight change to the deadband from 1 encoder count to 2. This changes the angle resolution by +/-1.1º.
With most of the issues completed off my checklist, I started work on creating a tripod gait routine. First step is to figure out how to intergrate the body coordinates to the individual leg coordinates. This is tricky as legs are mounted every 60º around the body. I put together a scale paper diagram on graph paper of the leg arrangement so I can figure this out. I need to be able to move the center of the robot body a set distance and direction. That distance and direction needs to be replicated by each leg under their own coordinates. Its just trigonometry but I’m drawing a blank on how to solve the problem right now. I’ll take some time to think about it and try again later.
I’ve been keeping the robot battery on a smart charger so the voltage stays up where it is supposed to be. Without the charger the battery voltage drops quickly so it looks like the battery got cooked. I’ve started looking for Lithium Iron Phosphate batteries with integrated Battery Management Systems (BMS) and am planning on getting something around the 25-30 Ahr range. They are pricy but are lightweight and maintain voltage better than a lead acid battery.
I’ve spent several days working on the math for translating the body movement coordinates into the individual leg coordinates. This way moving the body center 4 units in the Z direction and 5 units in the X direction, each leg is moving the same direction and distance. My initial calculations ended up being overly complex (although they did work!) and way too many steps to translate the body position into leg positions. Finally I had the proverbial light bulb go off (while standing in the shower of course!) and realized that since I already had the X and Z values for the movement, all I had to do was calculate the movement angle and the distance of movement for the body. I already know the angle each leg is located at compared to the center of the body. The math ended up being much simpler!
Using the Pythagorean theorem the stride length is calculated based on the input X and Z values. The movement angle is the arctangent of dividing Z by X values. Legs are positioned every 60º around the center of the robot. If leg #1 is at 90º to be the top-most leg (looking down on the body from overhead and in-line with the Z axis), then leg 2 is 150º, Leg 3 is 210º, Leg 4 is 270º, Leg 5 is 330º, and leg 6 is 30º. The movement angle is subtracted from the leg angle (ie, for leg #6 at 30º, if the body movement angle is 20º then 30º-20º = 10º. Using sine and cosine, the new X and Z values can be calculated (X = stridelength * sine(leg angle) and Z = stridelength * cosine(leg angle)). I’ve run the calculations manually using a calculator and putting them on graph paper to verify and so far everything looks good. Today I’ll start programming in the calculations and see where that leads me. A neat trick is that I only have to do the calculation for 3 legs, the other 3 legs are the same X and Z values but are in other quadrants of the circle. So if leg #1 is moving x=1 and z=2, then the leg opposite (leg #4) moves to x= -1 and z= -2. This will help speed up calculations since I only have to do half of them!
The next step in the gait routine is to get the legs from their starting point to the new position. The stride length distance will be broken up into short segments of about 1/4”. So if the stride is 4 inches, then there will be 16 segments to the move, with equal movements in the X and Z directions. The leg IK routine will be called for each segment to calculate the angles needed. This keeps the leg moving towards the end position and the short segments help ensure the leg is moving in a relatively straight line (I may have to adjust the 1/4” segment length either smaller or larger depending on how the legs respond). Too large a segment length can result in slippage at the leg tip and too small a segment can use too much time for the master computer to complete all the calculations resulting in jerky movements. A tripod gait will be the first gait where there are always 3 legs down and 3 legs up. The down legs move the body forward and the up legs are moving back into position to complete the next step.
On a side note, an issue I recognized a while back is finally going to rear itself now that I’m working on actual walking. As designed, the tibia angle ranges from 0º to 52º. At 0º the tibia is perpendicular to the ground and this was expected to be the normal position. However, this doesn’t leave any room for the leg to move while walking. For example, if the stride length is 4 inches, the leg on the side the movement is heading can extend the 4 inches needed. However, the leg on the other side can not move the leg to less than 0º. The simple solution is to move the tip of each leg out further from the robot body so all legs can move 4 inches in any direction. This has the effect of needing a wider area for the robot to move, which will cause issues when trying to move through a doorway... The longer term solution is to change the tibia motor mount to a smaller angle which would allow the tibia to move the leg tip to be in-line with the coxa pivot point. The photo shows the current 30º angle on the mount, reducing that angle will allow the leg tip to move to positions less than 0º.
I’ve been working on coding the tripod gait into the robot for several days. At first I did the brute force method, mainly to check out response times and get a general idea of how the coding should go. I didn’t actually get to the point of making the robot walk but I identified and corrected some mechanical and coding problems or at least found workarounds. The most exasperating issue is working with the motor done flags, in some situations the motor stops outside the motor movement dead-band with the motor still engaged but there isn’t enough power flowing to get it to actually move. Since the program is waiting for all the legs to finish moving before starting the next movement sequence, the code hangs up waiting for a motor that never gets to where its supposed to go. I believe this is occurring because I purposely limited the amount of the Integral value in the leg controller PID loop. It should be increasing steadily each loop of the program until the motor starts moving but I think its never getting large enough to reach that point. I need to determine the minimum amount of power needed to actually make the motor move when its under load and make sure the motor gets that so it can move... In the meantime I put in short milli-second pauses in place to allow time for motor movements until I can get back to the leg controllers.
I looked over several other people’s gait coding they used for their hexapods and tried some of their ideas. In the end I’ve come back to an even simpler method inspired by the propellor based hexapod code written by another Parallax forum member, Paul K.. His code was the easiest to wade through and understand. I’ve heavily modified it as at this time I’m only going to use a single gait for walking. I am also not incorporating any body roll or yaw movements at this time (I will need that when I want to climb stairs to keep the center of gravity centered). There are many other changes since I don’t use servos and am sending angle data directly to the leg controllers to control their movement.
So far I am only controlling a single leg, will be adding a second leg in a couple of days once I’m sure I have most of the bugs worked out of the code for moving a single leg. In my previous post I was working with translating the movement of the body coordinates to the individual leg coordinates, it turns out I was making it overly complicated. Now I just send the same angle data to each leg but add in + or - 60º to the front and rear legs and 0º to the legs on the side, and that ensures the leg is moving the right direction. I’ll get confirmation of that assumption once I add a second leg!
Continued testing has the advantage of ensuring that I understand and see issues fairly quickly. I see that I still have some calibration issues to fix on a couple of legs. I turned off the auto-calibration routine while I’m testing the gait, it’s harder to see patterns in my debugging display when the data is being actively manipulated!
I started to video some of the testing movements and will compile a new video of the progress once I get some more to show.
Still working on the robot walking routine, had to do some more tweaks to the leg controllers due to the motor done flag not getting set and the leg wasn’t moving. There is a range of input values around the motor stop value to the HB-25’s that just don’t provide enough power to the motors to get them moving reliably. I reinstated the code to check if the encoders aren’t changing so it kicks the controller out of that loop. Plus the individual leg calibrations were updated. Now I’m not seeing as much position variation in the legs as I was earlier. I want to code a simple test with each motor under load and see what input values are needed before the motor starts turning. Then I can create a movement dead zone in the code.
I continue to play with the master computer gait program using just one leg, still not satisfied with the movement I am seeing, the motion isn’t smooth and the leg doesn’t seem to be moving consistently to the right locations.
I’m running out of time for coding, soon we are starting our summer trips so this will go on the back burner until fall. I plan on taking a P1 experimenter board and my LIDAR unit with me to work on during rainy days on the road, maybe get that finally going.
I haven’t been on here in a while as I have been traveling the USA in our RV, we were out almost 6 months on the road last year. Finally caught up on house and yard work so got to spend some time with the robot again.
Its been a while so first thing was reviewing the last version of the program code to see where I left it and then turned it on and let it rip! Of course I had one leg not wanting to cooperate so that took some troubleshooting but now everything is back and running. After some more testing I still don’t get the smooth operation of the legs when running under IK that I want. Starting to think all that FP math is just too much for the P1 master computer.
I am starting to look into using another computer chip for the master, one that is faster and can handle the FP calculations required. The P2 chip looks like its almost ready to go, need to do some reading on the P2 forum and see what programming tools are available. Hopefully it has its own version of SPIN since I really like programming in that language!
In the meantime I want to finish up some of the hardware items on the robot like getting the leg down touch sensors figured out and a few cosmetic items.
Welcome back Bob! I wish the P2 was more mature so you could jump in. The hardware is there but SPIN2 is a little way off, maybe just weeks. You can sure benefit from some of the new instructions in the P2.
I was worried that you where pinched and held hostage by your robot in your own basement, and you just did a road trip!
Actually some thing I am looking forward to do too, alas in about 10 years if I even EVER will be able to retire.
Good to have you back here, yes the P2 is reality and thanks to @ersmith one can program it very comfortable from Spin 1.5, Eric's own Version of SPIN with P2 extensions.
The current problem with the P2 is that all the documentation and existing driver are still just scattered around the forum, Parallax is starting to set up a new OBEX via GitHub and the guys actually playing with the P2 dev modules are still in the stage of - lets test if (and how exactly) this feature works, so there are tons of sample out but no accepted standard drivers. It is all in the flux, still but it is wonderful.
The basic things are there, serial, USB, video, a bunch of languages/compilers. It will need some time to get this organized/packaged and documented, but I am pretty sure that Parallax will make sure that all of this will be Parallax Style awesome.
But the first thing you should do is try out Eric's Flexgui and his SPIN 1.5. It does not just work for the P2 it works with the P1 also.
And it compiles P1 SPIN to P1 PASM (LMM) thus is WAY faster then the SPIN interpreter, but need more space also, SPIN byte code is compact, PASM (LMM) needs more HUB.
But your P1 LEG controller might gain a lot of speed/reaction response if compiled by flexgui/fastspin as long as they still fit into HUB.
The good thing would be that you can just use the code you have and gain speed, instead of switching the MC and rewrite everything.
The master P1 should be definitely replaced by a P2. But the legs could just stay as they are.
Welcome back Bob! I wish the P2 was more mature so you could jump in. The hardware is there but SPIN2 is a little way off, maybe just weeks. You can sure benefit from some of the new instructions in the P2.
I was doing some reading today, looks like lots of I/O options, faster chip and more memory. Sounds like Chip is working on Spin2 now. It also sounds like Spin2 is also going to be compatible with the original Spin code too. I will continue to do some studying and start watching the P2 forum closer.
I had to study my code some more and read some of my later entries in this forum to get back on track with where I left the code off and the hardware issues. Still need some means of knowing when a leg is touching the ground so I was looking at strain gauges again. These could possibly be attached to the aluminum lower legs but there is a lot of additional hardware needed to make them work. A simpler option is using flexible force resistors that can wrap around the end tip of the leg. That only needs a voltage divider and ADC to work. I’ve got to look at the leg code and see if I have any left over cogs to run the ADC on the leg controllers. This requires machining new tips for the end of the legs so the resistors can be attached, working on some design ideas to test the concept.
I was worried that you where pinched and held hostage by your robot in your own basement, and you just did a road trip!
But the first thing you should do is try out Eric's Flexgui and his SPIN 1.5. It does not just work for the P2 it works with the P1 also.
And it compiles P1 SPIN to P1 PASM (LMM) thus is WAY faster then the SPIN interpreter, but need more space also, SPIN byte code is compact, PASM (LMM) needs more HUB.
But your P1 LEG controller might gain a lot of speed/reaction response if compiled by flexgui/fastspin as long as they still fit into HUB.
The good thing would be that you can just use the code you have and gain speed, instead of switching the MC and rewrite everything.
It was a good time traveling, 10 weeks to Alaska and then 8 weeks in the southwest along with several other shorter trips around here. Looking forward to a northwest trip this summer and diving in the South Pacific in late fall. Somehow I need to carve out some time for the robot!
I read about Eric’s Flexgui, didn’t realize it worked on the P1 also. I will download it and give it a try with my master controller and see if I can get some speed improvements with the FP math. I remember that at one point I was looking into using lookup tables for sine, cosine and see if I could do all the math using integer math to help speed things up. There were some good articles out there on some other forums with tips on how to use integer math to simulate floating point.
It does not just work on the P1, it also allows you to write objects in C or BASIC to use with spin as if they are spin objects, and C and BASIC support Floating Point, so you could write small FP routines in say BASIC an use them from your Spin Code.
I seem to sound like a fan-boy, but what Eric has done there is simply mind boggling. He seems to have the passion and skills you have for machining things just using it in his software forge.
I am programming for a living since ~30 years but I am just a Code Monkey, I just do grunt work and never reached the high paid jobs out there, always went for the more secure options.
But I did work with famous teams and I am able to see and admire good work even if my own skills are way below it. Unlike the Dunning Kruger Effect I know my limitations.
Over the last years I always pointed out that @JonnyMac has the most consistence and readable code, hoping that other would follow, I myself try to learn from his style to write things.
But the sheer AMOUNT of work Eric did put out for the P2, makes me wonder how he does it.
I barely find time to throw in 1-2 hours a week for the P2.
Anyways look for multi language integration since C and BASIC support FP and are integrated easy into a SPIN project.
Comments
My master board is a Parallax Activity Board which is handy due to the breadboard mounted on the circuit board (and XBee socket!). However it has lots of addtional circuits so the number of easily available I/O pins is limited to P0 through P15. I can also get to the P16 and P17 pins via the servo connection so there are 18 total I/O pins to use. I use 3 pins for the RGB lights and 2 pins for the master to leg communications. To implement a star configuration from the master to the legs I need 2 dedicated lines (Rx and Tx) per leg, or 12 I/O pins total. That uses up all the available I/O pins on the master computer (without hacking the circuit board at least). Quick question, since I am only using the Rx line on the master, is it possible to tie all the Tx lines during port setup to the same master pin in the software instead of having 6 unused serial connections?
I added another 4port serial object, actually used a different 4port object to link in. After moving all my hardwired connections around for the RGB and master to leg communications (then testing to make sure I didn’t mess it up!) I am starting with a single leg setup and will add additional legs as I verify operation. So that should keep me busy today.
Coming up on a short get away from home, time for a visit to my favorite electronics surplus store, Skycraft Surplus, down in Orlando Florida and pick up some supplies! Time to get away from this cold Michigan weather for bit. I want to get as much done on the robot before summer since I won’t have much time available to work on it due to traveling.
Bob My boards were basically set up the same way just without the in-line resistor. I have 2 seperate lines for transmitting from the master to slaves, one worked and the other one didn’t.
Jim
Since I am going to change the code from a ring network to a star configuration the master will only have one transmit line to all the legs but all the legs will have their own Tx line into the master.
Got to the point where I wasn’t getting anywhere troubleshooting so called it a day and will start early tomorrow to figure this out. I will add some more debug statements to the terminal to help figure out the problem. I have a hunch its in the master receive routine code where I tell it to use another object to retrieve data from #5.
Here is a photo of the RGB feedback lights in action, currently all green since all legs are at the requested position. This is just for looks/troubleshooting, the real information I want out of this is when a motor has stopped moving.
Finally got the 50amp connectors in the mail, need to wire these into the battery along with a master fuse. Huge connectors but these shouldn’t melt!
I did run into some problems finishing up this code, mostly issues with leg #5 where it was the only leg that wasn’t consistently outputting data to the master despite using the same code as the other legs. I added some more debugging code and then the computer couldn’t see the propellor chip on the board. The green power LED on the board was lit but no response. I cycled the power (unfortunately there is no manual reset on the boards, I may have to see about adding something to the circuit) but still no response. I was starting to get worried that I had damaged the chip. When I disconnected Leg#5 power connector I saw that the power LED was still lit? So I measured the power coming from the power plug and it was 0volts. Come to find out the fuse had blown and power was being backfeed to the board at 1.7volts, just enough to power the LED but not enough to do anything else. After running to the store to get more fuses, replaced the burnt out fuse, re-installed the program and everything started working!
Next step is to use that new feedback network to also get leg angle data. One item that’s needed especially after startup is knowing where each leg is physically located. Small hexapods have a startup routine where they can just move their legs to a default position from wherever they are. I can’t do that safely and don’t want to damage a leg(s) by unexpected movements. The leg controllers already calculate current leg angles for each motor so it was a matter of getting that data to the master computer. I created another buffer to load and transmit the 3 angles right after the motor status flags are sent. The master computer looks for this other data dump and stores it in arrays. Now the data can be used to figure out how to safely get the robot to a default starting position after power up.
I got one leg setup and returning the right angle data, next step is adding all the other legs and make sure it doesn’t adversely impact leg motor status data.
Bob
Enjoy!
Mike
I’ll free up another cog by getting rid of floating point calculations and doing everything in integer math soon. I really could use the speed increase! My initial observations with some simple movements is showing a definite speed issue with the leg response. I’m putting together a simple lower the body and raise it back up again movement using Inverse Kinematics (IK) so that the feet stay in one place as the body moves (this will be better tested code than the earlier video where the robot tried to fall over!). It’s a simple movement yet requires IK to keep the leg tips in one place so all motors will be engaged. I wrote the base code but it isn’t complete yet but the leg movements are slow and jerky as its waiting for the calculations for each leg to complete. I will video this once its running and then re-do everything in integer math and then run the same routine. I would expect a significant speed difference with integer math.
Bob
I still have to test the equations and verify that I didn’t make any math mistakes and then program the code. At this time I only need to calculate this once during initial startup so the code knows exactly where each leg tip is located. Then the program can safely move the legs to whatever position is needed.
My first pass on the formulas was a bust, came up with very wrong values for X,Y and Z after manually plugging in numbers on a calculator. So I re-examined everything and found that I made a bad assumption on figuring out one angle inside the parallelogram. Then it took some time to figure out how to get the initial angles correct. This added another step to the process so now there are 10 math steps to take to arrive at a solution. I still have something not quite right, the X and Z values are within tolerances (+/- 0.5”) but the Y value (height) is off by almost 1.3 inches. So I’m not sure how the X and Z are right with the Y being that far off.
I need to get a yardstick and measure the actual height since I got the angle numbers from the robot feedback routine after I told it to move to a specific location. If the equations were correct I would expect the X,Y, and Z output would closely match the input X,Y, and Z values.
I will move the robot into some other positions and see if it is a consistent error or not. However that will have to wait, heading tomorrow to sunny Florida for a winter break!
Bob
I brought all my Forward Kinematics equations with me, trying to verify that I didn’t make any other poor assumptions on calculating the angles and leg positions. So far everything looks good. I’m looking forward to start programming the calculations in once I get back. This might be a good items to start with converting over to integer math to speed up the calculations.
I found a couple of math errors (using Radians instead of Degrees messed me up for a while until I figured out the calculator I was using wasn’t on the right setting...). Today I started over from scratch and did a step by step approach on paper showing the information that I had and the information that I needed to calculate. I think I finally got close, just have to figure out a couple of inconsistencies that aren’t making sense yet. I find that if I write everything out long hand, in pencil, on paper first I tend to make fewer mistakes.
I will have to post the calculations and assumptions (need to draw up the angles and lengths that go into the calculations also), that helps me understand what I’m doing and makes it easier to find bad assumptions.
Did some more experimenting with using the Motor Done flags to control program speed vs. using pauses in the program. That went well and should help with program execution on other routines. I created a routine to control the coxa motor speed from the master. When the coxa moves it creates a pretty big jerk to the robot so now I can reduce the overall speed which reduced the amount of jerkiness. The leg controllers were already setup with motor speed control, just needed to call it up from the master.
Since I had created a routine that changes the height of the robot while keeping the X and Z leg positions the same, now I need a routine to move all the legs to a specific X and Z position while keeping the height constant. This item is what requires knowing where the legs are currently located so I can see what legs are currently on the ground so legs can be lifted and moved to the new position so they can take up the robots weight. Then the remaining legs can be lifted and moved to the new position. Between these two routines I can adjust the robot height and leg position. The other purpose is to be able to move the robot to a default position after startup regardless of the leg positions it was left in previously.
Bob
The last few days have been spent creating and troubleshooting various movement routines that run on the master computer. I added some additional safeguards to the code for moving the body up and down while the feet remain in place. Another routine allows me to move the feet around while maintaining the height constant. I re-visited a routine to move the legs to a narrower stance so that it will be able to travel through doorways while walking and updated that with additional safeguards.
Tonight was spent getting started with initial setting up of a gait program for all the legs. All my testing so far has been with a single leg making the movements needed to walk. Now I have to add in the other 5 legs. First thing needed is map out the coordinates for each leg in relation to the center of the robot body. The original CAD files have the dimensions of the main body as a starting point. Then each leg is located in relation to the center of the robot body so the individual leg coordinates can be coordinated together.
Another thing to do this week is installing some of the cool gadgets I got from Skycraft Surplus! I found a 75 amp shunt so I can start measuring total current draws off the battery and figure out what kind of battery life to expect (and determine if I need to look into Lithium power cells sooner than later). I’d like to get 1-2 hours of runtime if possible. Another item I got was a nice white LED array to install inside the main motor deck. Now its so dark in there that when I remove a leg I need a flashlight to see anything inside there, this light will be controlled by a manual switch and should make it much easier to trace wires inside that area. I also have a Lascar Electronics 4.3” color touch panel that I started programming. This would replace the existing Lascar 2.5” display panel as it provides a lot of additional options for display (4 voltage inputs, several digital inputs, output alarms, etc.) This way I can monitor main battery voltage and current, DC-DC converter output, and generate alarms in case of low voltages or high current levels.
First, the robot is ‘wobbly’ in that it rocks from side to side too easily. This comes from the fact that the bottom piece of the legs uses o-rings between it and the mounting block, it is not a solid connection. The plan had been to use this as a method of measuring side forces if the leg hit something. I used several very high density o-ring as spacers but with the weight of the robot they allow too much motion. I expect that I will have to figure out how to hard-mount the leg bottoms into the connector block. Maybe look into strain gauges for measuring side forces instead.
The second item is that the leg bottom switch mechanism is not going to work as designed. The switch is supposed to be activated when the leg has placed at least 25 lbs of force on the surface, however that only works if the leg is mostly perpendicular to the surface it is touching. As the leg is extended the switch isn’t getting activated. Plus, if I make the changes discussed in the first item then the leg isn’t going to move at all.... Time to revisit this problem, I think the switch is going to have to be mounted down at the tip of the leg to allow it to activate. Just have to come up with a mechanism that attaches to the leg tip now.
Thirdly, with all the legs down and touching the ground there is some variance in the amount of pressure they are exerting, mainly some legs tend to take up more weight than others for the same input position from the master computer. This could be a calibration issue when excessive such as when one leg is still in the air when all the others are on the ground, but mostly its just slight differences how each leg reacts to motion requests. This is mostly seen in the Femur control, although the Tibia shows some angle issues also. I need a ‘tweaking’ factor to the femur/tibia that can be applied from the master computer to compensate for this situation. Just another calibration to perform!
Back to the workshop for another day of work! Got a lot to do before my summer break!
Bob
This is the new 50 amp power disconnect for the battery. It seems pretty heavy duty and it will be fun to get that thing apart next time! The smaller disconnect on the right is for power to the 12v to 5v DC to DC converter used by all the computers for power and isolation from the voltage swings when the motors are operating.
This is the new 12v LED light for the inside of the robot. The next photo shows it installed and it lights up the interior very nicely. I need to add a switch but couldn’t decide where to mount it. So in the meantime I used an extra 2 pin connector that I can manually disconnect when it isn’t needed.
No pictures but I used the metal lathe to turn a new connector for the leg so the leg doesn’t have any extra flex in it. Didn’t try it out tonight, if it works then I need to make 5 more. Still thinking on how to create some method of signaling when the leg is on the ground.
I’ve been thinking how to mount and trip a microswitch from various angles based on how much the tibia is extended. I’ve looked for switches that can activate when a front or side load is placed not the switch, so far I haven’t found any candidates.
The other issue mentioned before is coming up with some method of adjustment for legs that even after calibration are not setting on the ground at the same angle as the other legs or with the same amount of pressure on the ground. I think I want to have a adjustment routine based in the master that I can determine how much out a particular leg is as compared to the other legs. Then that value can be sent to the individual leg so that when a movement command is received it automatically applies the adjustment. By having the adjustment value saved in the master computer that avoids having to reprogram individual leg programs for something as simple as a variable change.
I already have the individual leg controllers reporting back to the master the angles each motor is at. Once I run the Inverse Kinematics routine I have the requested motor angles. By using the IK routine, then have all the legs go to that position, after the motors stop I can get feedback on the actual angles the motors stopped at. I wrote a routine to compare the two values, actual vs. requested, and if the difference is more than 1, save the +/- difference in an array. The results of the array are used to add or subtract from the next calculated IK output before the next movement request is sent. I have some more experimenting to do to see how well it works and how often I should run the routine. Right now I’m only running it on startup but I want to see how the error values change over time. So far it looks promising, when I sent a movement command, the errors were determined and when I sent the same movement command I saw the legs adjust themselves to more closely match the request.
Still working on ideas for sensing when the leg tip has touched the ground. I’ve been looking for mechanical mechanisms that can trip a microswitch reliably from a variety of angles between 10º and 90º, but haven’t found anything useful yet. One idea is to not use a micro-switch but instead use the flexible resistors I was going to use for side impacts instead. Create a rounded shape for the leg foot that one of these resistors can be attached to. This could be the means of being able to sense a wide variety of angles that the foot is capable of touching the ground with. I’m not sure how durable they are in the long run. I also need some means of protecting the resistor from abrasion from direct contact with the ground and how would that impact the resistance readings.
This required me to disassemble the motor on the linear drive and I found the carbon brushes were not contacting the commutator. So some quick repair work to remove the brushes, run a small file inside the plastic brush holder to and freed up the obstructions so the brushes moved freely again. Re-assembled the motor and verified it worked before putting it back on the robot so I could finish the calibration.
I need to buy a couple of replacement drive motors, one of these days I’m going to get one that I can’t fix. There was some evidence of heat damage, as the motor itself was cool I believe this occurred before I added the additional program steps to reduce the probability of having a locked rotor situation.
I’ll get back to testing the auto calibration routines in the morning....
The auto-calibration mode seems to be working fairly well, it gently tweaks the output from the master to the leg controllers. I limited the routine to allowing no more than a +/-5º change, anything more than that implies that the individual leg calibration is off. As part of the testing I started using the motor done flags coming into the master from the legs to signal when a motor movement is complete. I ran into the situation where a leg would get close but still not make it to the deadband because the motor isn’t getting enough power to move. So I made a slight change to the deadband from 1 encoder count to 2. This changes the angle resolution by +/-1.1º.
With most of the issues completed off my checklist, I started work on creating a tripod gait routine. First step is to figure out how to intergrate the body coordinates to the individual leg coordinates. This is tricky as legs are mounted every 60º around the body. I put together a scale paper diagram on graph paper of the leg arrangement so I can figure this out. I need to be able to move the center of the robot body a set distance and direction. That distance and direction needs to be replicated by each leg under their own coordinates. Its just trigonometry but I’m drawing a blank on how to solve the problem right now. I’ll take some time to think about it and try again later.
I’ve spent several days working on the math for translating the body movement coordinates into the individual leg coordinates. This way moving the body center 4 units in the Z direction and 5 units in the X direction, each leg is moving the same direction and distance. My initial calculations ended up being overly complex (although they did work!) and way too many steps to translate the body position into leg positions. Finally I had the proverbial light bulb go off (while standing in the shower of course!) and realized that since I already had the X and Z values for the movement, all I had to do was calculate the movement angle and the distance of movement for the body. I already know the angle each leg is located at compared to the center of the body. The math ended up being much simpler!
Using the Pythagorean theorem the stride length is calculated based on the input X and Z values. The movement angle is the arctangent of dividing Z by X values. Legs are positioned every 60º around the center of the robot. If leg #1 is at 90º to be the top-most leg (looking down on the body from overhead and in-line with the Z axis), then leg 2 is 150º, Leg 3 is 210º, Leg 4 is 270º, Leg 5 is 330º, and leg 6 is 30º. The movement angle is subtracted from the leg angle (ie, for leg #6 at 30º, if the body movement angle is 20º then 30º-20º = 10º. Using sine and cosine, the new X and Z values can be calculated (X = stridelength * sine(leg angle) and Z = stridelength * cosine(leg angle)). I’ve run the calculations manually using a calculator and putting them on graph paper to verify and so far everything looks good. Today I’ll start programming in the calculations and see where that leads me. A neat trick is that I only have to do the calculation for 3 legs, the other 3 legs are the same X and Z values but are in other quadrants of the circle. So if leg #1 is moving x=1 and z=2, then the leg opposite (leg #4) moves to x= -1 and z= -2. This will help speed up calculations since I only have to do half of them!
The next step in the gait routine is to get the legs from their starting point to the new position. The stride length distance will be broken up into short segments of about 1/4”. So if the stride is 4 inches, then there will be 16 segments to the move, with equal movements in the X and Z directions. The leg IK routine will be called for each segment to calculate the angles needed. This keeps the leg moving towards the end position and the short segments help ensure the leg is moving in a relatively straight line (I may have to adjust the 1/4” segment length either smaller or larger depending on how the legs respond). Too large a segment length can result in slippage at the leg tip and too small a segment can use too much time for the master computer to complete all the calculations resulting in jerky movements. A tripod gait will be the first gait where there are always 3 legs down and 3 legs up. The down legs move the body forward and the up legs are moving back into position to complete the next step.
On a side note, an issue I recognized a while back is finally going to rear itself now that I’m working on actual walking. As designed, the tibia angle ranges from 0º to 52º. At 0º the tibia is perpendicular to the ground and this was expected to be the normal position. However, this doesn’t leave any room for the leg to move while walking. For example, if the stride length is 4 inches, the leg on the side the movement is heading can extend the 4 inches needed. However, the leg on the other side can not move the leg to less than 0º. The simple solution is to move the tip of each leg out further from the robot body so all legs can move 4 inches in any direction. This has the effect of needing a wider area for the robot to move, which will cause issues when trying to move through a doorway... The longer term solution is to change the tibia motor mount to a smaller angle which would allow the tibia to move the leg tip to be in-line with the coxa pivot point. The photo shows the current 30º angle on the mount, reducing that angle will allow the leg tip to move to positions less than 0º.
I looked over several other people’s gait coding they used for their hexapods and tried some of their ideas. In the end I’ve come back to an even simpler method inspired by the propellor based hexapod code written by another Parallax forum member, Paul K.. His code was the easiest to wade through and understand. I’ve heavily modified it as at this time I’m only going to use a single gait for walking. I am also not incorporating any body roll or yaw movements at this time (I will need that when I want to climb stairs to keep the center of gravity centered). There are many other changes since I don’t use servos and am sending angle data directly to the leg controllers to control their movement.
So far I am only controlling a single leg, will be adding a second leg in a couple of days once I’m sure I have most of the bugs worked out of the code for moving a single leg. In my previous post I was working with translating the movement of the body coordinates to the individual leg coordinates, it turns out I was making it overly complicated. Now I just send the same angle data to each leg but add in + or - 60º to the front and rear legs and 0º to the legs on the side, and that ensures the leg is moving the right direction. I’ll get confirmation of that assumption once I add a second leg!
Continued testing has the advantage of ensuring that I understand and see issues fairly quickly. I see that I still have some calibration issues to fix on a couple of legs. I turned off the auto-calibration routine while I’m testing the gait, it’s harder to see patterns in my debugging display when the data is being actively manipulated!
I started to video some of the testing movements and will compile a new video of the progress once I get some more to show.
Bob S
I continue to play with the master computer gait program using just one leg, still not satisfied with the movement I am seeing, the motion isn’t smooth and the leg doesn’t seem to be moving consistently to the right locations.
I’m running out of time for coding, soon we are starting our summer trips so this will go on the back burner until fall. I plan on taking a P1 experimenter board and my LIDAR unit with me to work on during rainy days on the road, maybe get that finally going.
Its been a while so first thing was reviewing the last version of the program code to see where I left it and then turned it on and let it rip! Of course I had one leg not wanting to cooperate so that took some troubleshooting but now everything is back and running. After some more testing I still don’t get the smooth operation of the legs when running under IK that I want. Starting to think all that FP math is just too much for the P1 master computer.
I am starting to look into using another computer chip for the master, one that is faster and can handle the FP calculations required. The P2 chip looks like its almost ready to go, need to do some reading on the P2 forum and see what programming tools are available. Hopefully it has its own version of SPIN since I really like programming in that language!
In the meantime I want to finish up some of the hardware items on the robot like getting the leg down touch sensors figured out and a few cosmetic items.
Actually some thing I am looking forward to do too, alas in about 10 years if I even EVER will be able to retire.
Good to have you back here, yes the P2 is reality and thanks to @ersmith one can program it very comfortable from Spin 1.5, Eric's own Version of SPIN with P2 extensions.
The current problem with the P2 is that all the documentation and existing driver are still just scattered around the forum, Parallax is starting to set up a new OBEX via GitHub and the guys actually playing with the P2 dev modules are still in the stage of - lets test if (and how exactly) this feature works, so there are tons of sample out but no accepted standard drivers. It is all in the flux, still but it is wonderful.
The basic things are there, serial, USB, video, a bunch of languages/compilers. It will need some time to get this organized/packaged and documented, but I am pretty sure that Parallax will make sure that all of this will be Parallax Style awesome.
But the first thing you should do is try out Eric's Flexgui and his SPIN 1.5. It does not just work for the P2 it works with the P1 also.
And it compiles P1 SPIN to P1 PASM (LMM) thus is WAY faster then the SPIN interpreter, but need more space also, SPIN byte code is compact, PASM (LMM) needs more HUB.
But your P1 LEG controller might gain a lot of speed/reaction response if compiled by flexgui/fastspin as long as they still fit into HUB.
The good thing would be that you can just use the code you have and gain speed, instead of switching the MC and rewrite everything.
The master P1 should be definitely replaced by a P2. But the legs could just stay as they are.
Anyways, good to see ya back,
Mike
I had to study my code some more and read some of my later entries in this forum to get back on track with where I left the code off and the hardware issues. Still need some means of knowing when a leg is touching the ground so I was looking at strain gauges again. These could possibly be attached to the aluminum lower legs but there is a lot of additional hardware needed to make them work. A simpler option is using flexible force resistors that can wrap around the end tip of the leg. That only needs a voltage divider and ADC to work. I’ve got to look at the leg code and see if I have any left over cogs to run the ADC on the leg controllers. This requires machining new tips for the end of the legs so the resistors can be attached, working on some design ideas to test the concept.
It was a good time traveling, 10 weeks to Alaska and then 8 weeks in the southwest along with several other shorter trips around here. Looking forward to a northwest trip this summer and diving in the South Pacific in late fall. Somehow I need to carve out some time for the robot!
I read about Eric’s Flexgui, didn’t realize it worked on the P1 also. I will download it and give it a try with my master controller and see if I can get some speed improvements with the FP math. I remember that at one point I was looking into using lookup tables for sine, cosine and see if I could do all the math using integer math to help speed things up. There were some good articles out there on some other forums with tips on how to use integer math to simulate floating point.
I seem to sound like a fan-boy, but what Eric has done there is simply mind boggling. He seems to have the passion and skills you have for machining things just using it in his software forge.
I am programming for a living since ~30 years but I am just a Code Monkey, I just do grunt work and never reached the high paid jobs out there, always went for the more secure options.
But I did work with famous teams and I am able to see and admire good work even if my own skills are way below it. Unlike the Dunning Kruger Effect I know my limitations.
Over the last years I always pointed out that @JonnyMac has the most consistence and readable code, hoping that other would follow, I myself try to learn from his style to write things.
But the sheer AMOUNT of work Eric did put out for the P2, makes me wonder how he does it.
I barely find time to throw in 1-2 hours a week for the P2.
Anyways look for multi language integration since C and BASIC support FP and are integrated easy into a SPIN project.
Enjoy!
Mike