I had to throw away the coxa encoder arms that I made earlier. When I installed the arms I found several problems with the new design including the fact that they were almost impossible to install in the space available. Back to the drawing board and I reduced the length of the arm down to 1.5 inches and increased the width of the slots on the ends of the arm to 0.125 inches. I also drilled 2 more holes in the support plate to allow a hex wrench easier access to the screws that hold the springs to the movable portion of the leg. The screw connection for the spring may need some adjusting also, the spring is sitting at an angle and it should be level, may make some custom spacers to elevate the point where the springs connect to the leg. The springs I am describing are custom springs made using 0.54” music wire that was wound on a jig to get the correct spring length and connectors for the hold down screws.
I also mounted the femur and tibia encoder housings on one leg. I found that I was getting some interference from the head of a bolt that didn’t allow the encoder to turn smoothly. That was fixed by adding a thin washer on the encoder to push the encoder shaft away from the bolt head. Also the friction fit discs that slip on the encoder shaft had to be discarded as they were too thick. I figured it would be faster/easier to use the lathe to fabricate new parts rather than figuring out how to reduce the thickness from 0.25 to 0.21 inches.
Leg # 2 is now put back together, will be working on finishing up the other legs now that I have good measurements for the needed parts. The remaining legs should go a bit faster.
... The springs I am describing are custom springs made using 0.54” music wire that was wound on a jig to get the correct spring length and connectors for the hold down screws....
DiverBob, is that decimal in the right place? Half-inch music wire? Post a picture!
... The springs I am describing are custom springs made using 0.54” music wire that was wound on a jig to get the correct spring length and connectors for the hold down screws....
DiverBob, is that decimal in the right place? Half-inch music wire? Post a picture!
Oops, you are right, it should be 0.054 diameter! Half inch might be a bit hard to bend by hand...
I got leg #1 mechanicals updated and attempted to install the leg on the body. Unfortunately I discovered that the wiring harnesses I created for the encoders is about 2-3 inches too short. I got the bundled 6 wire cable length correct but the connectors were too short to reach the sensor plugs. Thats when I remembered that I cut the plug wires shorter by about 4 inches. So to get around this SNAFU that I created for myself, I wanted to see what the easiest fix would be. By swapping the positions of the sensor plugin board and the motor power board I was able to get the plugs close enough that I could plug in the sensors. The disadvantage of this was that I could see that the motor wires could potentially interfere with the coxa encoder movement, plus I was worried that the encoder wires are still tight and coxa movement could damage the wires. All the other potential solutions I thought of were either fairly extensive or too complicated. So the best answer I have is to go back and solder in the extra length of wire that I cut off. So that is about 120 solder connections to make again..... Unfortunately this was a self imposed problem this time.
Bob,
Did you ever get those harnesses rewired?
Jim
I haven’t posted in a while as I was in Maui diving for a while and since then I’ve been busy completing with laser project commitments (I got more orders than expected for a series of Great Lakes shipwreck maps I created) so the robot has been ignored. I will have time opening up starting in May so I will start fixing the wiring harnesses. Then I can get back to programming again, just about ready to test 2 leg movement. Of course by that time something else will happen/break and I’ll be fixing/modifying that also. In the course of testing the leg movements I found that the coxa reduction gear bronze bushing would fall out occasionally. This is a flanged bushing and the flange is on the underside of the part so gravity tends to help this problem. The fix would be fairly easy but time consuming, just machine a recess for the bushing on the ‘top’ of the part and then it can’t fall out. Unfortunately that involves a lot of disassembly, set up and cutting on the mill so I’ve just resorted to putting the bushing back in and try to pin it in place (unsuccessfully).
Glue?
Jealous of dining in Maui. Only diving I have ever done is 10 days in the Bahamas.
Jim
I haven't found a glue that would stand up to the forces that would be exerted on the bushing. I just need to do the correct fix, too many times I try a 'shortcut' and usually I regret it later. The rest of this month is filled with some traveling and other projects so the robot stays on the back burner for a bit longer. I am committed to getting this thing to walk eventually, I retired and its actually harder to find time to work on it!
My wife and I dive for 3 weeks in Maui every other year with the Caribbean as our choice on the off years. I dive year round, Great Lakes shipwreck diving season should be getting started shortly (waiting for the early storms to start to calm down now) and I'll be out diving most weekends off my boat.
Just a quick note to say this thread isn’t dead, its just summer.... The robot is still a work in progress, just less progress during the summer due to too many other distractions! I do manage to spend a bit of time on it but nothing major is happening at this time. The focus is re-wiring the magnetic encoder wiring harnesses to add the extra length needed so the leg can move freely. Thats a boring job so it keeps being put off! I do play with some other minor tweaks and run the software from time to time to fine tune the movements, still haven’t gotten 2 legs to run at once but it’s on the testing listing after the wiring update....
Back to summer fun, new RV so we are traveling around and seeing the things we missed during our younger years!
This has been the longest break from working on the robot since I started but summer is winding down so we won’t be traveling much until spring rolls around again in Michigan. So theoretically that means I should have more time to get back to work on the robot after I get caught up on the Honey-Do list!
I broke down and re-wired all the wiring harnesses that were too short by adding about 4 inches of extra wire to the harness length. Now that that chore is complete I am adding the tibia and femur encoders to the remaining 5 legs starting tonight. It’s been so long since I worked on this last that I have to disassemble the working leg to see what mods I added to it so I can make sure the remaining legs get the same changes added. The main battery has been charged back up and I can try out the coding again on the operating leg. Time to see if it is still operating the same way as I left it.
It’s good to be back! I occasionally would get back on the forum to read and see what was new but didn’t spend a lot of time here. Good to see the P2 is alive, I wonder if I could use one of those in place of the 7 P1’s being used by the robot?
I installed the encoders on one leg and decided that as long as I had it partially disassembled for that task, I would go ahead and finally fix the problem where the bronze bushings in the coxa gear train would fall out. This involves removing the bottom plate and taking the bushings out. Since the bushings are flanged, the fix is to simply insert the bushings back into the the existing holes but with the flanges on the top side of the plate so gravity and friction hold them in place. No machining necessary! The flanges only stick up .034 and don’t interfere with the gears. All this time I thought I would have to re-machine a new flange area, coming back with a fresh perspective helped me see past my prior assumptions.
Wiring addition
Bottom gear plate, view from bottom with bushings inserted from top
Bushing flanges hold bushings in place
Reduction gear assembly with bottom plate removed. Plenty of space for the flanges to rest on top of plate without interfering with the gears.
Bottom plate re-installed.
Coxa encoder installed. You can see the shaft that moves the encoder as the coxa moves.
Three legs are complete and installed. Working on #4 tonight. I had to read my own entries on this thread to see what additional changes I had to install for this leg. The other 2 legs already had most of the updates installed so the next 3 will be slower. Got the bushings fixed and now I’m setting up the coxa encoder so I have to create 2 more of my custom wire ‘springs’. Luckily the jig I made was still beside the vise, now to locate the music wire again and do some bending.
I haven’t turned on the computer and looked at the program yet, I’ll get these mechanical updates completed before I start programming again. Of course now I have to come back up to speed on my program, I believe I was about ready to run with 2 legs at the same time.
Leg #4 has all the updates installed and is ready to mount on the robot body. Starting on the next leg, it may go a bit faster since I was also making all the upgrade parts for the other legs too.
I got leg #5 finished, need to connect it to the robot next. One last leg to upgrade and all 6 are done. Still have to solder up the last 2 RoboPi boards as leg controllers.
I will have to come back up to speed on my leg software, its been a while since I did anything with it. I’m hopeful that this won’t take too much time, I’ve got to calibrate each leg, programming several props to talk to each other will be interesting....
I think the P2 rollout will be first!
Leg #5 is connected to the body now, started upgrades on the last leg. Unfortunately when I was cleaning up with the shopvac I accidentally vacuumed up some of the parts I had made. I couldn’t find them in the vacuum bag, its mostly full of sawdust, plastic shavings and aluminum scrap, about 10 lbs worth. After a while of trying to find the parts (you’d think they would be near the top?) I finally gave up and started to re-create them fresh.
I didn’t like to look of the wire harness on each leg so I used some 1/4” split loom plastic to encase the wires. Now it looks much nicer, need to zip tie the wires to the leg also.
I’ll get some fresh photos of the hexapod once its all put back together, its been a while since its been assembled this much, I think it was at the last Unofficial Parallax Expo in Findlay, Ohio. I miss having those get together, it was fun to see other like minded people and the projects everyone came up with!
Leg #6 upgrades are complete and it is attached to the body. This is the first time all legs have been attached since the last Parallax Expo. The top dome is still empty, haven’t had time to work on the Lidar unit and cameras that will be placed in there eventually.
Here is another view of the power control panel with the Lascar PanelPilot display configured to show main battery voltage.
Next step is to start the leg calibration process. For this I have a program that moves each axis of the leg to the extremes of each axis and records the minimum and maximum encoder values. It does this some 10 times per axis so I can compare values and see if there is any variance. Any thing more than a couple of counts off indicates the encoder is sticking or something is loose. If that happens then I have to troubleshoot the movement and figure out a fix. The upgrades I put into each leg should eliminate that problem but the routine is still good for finding the unexpected.
But before I start calibrating I am going to be studying the old leg code and running it on the first installed leg. Got to make sure I haven’t forgotten anything that needs attention in the code.
Each leg is 26 lbs x 6 = 156lbs. I haven’t weighted the body with battery but I would estimate it to be around 50 lbs for a total weight of just over 200 lbs. One of these days I will get a completed weight. Luckily each linear motor can move 300 lbs and since they move in groups of three there shouldn’t be any issues. Several times during testing when the test leg program misbehaved it was easily picking up the whole side of the robot off the test stand before I could hit the stop.
In between getting ready for Thanksgiving and everything else I finally finished soldering the last 2 RoboPi computer boards for the robot.
Now I have all 6 leg controllers and master computer completed.
Powered up the test leg for the first time in a while, loaded the latest program, guess what it still works! After running a few movements through the manual input option I noticed saw some issues again that had been bothering me the last time I was here. This time I was able to recognize that the PI controller was pushing the motor speed due to Integral windup thus causing overshoot. This time I quickly found a solution that had been eluding me previously. I couldn’t remove or reduce the Integral portion as that is needed to enable motor moves when the requested move is a very small value. So I came up with an new default ‘max’ value for the integral value and after a bit of experimentation along with finding a Ki multiplication factor, the leg moves as expected with small or large input values.
The next item on the troubleshooting list is figuring out how to improve the communications link between the leg controller and the master. The current setup has the feedback loop from the legs to the master as part of the master loop. However the master loop spends most of its time sitting and waiting for input from the master so it doesn’t send any info back to the master until after it receives new input from the master. I realized that since I am only using 6 cogs now so I am thinking about setting up a dedicated cog just for output serial communications to the master and leave the existing input comms where they are now. I’ll look into that more tomorrow.
It didn’t take as long as to come back up to speed on the leg controller as I thought it might. The PID setup has simplified the code considerably and makes it easier to see what is going on as compared to the earlier versions of the code.
DiverBob, I just have to say this is awesome, I never realized the scale of the full robot! I also got one of those RoboPi boards from Bill and wondering what I should do with it (have it figure out how to use it, really.) Looks like you are putting yours to great use! Please keep the great updates and photos coming, it has been really something to follow the progress.
Working on coding today, specifically made some changes to all the PI loops to keep them the same, the only differences between them are the Kp and Ki multiplier values.
Next stop was setting up a new cog for feedback communications to the master. Once I set this up and moved the feedback code to the new cog for execution. Of course once I see it in code I start thinking about ways to improve it. Right now the setup would be that each leg has its own feedback loop to the master and each one is sent to a separate input pin on the master. The master could have one cog dedicated to reading the 6 separate inputs sequentially and storing the incoming values so that other cogs can access the data as needed.
My thought is that with no synchronization between the legs, data can be lost from a leg that is reporting an error condition while the master is busy reading/writing another leg’s data.
A method to synchronize is to use a single master feedback input pin that all the legs are connected to. The master sequentially queries each leg and the prompted leg uploads its data. I already send an identifier and leg number via the feedback loop (‘$,’ is used to indicate a string, followed by a numeric indicator (1-6) representing the leg number (the rest of the string is another number, 1-9 to to indicate the leg source, such as 1 is Femur, 2 is Tibia, 3 is Coxa, which is then followed by a data value). This requires monitoring and sending code (much like what is currently in the main loop). Especially since its in its own cog so I can’t just can’t call the PUB in the main loop (I can just copy them with a different name but I hate to duplicate things like that!). I love tha parallel processing of the P1 but situations like this where multiple processors need to share the same code can be a pain at times. I’m sure there is an easier way of doing this but I don’t know it!
Still thinking of alternatives and will be doing some searches in the P1 discussion forums tonight.
I'm not too clear on what you mean in that last paragraph. Are you sending actual pasm/spin code between the cogs or prop chips, or are you sending data that results in some specific code being executed?
I'm not too clear on what you mean in that last paragraph. Are you sending actual pasm/spin code between the cogs or prop chips, or are you sending data that results in some specific code being executed?
My setup has 6 leg controllers and one master computer. The master computer sends leg commands to the individual legs using a format like this: $,6,2,900. That command translates as move leg 6 tibia motor to 90.0º position. Once the command is sent the leg then executes the command. Each leg controller also generates information related to the commanded movement that needs to be sent back to the master for display or further operations. The format for that command is similar to the incoming command; $6,4,1. This translates in the master as coming from leg 6, error #1 identified.
Right now I have the leg controller wired directly to two separate pins on the master for signal transmission and reception. Now I am in the process of adding in the additional leg controllers and I need to come up with a good communications system. At one point I was going to have each leg controller connecting to separate master pins (6 transmit and 6 receivers) but I don’t really like that solution. I’ve since been thinking of using a single master transmit and receiving lines instead. Since I already use a leg identifier in the data stream both directions, I can wire the master to leg as a single wire to each controller and use the existing data format so each leg can pick up the data it needs.
I’m thinking about using a similar setup for the feedback loop. For the longest time I did not have any extra cogs available on the leg controllers but with the code improvements there are a couple of unused cogs now. I can set up a dedicated cog just for sending data back to the master over a single wire that connects to all the legs. This is a trickier process than the master sending out to the individual legs as all 6 legs could transmit back to the master and interfere with each other. My idea is to have the master control the data coming into it by sending a query to each leg in turn and the leg then send its data. That would eliminate the interference issue at the expense of additional code and wiring complexity, since I have to have a dedicated transmit line from the master.
So what I’m trying to do is figure out if this is the best way to approach this problem or if there is a better way I haven’t seen yet. I hope that explains the process better, I kind of clouded the issue earlier when talking about some of the difficulties running parallel processes.
I can set up a dedicated cog just for sending data back to the master over a single wire that connects to all the legs. This is a trickier process than the master sending out to the individual legs as all 6 legs could transmit back to the master and interfere with each other. ...........
So what I’m trying to do is figure out if this is the best way to approach this problem or if there is a better way I haven’t seen yet. I hope that explains the process better, I kind of clouded the issue earlier when talking about some of the difficulties running parallel processes.
This type of communication has been done many times in the past using one of several protocols. Typically it goes like this:
A single half duplex line goes from the master to all the slaves.
All slaves listen for a command addressed to them from the master.
When a slave receives a command it sends back data and/or acknowledgement to the slave and then goes back to listening.
Most commonly used protocol is probably csma/cd, which is the method used by ethernet.
....
This type of communication has been done many times in the past using one of several protocols. Typically it goes like this:
A single half duplex line goes from the master to all the slaves.
All slaves listen for a command addressed to them from the master.
When a slave receives a command it sends back data and/or acknowledgement to the slave and then goes back to listening.
Most commonly used protocol is probably csma/cd, which is the method used by ethernet.
I misspoke earlier using the term ‘single wire’. What I meant was daisy-chaining all the leg computers to a common pin on the master for a dedicated transmit line from the master to each leg. This line is just for sending leg movement instructions from the master to the leg controllers from the main program loop. I didn’t want to add any more code overhead to receive data on the main loop due to the the amount of floating point math calculations it was already doing for figuring out leg movement. I have already seen some evidence that the code might be too slow as I add calculations for additional legs so I’m trying not to overburden the main loop any more than necessary.
I’m using a separate wire to daisy-chain as a dedicated line for feedback from the leg to master. This is where possible data interference can occur due to all 6 legs having data to send to the master over this line.
I’m using a 4 port serial object so I can dedicate a new port on a new cog for this additional communications link. Having a dedicated line from the master to the legs for transmission simplifies the coding on the master side of things, it just has to have a loop where it requests data from a specific leg and the specific leg sends back the information. The other legs just have to listen for when a command is applicable to them.
I did a lot of reading last night on prop to prop communications, there are a lot of options out there! The setup I’m looking at implementing has 2 separate ports on two cogs transmitting from the master with a separate port recieving data on the master for leg feedback. The feedback loop is required to make this a closed loop system so that if for some reason a leg can not complete a requested movement then the master can perform some action. Otherwise it could lead to major mechanical breakage or the robot falling over. Plus I have some additional sensors to add to the legs In the future that need to send data back also.
I’m going to start programming this in today, nothing else planned for distractions so hopefully I can get some momentum going on this and get it into testing.
Comments
I also mounted the femur and tibia encoder housings on one leg. I found that I was getting some interference from the head of a bolt that didn’t allow the encoder to turn smoothly. That was fixed by adding a thin washer on the encoder to push the encoder shaft away from the bolt head. Also the friction fit discs that slip on the encoder shaft had to be discarded as they were too thick. I figured it would be faster/easier to use the lathe to fabricate new parts rather than figuring out how to reduce the thickness from 0.25 to 0.21 inches.
Leg # 2 is now put back together, will be working on finishing up the other legs now that I have good measurements for the needed parts. The remaining legs should go a bit faster.
DiverBob, is that decimal in the right place? Half-inch music wire? Post a picture!
Oops, you are right, it should be 0.054 diameter! Half inch might be a bit hard to bend by hand...
Did you ever get those harnesses rewired?
Jim
Jealous of dining in Maui. Only diving I have ever done is 10 days in the Bahamas.
Jim
My wife and I dive for 3 weeks in Maui every other year with the Caribbean as our choice on the off years. I dive year round, Great Lakes shipwreck diving season should be getting started shortly (waiting for the early storms to start to calm down now) and I'll be out diving most weekends off my boat.
Back to summer fun, new RV so we are traveling around and seeing the things we missed during our younger years!
Bob
I broke down and re-wired all the wiring harnesses that were too short by adding about 4 inches of extra wire to the harness length. Now that that chore is complete I am adding the tibia and femur encoders to the remaining 5 legs starting tonight. It’s been so long since I worked on this last that I have to disassemble the working leg to see what mods I added to it so I can make sure the remaining legs get the same changes added. The main battery has been charged back up and I can try out the coding again on the operating leg. Time to see if it is still operating the same way as I left it.
JIm
I installed the encoders on one leg and decided that as long as I had it partially disassembled for that task, I would go ahead and finally fix the problem where the bronze bushings in the coxa gear train would fall out. This involves removing the bottom plate and taking the bushings out. Since the bushings are flanged, the fix is to simply insert the bushings back into the the existing holes but with the flanges on the top side of the plate so gravity and friction hold them in place. No machining necessary! The flanges only stick up .034 and don’t interfere with the gears. All this time I thought I would have to re-machine a new flange area, coming back with a fresh perspective helped me see past my prior assumptions.
Wiring addition
Bottom gear plate, view from bottom with bushings inserted from top
Bushing flanges hold bushings in place
Reduction gear assembly with bottom plate removed. Plenty of space for the flanges to rest on top of plate without interfering with the gears.
Bottom plate re-installed.
Coxa encoder installed. You can see the shaft that moves the encoder as the coxa moves.
I haven’t turned on the computer and looked at the program yet, I’ll get these mechanical updates completed before I start programming again. Of course now I have to come back up to speed on my program, I believe I was about ready to run with 2 legs at the same time.
You still have a chance to have this thing walking it's first step before Chip finishes the final P2.
still betting on you...
Mike
I will have to come back up to speed on my leg software, its been a while since I did anything with it. I’m hopeful that this won’t take too much time, I’ve got to calibrate each leg, programming several props to talk to each other will be interesting....
I think the P2 rollout will be first!
I didn’t like to look of the wire harness on each leg so I used some 1/4” split loom plastic to encase the wires. Now it looks much nicer, need to zip tie the wires to the leg also.
I’ll get some fresh photos of the hexapod once its all put back together, its been a while since its been assembled this much, I think it was at the last Unofficial Parallax Expo in Findlay, Ohio. I miss having those get together, it was fun to see other like minded people and the projects everyone came up with!
Bob
Here is another view of the power control panel with the Lascar PanelPilot display configured to show main battery voltage.
Next step is to start the leg calibration process. For this I have a program that moves each axis of the leg to the extremes of each axis and records the minimum and maximum encoder values. It does this some 10 times per axis so I can compare values and see if there is any variance. Any thing more than a couple of counts off indicates the encoder is sticking or something is loose. If that happens then I have to troubleshoot the movement and figure out a fix. The upgrades I put into each leg should eliminate that problem but the routine is still good for finding the unexpected.
But before I start calibrating I am going to be studying the old leg code and running it on the first installed leg. Got to make sure I haven’t forgotten anything that needs attention in the code.
Bob
Bob
Now I have all 6 leg controllers and master computer completed.
The next item on the troubleshooting list is figuring out how to improve the communications link between the leg controller and the master. The current setup has the feedback loop from the legs to the master as part of the master loop. However the master loop spends most of its time sitting and waiting for input from the master so it doesn’t send any info back to the master until after it receives new input from the master. I realized that since I am only using 6 cogs now so I am thinking about setting up a dedicated cog just for output serial communications to the master and leave the existing input comms where they are now. I’ll look into that more tomorrow.
It didn’t take as long as to come back up to speed on the leg controller as I thought it might. The PID setup has simplified the code considerably and makes it easier to see what is going on as compared to the earlier versions of the code.
Next stop was setting up a new cog for feedback communications to the master. Once I set this up and moved the feedback code to the new cog for execution. Of course once I see it in code I start thinking about ways to improve it. Right now the setup would be that each leg has its own feedback loop to the master and each one is sent to a separate input pin on the master. The master could have one cog dedicated to reading the 6 separate inputs sequentially and storing the incoming values so that other cogs can access the data as needed.
My thought is that with no synchronization between the legs, data can be lost from a leg that is reporting an error condition while the master is busy reading/writing another leg’s data.
A method to synchronize is to use a single master feedback input pin that all the legs are connected to. The master sequentially queries each leg and the prompted leg uploads its data. I already send an identifier and leg number via the feedback loop (‘$,’ is used to indicate a string, followed by a numeric indicator (1-6) representing the leg number (the rest of the string is another number, 1-9 to to indicate the leg source, such as 1 is Femur, 2 is Tibia, 3 is Coxa, which is then followed by a data value). This requires monitoring and sending code (much like what is currently in the main loop). Especially since its in its own cog so I can’t just can’t call the PUB in the main loop (I can just copy them with a different name but I hate to duplicate things like that!). I love tha parallel processing of the P1 but situations like this where multiple processors need to share the same code can be a pain at times. I’m sure there is an easier way of doing this but I don’t know it!
Still thinking of alternatives and will be doing some searches in the P1 discussion forums tonight.
Bob
Right now I have the leg controller wired directly to two separate pins on the master for signal transmission and reception. Now I am in the process of adding in the additional leg controllers and I need to come up with a good communications system. At one point I was going to have each leg controller connecting to separate master pins (6 transmit and 6 receivers) but I don’t really like that solution. I’ve since been thinking of using a single master transmit and receiving lines instead. Since I already use a leg identifier in the data stream both directions, I can wire the master to leg as a single wire to each controller and use the existing data format so each leg can pick up the data it needs.
I’m thinking about using a similar setup for the feedback loop. For the longest time I did not have any extra cogs available on the leg controllers but with the code improvements there are a couple of unused cogs now. I can set up a dedicated cog just for sending data back to the master over a single wire that connects to all the legs. This is a trickier process than the master sending out to the individual legs as all 6 legs could transmit back to the master and interfere with each other. My idea is to have the master control the data coming into it by sending a query to each leg in turn and the leg then send its data. That would eliminate the interference issue at the expense of additional code and wiring complexity, since I have to have a dedicated transmit line from the master.
So what I’m trying to do is figure out if this is the best way to approach this problem or if there is a better way I haven’t seen yet. I hope that explains the process better, I kind of clouded the issue earlier when talking about some of the difficulties running parallel processes.
This type of communication has been done many times in the past using one of several protocols. Typically it goes like this:
A single half duplex line goes from the master to all the slaves.
All slaves listen for a command addressed to them from the master.
When a slave receives a command it sends back data and/or acknowledgement to the slave and then goes back to listening.
Most commonly used protocol is probably csma/cd, which is the method used by ethernet.
I’m using a separate wire to daisy-chain as a dedicated line for feedback from the leg to master. This is where possible data interference can occur due to all 6 legs having data to send to the master over this line.
I’m using a 4 port serial object so I can dedicate a new port on a new cog for this additional communications link. Having a dedicated line from the master to the legs for transmission simplifies the coding on the master side of things, it just has to have a loop where it requests data from a specific leg and the specific leg sends back the information. The other legs just have to listen for when a command is applicable to them.
I did a lot of reading last night on prop to prop communications, there are a lot of options out there! The setup I’m looking at implementing has 2 separate ports on two cogs transmitting from the master with a separate port recieving data on the master for leg feedback. The feedback loop is required to make this a closed loop system so that if for some reason a leg can not complete a requested movement then the master can perform some action. Otherwise it could lead to major mechanical breakage or the robot falling over. Plus I have some additional sensors to add to the legs In the future that need to send data back also.
I’m going to start programming this in today, nothing else planned for distractions so hopefully I can get some momentum going on this and get it into testing.
Bob