If all the lines from the leg computers are going to a single pin on the master it is essentially the same as a single wire connection since all the leg computers are receiving the data intended for any one of the legs. Half duplex handles that easily.
Master sends out a command with the address of the slave as one of the bytes (usually the first byte) in the message.
Slave responds with data/acknowledgement/or whatever is required to master.
Commonly used this on automation systems. Typically I use address 0 as master and 1 - 255 as slaves, although I have never had a system with more than a dozen or so slaves.
there is a nice serial object from @"Beau Schwabe". The concept behind it is to daisy chain all Propeller together in a ring, one COG for input one COG for output to the next propeller.
Then you dedicate a HUB ram area as cmd/response buffer and send this buffer from Prop to Prop continuously around and around. Each Prop receives the buffer and sends it to the next until it comes back to the first one.
Now you can use the same mailbox method used normally to talk from one cog to another on the same chip across multiple chips.
This is dead simple and does require 2 pins and 2 cogs per propeller. The whole communication runs constantly in the background just moving the buffer around and you just need to dedicate certain areas of the buffer to certain Propellers, say the first 10 longs for the first leg, the next 10 longs for the second leg and so each Propeller can read its commands and write its responses simply in its dedicated buffer. by writing /reading its own HUB ram.
The only problem is that when one Propeller dies the complete communication stops. But in your case that might be OK because if one leg controller dies the rest of the robot should not move any further.
I think it was called High-Speed serial or something alike and should be in the OBEX.
Beau’s serial object is nice but I only have one open cog on the leg controllers and no way to free up another one. His solution is elegant and would be great if I had the cogs....
Kwinn - I didn’t conceptualize what you meant until this posting. You are correct, I could just use a single daisy-chained wire from the master to each leg controller for both transmit and reception. That simplifies wiring with no other changes to the code.
Using the 4 port serial object, I started a 3rd port on the leg software. I put in a simple repeat loop to check for an input from the master (example: $,6) for that leg and then output the feedback data followed by a unique end character (#). I didn’t put the master computer in the mix yet but did some checking using my debugging connection to simulate master requests. Most of the code is working fine and the expected feedback information is being generated to the screen. I ran into a bit of trouble using the debug console to send motor commands and feedback commands over the same line (since I have 2 separate processes looking for input and I used the same schema ($,leg#)) to call both - it’s only a problem debugging because normally these would be looking at 2 different master computer outputs, not a single terminal providing input to both). That caused some interesting results. I will change the ‘$’ to another unique character (maybe use % instead) to avoid this for future troubleshooting!
I haven’t had much time to spare but I’ve gotten a few items done on the robot. I continue to tweak the PID, it seems stable and works as expected. I went to engergize another leg for calibration but some wires without labels required me to totally remove the #5 leg and controller assemblies. As long as I was in there, I went ahead and moved the leg sensor panel 1 inch out using spacers. I found that my short fingers were having issues reaching in blindly to plug the sensor wires into the right sockets, especially since one hand is busy holding 26# of leg assembly in place. It should be a lot easier to make the attachments in the future.
Since I had to remove most of the battery compartment covers I saw all the open space I was planning on using for a 2nd battery if needed. Instead of another heavy gel cell I should be thinking of using Lithium battery packs instead. Checking on-line for sizes, I think I could shrink that space down by a bit so it isn’t quite as large and ungainly. Unfortunately I used a lot of space for the power distribution system and its components so that will require some effort to make any changes in that area. Keep tuned for follow ups on this idea.
Did some more work on the communications feedback setup from the leg to the master computer. Fixed a bug where 2 cogs were calling the same sub-routine and interfering with each other. Still getting my mind around the protocols to use for the master and leg communications. Each leg basically has 2 seperate and independent communication loops. There is one from the master to the leg for sending leg movement data using the main program cog. This setup works good (at least with one leg in test) its basically just the master sending a continuous stream of needed leg movements. I have another cog that handles 2 way communications over 2 wires to the legs. This is the feedback loop and the current plan is that the master will transmit a signal for each leg in turn to respond. When the leg sees its identifier, it will transmit back data on leg status. When the master receives a specific character it will then query the next leg in turn for its status. I don’t have any experience in this type of programming and keep hitting roadblocks, mostly of my own lack of knowledge. It is also time consuming and much harder to figure out where a problem is coming from with 2 prop computers to deal with, let alone once I start adding in additional leg controllers to the mix. I think this part has been a bit intimidating so I have been avoiding it, hence my progress has slowed way down.
Anyway, still plugging away. Someday I’ll get some type of coordinated movement out of it.
I haven’t had much time to spare but I’ve gotten a few items done on the robot.........
Did some more work on the communications feedback setup from the leg to the master computer. Fixed a bug where 2 cogs were calling the same sub-routine and interfering with each other. Still getting my mind around the protocols to use for the master and leg communications. Each leg basically has 2 seperate and independent communication loops. There is one from the master to the leg for sending leg movement data using the main program cog. This setup works good (at least with one leg in test) its basically just the master sending a continuous stream of needed leg movements. I have another cog that handles 2 way communications over 2 wires to the legs. This is the feedback loop and the current plan is that the master will transmit a signal for each leg in turn to respond. When the leg sees its identifier, it will transmit back data on leg status. When the master receives a specific character it will then query the next leg in turn for its status. I don’t have any experience in this type of programming and keep hitting roadblocks, mostly of my own lack of knowledge. It is also time consuming and much harder to figure out where a problem is coming from with 2 prop computers to deal with, let alone once I start adding in additional leg controllers to the mix. I think this part has been a bit intimidating so I have been avoiding it, hence my progress has slowed way down.
Anyway, still plugging away. Someday I’ll get some type of coordinated movement out of it.
One way of figuring out where a problem is coming from is to have the master cog output the command it is sending and the response it receives to the debug (PST) terminal. Also, have you considered using pre-programmed gaits rather than having the master send all this data to each of the leg controllers. This way each leg controller has it's motors go through a sequence of movements at specified speeds and the master only has to specify the gait and provide a synchronizing command to all the legs. Think of it as the equivalent of the gaits that we use for walking, jogging, and running. Each one has a number of specific movements for each leg, and each group of movements can be done at various speeds.
With the preprogrammed gaits theory, you would want the prop in the motor controller to read an external EEPROM for the data to run the gaits. These EEPROMs could be removable so that another prop off of the bot could be used to write walking code.
One way of figuring out where a problem is coming from is to have the master cog output the command it is sending and the response it receives to the debug (PST) terminal. Also, have you considered using pre-programmed gaits rather than having the master send all this data to each of the leg controllers. This way each leg controller has it's motors go through a sequence of movements at specified speeds and the master only has to specify the gait and provide a synchronizing command to all the legs. Think of it as the equivalent of the gaits that we use for walking, jogging, and running. Each one has a number of specific movements for each leg, and each group of movements can be done at various speeds.
The method you spoke of for testing is one of the ways that I have tested the leg to master communications in the past and will use a readout to PST to verify the communications. However in the past all the communications has been one leg connected to the master. Now I’m ready to expand the communications to additional legs so the simple system I put into place originally is not adequate. In the meantime I think I’ll test each of the other legs, get them up and running individually before I tackle having the master talk to multiple legs.
What you described is basically the way the leg and master work together now. I’ve offloaded all leg movement duties to the leg controller so that the master tells the leg where it wants it to go. The leg computer waits for master input for any of the 3 motors and then activates each motor to move it to the requested angle. The master computer only outputs motor angle data to each leg based on where it wants the tip of the leg (where the leg touches the ground) to move.
I’ve bounced around the idea of using pre-programmed gaits and using a single leg I was doing something similar while figuring out how to get the leg to move in a straight line. Movement in a straight line was the hardest programming item but I think that the Inverse Kinematics formulas are working good for this now. The actual gait generation is a seperate issue and the current setup assumes a ‘front’ and ‘back’ to the robot and will move the legs according to that orientation. I tested leg movements that would be associated with turning and the leg moves as expected. I did find a leg design flaw during this testing, the tip of the leg needs to be able to move closer to the axis of leg rotation (kind of putting the leg tip underneath the coxa rotation point). Since the mechanical design does not allow that configuration, legs that are in the front or rear of the robot are not capable of as long a stride as the legs to the side. Since the stride length is dependent on the shortest movement, the overall speed will be reduced. That isn’t a major concern at this point but I will have to address it sometime after I get it to walk the first time.
Back to the subject of pre-programmed gaits, I guess I’m not sure that those would be useful other than for testing or moving in a straight line. I’ll post the IK and gait movement code when I power up the computer next. Maybe someone else sees a better way of approaching the problem. I really want the robot to be able to respond dynamically to a user input rather than following a pre-programmed path.
Worked on setting leg #5 up for testing. The new position for the sensor plugs is much easier to access! After the leg was installed all the sensors and motor controller were wired into the RoboPi board. Powered the board up and downloaded the code. The first thing the program prints out is the current leg angle, encoder value, and the calculated slope. Of course 2 of the 3 motors showed an encoder value of 0 which I found out in an earlier post means that the CS and CLK signals are reversed (this was due to the socket connectors on the sensors occasionally swapped the wires in the plastic connector). I temporarily reversed the wires on the connectors and got everything back up and then got good encoder output values.
Next step was motor and encoder calibration. I have a routine that runs a motor to its maximum position each direction and records the encoder value. I run this routine several times to make sure the min and max encoder values don’t change. The first axis I ran was the coxa and although I initially got some good numbers, after about the 5th time I noticed a slight movement interruption where the leg would just stop with the motor still running. By the 8th iteration the leg stopped moving, although the motor was running. (the gear with the X markup is purposely disconnected as this was replaced by the magnetic encoders)
I was able to determine that the gear on the motor shaft had slipped down and the gear was no longer engaging (2). Since I couldn’t move the gear with my fingers, leg removal was required. Even with the leg removed I had to partially disassemble the leg to get tools in to re-position the gear. I believe part of the problem is the that the gear hub is very thin and the setscrew can’t get enough purchase in the threads (1). I will first try grinding a better ‘flat’ on the shaft for the setscrew and if that isn’t enough, drill through the shaft for a spring pin.
While I was moving the coxa back and forth I also noticed that the coxa encoder was not moving consistently when at full rotation (30º and 150º). It appears that the custom springs are not being tensioned properly at these two location and so the leg can move a small amount without any encoder movement. I think I can put more twist on the springs so both of the springs are always in tension and that should eliminate the slop. The marked up X is the old 20 turn potentiometer that is no longer used.
Bob,
Are you doing your PID calculations in fixed or floating point? I tried to figure it out doing a quick review of the thread but couldn’t find that out. If you are using it float, couldn’t you cut down on the number of cogs and increase the speed by using fixed point and integer math?
Jim
Bob,
Are you doing your PID calculations in fixed or floating point? I tried to figure it out doing a quick review of the thread but couldn’t find that out. If you are using it float, couldn’t you cut down on the number of cogs and increase the speed by using fixed point and integer math?
Jim
I use floating point due to needing sine, cosine, arccosine and arctangent (too much to put into a table). However I use integer math by multiplying FP results by 100, doing all the remaining math using integers and then divide by 100 at the end. I only use FP where necessary and revert back to faster integer mathematics ASAP. The process works fairly well in testing, I had to add pauses in the code to allow the mechanical systems time to catch up. Once I get all 6 legs going at the same time hopefully the speed will be adequate. There are some other mathematical tricks I can use to help speed things up later if needed (legs across from each other require the same output values but movement in the opposite direction when moving in a straight line so I only have to calculate for 3 legs Most of the time. Turns will be harder but should be over a short time period where all 6 legs need independent values)
Got leg #5 back together again and re-installed it. Powered it up for the first time and ran the calibration routine. This is where the program moves the selected motor to its minimum and maximum position at slow speed and then gets the encoder value at both positions. I run the routine several times to ensure I am getting a stable value. Starting with the tibia movement I kept getting inconsistent values although there was a value that came up more often. I decided to plug these values into the DAT section and see how well the tibia operated. After giving a tibia movement command, no movement from the tibia motor, didn’t even energize the motor. Since I had just ran the calibration I knew the connections were good and the motor controller was getting signals. The only reason that a motor would not energize at all is if the internal limit switches were activated, which means the motor is being told to run the wrong direction. So now I have to remove the leg and trace the power wires. This may be the same issue I had before where the pre-wired connectors I used changed the position of the wire colors in the connector. I can always swap the motor output wires on the motor controller but I cut those wires to length, so I would have to make up a new wiring bundle. Plus this is just the first motor, I tried the other motors with similar issues. Troubleshooting time!
Bob,
Starting to sound like you need to build a wire harness test jig to catch those errors befor they get to the installation phase.
Jim
Yep, that might have been a good idea at the time. I’m disappointed that the wire connectors were not all the same, I made a bad assumption about that. I could make the changes in the program but I really don’t want to deal with 6 leg computers all running slightly different code!
Figured out the problems with Leg #5. The tibia motor is physically wired backwards in the motor so it rotated the opposite direction as expected. I moved the motor lead plugs around in the socket to get that corrected. Next issue was the femur motor. The motor and software worked perfectly after calibration but all movements are exactly opposite of the expected movement. This required another motor lead reversal. Lastly the coxa ended up with 2 issues that masked each other. First the encoder was installed incorrectly such that when the coxa moved the encoder was going from a value of 2600 to 1000 but was passing through 0. Once that was fixed then of course the motor was running opposite of the required direction. I have to fix that but after putting on and removing the leg several times today I just wasn’t ready for one more disassembly / re-assembly. Saving that for tomorrow before my wife has me out handing out Christmas cookies.
Got to figure out why every motor was running the opposite direction as the test leg (#6). They were all wired at the same time and I was being careful to make sure they all matched. I had it written down on my notes as to the wire colors and connectors. Puzzling.
Leg #5 is now calibrated and running correctly! Starting calibration of Leg #1 and determined that I don’t have any longer length servo harness wires so time to order some 1 ft long wires to connect between the motor controllers and leg controllers.
I removed battery layer covers and got to thinking about how reduce the height of the battery section. I decided that if I need more battery than the 12v 26Ahr gel cell can provide then I would swap over to a Lithium battery pack instead. Since the area was sized for 2 gel cells there is a lot of wasted space. However, I used the existing vertical space for the computer and motor distribution setup so this requires some rewiring and moving components around. I believe I can reduce the height from 11” to 7” and still have room for expansion if needed.
Here you can see the battery and the open space above it. The backside of the computer power distribution is in the back.
Here is the motor power distribution area. The fuse block is fairly tall so it needs to be moved down. I wouldn’t move the fuse block due to the amount of rewiring it would require so the power switches and relay wiring would have to be moved to another open bay.
This side has the motor filter caps. These were added to smooth out power supply voltage spikes as motors switched on and off. I worried that this could affect the computer power as it feeds off the same power supply. Since I got a good quality 12v to 5v switching power supply I haven’t had any computer glitches from motor operation. So these may be unnecessary at this point. They caps fit with the lower height but they stretch across 2 bays. They could be relocated to inside the main level, its fairly open in there with just a lot of wiring and the coxa motors.
Here is the computer power distribution panel and charging ports. With a single battery only one charging port is needed instead of 4. The fuse block is very tall and won’t fit in the 7” height, however the upper section is just a common negative bus that could be cut off and separated from the actual fuse section.
I’ll play around with this awhile and make up some drawings to see where everything could fit and placement of the parts. Don’t know if I’ll get around to changing anything soon but if I hit a programming roadblock then this might be a good mini-project to divert over to.
Completed calibration of Leg #1, half way done, 3 to go. Had some issues where the femur motor wasn’t responding as expected, it ended that the encoder limits I entered were so far out that the program couldn’t figure out how to move the leg. Once I realized this and corrected the encoder limits the motor ran fine.
Started work on Leg #4 and once again ran into problems starting with the femur motor which doesn’t want to move because the encoder seems to be locked on a value of 4095. I verified the encoder wires are going to the right places, Hmmmmm. Next step is to remove the leg, disconnect the femur motor and hook the femur encoder to a dedicated encoder program and see if it works. It is possible that I have a bad encoder, luckily I got extras!
This will be the last leg I can calibrate until I get some longer servo wires to go from the motor controllers to the computers on the top deck. Unfortunately we just got notified that our CC was hacked so no on-line purchases until the replacement shows up.
It is funny how much wiring issues occurred and I am sure you are very methodical. But how could you expect different crimped wires.
I am following your project with awe about your dedication and attention for details.
And everything you need to change or build you need to repeat for every leg. What a nightmare of a project, but also even more than cool.
If that thing steps out of your pickup to fetch some stuff off the local diving store, nobody will even think about messing with you.
For the programming part you will find a couple of examples here in this forum where one prop drives a hexapot. As far as I could follow you have one Propeller per leg acting as a leg-controller and giving feedback to the central controller.
That means that the central propeller 'just' need to send commands and listen to notifications, right?
My question here is where you plan to split the responsibility. So will the central processor say:
LEG 1
Femur 20 degree
tibia 12 degree
LEG 2
Femur 22 degree
tibia 13 degree
…
or will the central prop say
LEG 1
moveto x:123, Y:456, Z:789
LEG 2
moveto x:456, Y:789, Z:012
and leave the path building to the leg controllers, working in parallel?
For the programming part you will find a couple of examples here in this forum where one prop drives a hexapot. As far as I could follow you have one Propeller per leg acting as a leg-controller and giving feedback to the central controller.
Correct, each leg has one RoboPi controller. There are several examples of hexapods that use a single prop to run all the legs. All the hexapods that I am aware of use servos to move the legs. Servos make leg control much easier as all the electronics to run them is embedded in the servo. My hexapod has DC motors in linear actuators with magnetic encoders for positional feedback, all run under program control. I end up using 3 cogs just for motor control. It doesn’t leave much space for the mathmatics needed to actually figure out how to tell the motors to move after that. The end result is that the leg controllers act a lot like servos as far as the master computer is concerned. Unlike an actual servo the leg controllers accept motor angle data as input instead of PWM pulses.
That means that the central propeller 'just' need to send commands and listen to notifications, right?
My question here is where you plan to split the responsibility. So will the central processor say:
LEG 1
Femur 20 degree
tibia 12 degree
LEG 2
Femur 22 degree
tibia 13 degree
…
or will the central prop say
LEG 1
moveto x:123, Y:456, Z:789
LEG 2
moveto x:456, Y:789, Z:012
and leave the path building to the leg controllers, working in parallel?
The master prop does all the inverse kinematics calculations to figure out how each leg and the motors on the leg need to move along with coordinating the overall gait that the robot will take. Your first example is the most accurate representation of the master computer output:
$,1,1, 900 $,1,2,10 $,1,3,900 $,2,1,800 etc. where the $ is the start, followed by the leg #, next is the motor (1 for femur, 2 for tibia, 3 for coxa) and lastly the requested angle (900 is actually 90.0 degrees to keep everything in the leg controller under integer math). The master puts out 18 seperate commands (6 legs x 3 motors) for each calculated movement. Each step (one leg moving in a straight line) is broken into 30 segments each direction (60 steps + a lift or lower movement at the end or beginning of a step). So the master is pretty busy calculating the step end location along with the interim positions along the path for each leg’s motor. In this case the master operates like a standard hexapod using servos (in this case the leg controllers act like smart servos).
Your second example could be implemented using the same setup as that would just be a programming change for the master and leg computers. That type of interface could be faster since I wouldn’t have to identify the leg# with each command (how about something like master output of $1,900,10,800 $2,910,11,805 where the $ is followed by the leg #, and then the 3 leg position commands where the first item is Femur followed by Tibia and then Coxa). I didn’t go that direction since during software development I was only testing one motor at a time. It wasn’t until I started playing with gait control that I was sending data for all motors on a leg. This setup has some pluses going for it, I need to give it some more thought, thanks for the idea!
The added benefit of the leg controllers is that they have the ability to feedback to the master any error conditions and the master can respond as needed, functionality that a standard servo does not have.
My thinking here is that as more movement control you put in the leg (smart legs?) as less the central processor has to do.
The central processor should think about gait not tiburs and femas and coxas and angles and...
Mike
In the original scheme I had more processing going on in the leg controllers. But I ran into a problem of not having enough cogs to do everything. That’s why I scaled the leg controllers back and made them act more like smart servos. I wanted to do the inverse kinematics in the legs with gait control in the master but I’m at the point where there are no open cogs to run the floating point math needed in the legs.
The master computer should be speedy enough to handle the IK and gait control, proof is in the number of single prop hexapods that are working in the wild. I may end up adding another prop computer just to run the auxiliary equipment (cameras, LIDAR, etc.) later to off load the master if needed.
Bob,
I hope you and the robot can make it out to Parallax next Fall for an Expo. We will not expect it to walk all the way!
I hope to attend one of these Parallax events someday! Always wanted to see the Parallax location in person. Unfortunately I am already booked for a 2-3 month driving trip to Alaska this year. I would love to have this thing walking before I go (plus I have to figure out how to get it there, not sure that I could buy an airline seat ticket for it, seats are too small. That leaves driving with a small trailer since it won’t fit through the door on my RV). In the meantime I will just continue to write up my mis-adventures trying to get this thing done so long as anyone wants to read through the 24 pages of postings!
Back on Leg #4 calibration. It’s funny how after coming back later to a problem it’s easily found and corrected? After removing the leg and testing each of the encoders separately (they all worked), I found that I mis-typed the CLK output PIN number in the program. Once this was fixed the calibration was smooth.
I tried to cobble together a 3 wire servo harness for the last 2 legs but finally decided to order 3 wire servo harnesses with the correct length instead. I removed the last 2 legs and motor controllers so they will be ready to go once I get the parts (I have a week before the new CC shows up so no on-line spending now).
Here is a very open view of the motor level on the robot after I ended up removing 3 legs and 2 motor controllers. Lots of wiring in there!
Since I had some extra time on my hands and no other pressing projects I decided to re-arrange the computer power distribution board. I moved the fuse panel up and the relay and terminal strip were relocated above the battery.
I cut the board down to the new size so you can see how much shorter the battery level will be. There’s still a lot of work to do this and I am just doing it in stages.
Started the new year with a refreshing scuba dive into 42º water with some friends! Now I’m back home and still waiting for the replacement CC to show up.... So I got real busy today and took the motor power distribution center apart.
This is the original motor distribution setup at the start of disassembly. I didn’t want to re-wire the system so the equipment needed to be relocated so that the wires would still reach.
This was the end result. I rotated the switches 90º and moved the fuse panel up. This didn’t leave any room for the main relay and terminal strip. I also had some repair work as a couple of lugs apparently were not properly crimped and the wires slipped out.
I added a new panel on the left beside the motor fuses to mount the terminal strip and motor relay. The wires hanging below are kind of messy and I’ll straighten that out when I get a chance.
Next step was to disconnect all the aluminum panels from the round battery support bars and then remove the bars. This photo shows the robot body laying on its side and all the panels hanging down also (I ended up removing all the legs as it was easier to access the battery area. I’m glad I made everything modular, everything came apart relatively easily).
I have to cut the battery supports down to 7” length, drill and tap a few holes and then I can put everything back together again.
After dinner I didn’t have any other chores for the night so decided to retreat to the basement workshop again. After measuring twice, I cut the old battery level posts down close to size using the bandsaw. Then each one was put in that lathe and finished to the correct length. After that the end of each was drilled and tapped. At that point it was fairly simple to reconnect each post to the main body and screw the power distribution boards back into them, add the bottom plate and put in the battery.
It looks more or less the same as before but it is now 5” shorter than before. I still have to cut the plastic panels that hide all this down to the new size. One problem is that the panel that was over the power switches already has holes in it for accessin the switches and the digital power meter. Unfortunately I don’t have any more sheets of that plastic left so short of getting all new plastic I may have to figure out how to reuse some of the cutoff sections of paneling for that side.
I will continue to use the existing gel cell for power and see how much operating time I get out of it. I suspect that I will eventually have to replace it with a lithium battery pack but there is plenty of space to put a 30-50Ahr battery pack in there. The only issue I have to figure out is that in order to remove the battery one of the battery level posts has to be removed which requires removing a leg in order to access the top bolt. I need to come up with an easier method for changing out battery packs. Of course once the robot is standing on its legs vs sitting on a test stand, the easiest access would be to remove the 6 screws holding the battery base plate and then the battery can be lowered down. This might be awkward trying to maneuver between the legs and holding the plate up to remove the last two screws.... Always another design item to think about!
Today I’ll re-install the 4 legs that were calibrated and do the bench tests on the remaining 2 legs so once I get the servo wires I can install and calibrate them. I also need to do some quick tests using the new RoboPi computers to make sure I didn’t make any soldering mistakes!
It took longer than expected but the new battery level mods are complete! The plastic panels had to be trimmed a bit to fit but they are also installed. With that done I put the 4 calibrated legs back on the body.
I finally got the new CC so I was able to order longer servo wires, once those arrive I’ve install and calibrate the last 2 legs.
I also need to solder up a couple of wiring harnesses for the Master to Leg computer communications. I’ve got to get that communications protocols figured out soon so I can control more than one leg at a time using one wire to connect all the legs to the master.
For one-wire leg comms, you might have each of the leg computers listen for serial data on the line, and have them ignore each data packet if it does not stay with it’s ID number. With that, you don’t have all six legs reacting to leg 1’s commands and so on.
For one-wire leg comms, you might have each of the leg computers listen for serial data on the line, and have them ignore each data packet if it does not stay with it’s ID number. With that, you don’t have all six legs reacting to leg 1’s commands and so on.
That’s pretty much the design I’m using now. Each data packet identifies the leg #, the motor # and then the position in degrees. An earlier suggestion was to send a data packet with the leg #, then the 3 motor position data. That cuts down the number of transmissions in the long run. I didn’t initially go that direction since up until recently I was only testing one leg and one motor at a time. I think that I’ll try this protocol out once I get the remaining legs calibrated.
One item that I didn’t think about until I reattached 4 of the legs is that removing 5” from the battery section means that that the leg is just barely touching the ground with the femur at 90º and tibia at 0º while it is sitting on my test stand. I need to find something to prop the body up higher so erratic leg movements don’t cause an unintended incident!
Comments
Master sends out a command with the address of the slave as one of the bytes (usually the first byte) in the message.
Slave responds with data/acknowledgement/or whatever is required to master.
Commonly used this on automation systems. Typically I use address 0 as master and 1 - 255 as slaves, although I have never had a system with more than a dozen or so slaves.
Then you dedicate a HUB ram area as cmd/response buffer and send this buffer from Prop to Prop continuously around and around. Each Prop receives the buffer and sends it to the next until it comes back to the first one.
Now you can use the same mailbox method used normally to talk from one cog to another on the same chip across multiple chips.
This is dead simple and does require 2 pins and 2 cogs per propeller. The whole communication runs constantly in the background just moving the buffer around and you just need to dedicate certain areas of the buffer to certain Propellers, say the first 10 longs for the first leg, the next 10 longs for the second leg and so each Propeller can read its commands and write its responses simply in its dedicated buffer. by writing /reading its own HUB ram.
The only problem is that when one Propeller dies the complete communication stops. But in your case that might be OK because if one leg controller dies the rest of the robot should not move any further.
I think it was called High-Speed serial or something alike and should be in the OBEX.
Enjoy!
Mike
Kwinn - I didn’t conceptualize what you meant until this posting. You are correct, I could just use a single daisy-chained wire from the master to each leg controller for both transmit and reception. That simplifies wiring with no other changes to the code.
Using the 4 port serial object, I started a 3rd port on the leg software. I put in a simple repeat loop to check for an input from the master (example: $,6) for that leg and then output the feedback data followed by a unique end character (#). I didn’t put the master computer in the mix yet but did some checking using my debugging connection to simulate master requests. Most of the code is working fine and the expected feedback information is being generated to the screen. I ran into a bit of trouble using the debug console to send motor commands and feedback commands over the same line (since I have 2 separate processes looking for input and I used the same schema ($,leg#)) to call both - it’s only a problem debugging because normally these would be looking at 2 different master computer outputs, not a single terminal providing input to both). That caused some interesting results. I will change the ‘$’ to another unique character (maybe use % instead) to avoid this for future troubleshooting!
Since I had to remove most of the battery compartment covers I saw all the open space I was planning on using for a 2nd battery if needed. Instead of another heavy gel cell I should be thinking of using Lithium battery packs instead. Checking on-line for sizes, I think I could shrink that space down by a bit so it isn’t quite as large and ungainly. Unfortunately I used a lot of space for the power distribution system and its components so that will require some effort to make any changes in that area. Keep tuned for follow ups on this idea.
Did some more work on the communications feedback setup from the leg to the master computer. Fixed a bug where 2 cogs were calling the same sub-routine and interfering with each other. Still getting my mind around the protocols to use for the master and leg communications. Each leg basically has 2 seperate and independent communication loops. There is one from the master to the leg for sending leg movement data using the main program cog. This setup works good (at least with one leg in test) its basically just the master sending a continuous stream of needed leg movements. I have another cog that handles 2 way communications over 2 wires to the legs. This is the feedback loop and the current plan is that the master will transmit a signal for each leg in turn to respond. When the leg sees its identifier, it will transmit back data on leg status. When the master receives a specific character it will then query the next leg in turn for its status. I don’t have any experience in this type of programming and keep hitting roadblocks, mostly of my own lack of knowledge. It is also time consuming and much harder to figure out where a problem is coming from with 2 prop computers to deal with, let alone once I start adding in additional leg controllers to the mix. I think this part has been a bit intimidating so I have been avoiding it, hence my progress has slowed way down.
Anyway, still plugging away. Someday I’ll get some type of coordinated movement out of it.
One way of figuring out where a problem is coming from is to have the master cog output the command it is sending and the response it receives to the debug (PST) terminal. Also, have you considered using pre-programmed gaits rather than having the master send all this data to each of the leg controllers. This way each leg controller has it's motors go through a sequence of movements at specified speeds and the master only has to specify the gait and provide a synchronizing command to all the legs. Think of it as the equivalent of the gaits that we use for walking, jogging, and running. Each one has a number of specific movements for each leg, and each group of movements can be done at various speeds.
What you described is basically the way the leg and master work together now. I’ve offloaded all leg movement duties to the leg controller so that the master tells the leg where it wants it to go. The leg computer waits for master input for any of the 3 motors and then activates each motor to move it to the requested angle. The master computer only outputs motor angle data to each leg based on where it wants the tip of the leg (where the leg touches the ground) to move.
I’ve bounced around the idea of using pre-programmed gaits and using a single leg I was doing something similar while figuring out how to get the leg to move in a straight line. Movement in a straight line was the hardest programming item but I think that the Inverse Kinematics formulas are working good for this now. The actual gait generation is a seperate issue and the current setup assumes a ‘front’ and ‘back’ to the robot and will move the legs according to that orientation. I tested leg movements that would be associated with turning and the leg moves as expected. I did find a leg design flaw during this testing, the tip of the leg needs to be able to move closer to the axis of leg rotation (kind of putting the leg tip underneath the coxa rotation point). Since the mechanical design does not allow that configuration, legs that are in the front or rear of the robot are not capable of as long a stride as the legs to the side. Since the stride length is dependent on the shortest movement, the overall speed will be reduced. That isn’t a major concern at this point but I will have to address it sometime after I get it to walk the first time.
Back to the subject of pre-programmed gaits, I guess I’m not sure that those would be useful other than for testing or moving in a straight line. I’ll post the IK and gait movement code when I power up the computer next. Maybe someone else sees a better way of approaching the problem. I really want the robot to be able to respond dynamically to a user input rather than following a pre-programmed path.
Bob
Next step was motor and encoder calibration. I have a routine that runs a motor to its maximum position each direction and records the encoder value. I run this routine several times to make sure the min and max encoder values don’t change. The first axis I ran was the coxa and although I initially got some good numbers, after about the 5th time I noticed a slight movement interruption where the leg would just stop with the motor still running. By the 8th iteration the leg stopped moving, although the motor was running.
I was able to determine that the gear on the motor shaft had slipped down and the gear was no longer engaging (2). Since I couldn’t move the gear with my fingers, leg removal was required. Even with the leg removed I had to partially disassemble the leg to get tools in to re-position the gear. I believe part of the problem is the that the gear hub is very thin and the setscrew can’t get enough purchase in the threads (1). I will first try grinding a better ‘flat’ on the shaft for the setscrew and if that isn’t enough, drill through the shaft for a spring pin.
While I was moving the coxa back and forth I also noticed that the coxa encoder was not moving consistently when at full rotation (30º and 150º). It appears that the custom springs are not being tensioned properly at these two location and so the leg can move a small amount without any encoder movement. I think I can put more twist on the springs so both of the springs are always in tension and that should eliminate the slop. The marked up X is the old 20 turn potentiometer that is no longer used.
Are you doing your PID calculations in fixed or floating point? I tried to figure it out doing a quick review of the thread but couldn’t find that out. If you are using it float, couldn’t you cut down on the number of cogs and increase the speed by using fixed point and integer math?
Jim
Bob
Starting to sound like you need to build a wire harness test jig to catch those errors befor they get to the installation phase.
Jim
Got to figure out why every motor was running the opposite direction as the test leg (#6). They were all wired at the same time and I was being careful to make sure they all matched. I had it written down on my notes as to the wire colors and connectors. Puzzling.
Bob
I removed battery layer covers and got to thinking about how reduce the height of the battery section. I decided that if I need more battery than the 12v 26Ahr gel cell can provide then I would swap over to a Lithium battery pack instead. Since the area was sized for 2 gel cells there is a lot of wasted space. However, I used the existing vertical space for the computer and motor distribution setup so this requires some rewiring and moving components around. I believe I can reduce the height from 11” to 7” and still have room for expansion if needed.
Here you can see the battery and the open space above it. The backside of the computer power distribution is in the back.
Here is the motor power distribution area. The fuse block is fairly tall so it needs to be moved down. I wouldn’t move the fuse block due to the amount of rewiring it would require so the power switches and relay wiring would have to be moved to another open bay.
This side has the motor filter caps. These were added to smooth out power supply voltage spikes as motors switched on and off. I worried that this could affect the computer power as it feeds off the same power supply. Since I got a good quality 12v to 5v switching power supply I haven’t had any computer glitches from motor operation. So these may be unnecessary at this point. They caps fit with the lower height but they stretch across 2 bays. They could be relocated to inside the main level, its fairly open in there with just a lot of wiring and the coxa motors.
Here is the computer power distribution panel and charging ports. With a single battery only one charging port is needed instead of 4. The fuse block is very tall and won’t fit in the 7” height, however the upper section is just a common negative bus that could be cut off and separated from the actual fuse section.
I’ll play around with this awhile and make up some drawings to see where everything could fit and placement of the parts. Don’t know if I’ll get around to changing anything soon but if I hit a programming roadblock then this might be a good mini-project to divert over to.
Bob
Started work on Leg #4 and once again ran into problems starting with the femur motor which doesn’t want to move because the encoder seems to be locked on a value of 4095. I verified the encoder wires are going to the right places, Hmmmmm. Next step is to remove the leg, disconnect the femur motor and hook the femur encoder to a dedicated encoder program and see if it works. It is possible that I have a bad encoder, luckily I got extras!
This will be the last leg I can calibrate until I get some longer servo wires to go from the motor controllers to the computers on the top deck. Unfortunately we just got notified that our CC was hacked so no on-line purchases until the replacement shows up.
Bob
I am following your project with awe about your dedication and attention for details.
And everything you need to change or build you need to repeat for every leg. What a nightmare of a project, but also even more than cool.
If that thing steps out of your pickup to fetch some stuff off the local diving store, nobody will even think about messing with you.
For the programming part you will find a couple of examples here in this forum where one prop drives a hexapot. As far as I could follow you have one Propeller per leg acting as a leg-controller and giving feedback to the central controller.
That means that the central propeller 'just' need to send commands and listen to notifications, right?
My question here is where you plan to split the responsibility. So will the central processor say:
LEG 1
Femur 20 degree
tibia 12 degree
LEG 2
Femur 22 degree
tibia 13 degree
…
or will the central prop say
LEG 1
moveto x:123, Y:456, Z:789
LEG 2
moveto x:456, Y:789, Z:012
and leave the path building to the leg controllers, working in parallel?
programming this monster will be a lot of fun...
Enjoy and thanks for sharing all of this,
Mike
The master prop does all the inverse kinematics calculations to figure out how each leg and the motors on the leg need to move along with coordinating the overall gait that the robot will take. Your first example is the most accurate representation of the master computer output:
$,1,1, 900 $,1,2,10 $,1,3,900 $,2,1,800 etc. where the $ is the start, followed by the leg #, next is the motor (1 for femur, 2 for tibia, 3 for coxa) and lastly the requested angle (900 is actually 90.0 degrees to keep everything in the leg controller under integer math). The master puts out 18 seperate commands (6 legs x 3 motors) for each calculated movement. Each step (one leg moving in a straight line) is broken into 30 segments each direction (60 steps + a lift or lower movement at the end or beginning of a step). So the master is pretty busy calculating the step end location along with the interim positions along the path for each leg’s motor. In this case the master operates like a standard hexapod using servos (in this case the leg controllers act like smart servos).
Your second example could be implemented using the same setup as that would just be a programming change for the master and leg computers. That type of interface could be faster since I wouldn’t have to identify the leg# with each command (how about something like master output of $1,900,10,800 $2,910,11,805 where the $ is followed by the leg #, and then the 3 leg position commands where the first item is Femur followed by Tibia and then Coxa). I didn’t go that direction since during software development I was only testing one motor at a time. It wasn’t until I started playing with gait control that I was sending data for all motors on a leg. This setup has some pluses going for it, I need to give it some more thought, thanks for the idea!
The added benefit of the leg controllers is that they have the ability to feedback to the master any error conditions and the master can respond as needed, functionality that a standard servo does not have.
Bob
The central processor should think about gait not tiburs and femas and coxas and angles and...
Mike
The master computer should be speedy enough to handle the IK and gait control, proof is in the number of single prop hexapods that are working in the wild. I may end up adding another prop computer just to run the auxiliary equipment (cameras, LIDAR, etc.) later to off load the master if needed.
I hope you and the robot can make it out to Parallax next Fall for an Expo. We will not expect it to walk all the way to Rocklin!
I tried to cobble together a 3 wire servo harness for the last 2 legs but finally decided to order 3 wire servo harnesses with the correct length instead. I removed the last 2 legs and motor controllers so they will be ready to go once I get the parts (I have a week before the new CC shows up so no on-line spending now).
Here is a very open view of the motor level on the robot after I ended up removing 3 legs and 2 motor controllers. Lots of wiring in there!
Since I had some extra time on my hands and no other pressing projects I decided to re-arrange the computer power distribution board. I moved the fuse panel up and the relay and terminal strip were relocated above the battery.
I cut the board down to the new size so you can see how much shorter the battery level will be. There’s still a lot of work to do this and I am just doing it in stages.
This is the original motor distribution setup at the start of disassembly. I didn’t want to re-wire the system so the equipment needed to be relocated so that the wires would still reach.
This was the end result. I rotated the switches 90º and moved the fuse panel up. This didn’t leave any room for the main relay and terminal strip. I also had some repair work as a couple of lugs apparently were not properly crimped and the wires slipped out.
I added a new panel on the left beside the motor fuses to mount the terminal strip and motor relay. The wires hanging below are kind of messy and I’ll straighten that out when I get a chance.
Next step was to disconnect all the aluminum panels from the round battery support bars and then remove the bars. This photo shows the robot body laying on its side and all the panels hanging down also (I ended up removing all the legs as it was easier to access the battery area. I’m glad I made everything modular, everything came apart relatively easily).
I have to cut the battery supports down to 7” length, drill and tap a few holes and then I can put everything back together again.
It looks more or less the same as before but it is now 5” shorter than before. I still have to cut the plastic panels that hide all this down to the new size. One problem is that the panel that was over the power switches already has holes in it for accessin the switches and the digital power meter. Unfortunately I don’t have any more sheets of that plastic left so short of getting all new plastic I may have to figure out how to reuse some of the cutoff sections of paneling for that side.
I will continue to use the existing gel cell for power and see how much operating time I get out of it. I suspect that I will eventually have to replace it with a lithium battery pack but there is plenty of space to put a 30-50Ahr battery pack in there. The only issue I have to figure out is that in order to remove the battery one of the battery level posts has to be removed which requires removing a leg in order to access the top bolt. I need to come up with an easier method for changing out battery packs. Of course once the robot is standing on its legs vs sitting on a test stand, the easiest access would be to remove the 6 screws holding the battery base plate and then the battery can be lowered down. This might be awkward trying to maneuver between the legs and holding the plate up to remove the last two screws.... Always another design item to think about!
Today I’ll re-install the 4 legs that were calibrated and do the bench tests on the remaining 2 legs so once I get the servo wires I can install and calibrate them. I also need to do some quick tests using the new RoboPi computers to make sure I didn’t make any soldering mistakes!
Bob
I finally got the new CC so I was able to order longer servo wires, once those arrive I’ve install and calibrate the last 2 legs.
I also need to solder up a couple of wiring harnesses for the Master to Leg computer communications. I’ve got to get that communications protocols figured out soon so I can control more than one leg at a time using one wire to connect all the legs to the master.
One item that I didn’t think about until I reattached 4 of the legs is that removing 5” from the battery section means that that the leg is just barely touching the ground with the femur at 90º and tibia at 0º while it is sitting on my test stand. I need to find something to prop the body up higher so erratic leg movements don’t cause an unintended incident!