As best I can determine, I have a bad Prop Activity Board, no signs of life except for the power LEDs. I sent an email to Parallax Tech Support to see if they have any suggestions. But I suppose I'll need to buy another one to continue since I need the XBee connector for this next stage of programming. I did order a XBee breakout board that I would be able to use on the prop development board once it shows up. I think I'll look around the Parallax store for a while and see what other options are out there.
After a week of email back and forth, I'm sending the Activity board back to Parallax so they can validate the USB circuitry is out. This is the first time I've had a Parallax product not work out of the box. Unfortunately the board had been sitting around unused since I didn't get to the XBee programming as soon as I originally expected. In the meantime I received a XBee adapter so there isn't an immediate need for the Activity board. As long as I had the soldering station warmed up I also put together another RoboPi board; 2 done, 4 more to go!
I did a quick test this afternoon with the XBee, I loaded the transmitter app in the Q4 transmitter, the only change I made to Paul K. Program was to the LCD display to show the output for 5 controls; X and Y axis on gimbal 1, the pushbutton on Gimbal 1, a toggle switch and a pushbutton switch. The reciever app was wired to display 5 LEDS, one for each control would lite, a slight variation on Paul K's reciever app. Unfortunately it didn't work and I ran out of time to troubleshoot. I don't have any experience with XBee so this could be a long process! Like, how do you know it's actually transmitting and receiving? Should be fun to figure out.
If you post the code your using I could take a look at it. I have a similar testing setup like your describing.
I just went over the code and didn't find any wiring errors or any obvious programming snafus. The transmitter program shows the desired output values on the LCD correctly. I'm using a Parallax Developer board for the RX and the XBee reciever is connected to +5v, GND, TX and RX lines only.
I hope you can see what is going wrong! Is there any way to validate the transmitter is transmitting and the reciever is recieving data?
I tried your code out and it works you just mixed up the channel assignments.
Using a Propeller BOE I ran your RX code with the changes below. I loaded my Q4 with your TX code so I could see the channel values on the LCD.
Just swap the Output Test portion of the RX code with the lines of code below.
Repeat
If XBee_Data[0] > 1000 'If Gimbal 1 Horizontal A/D data larger than 1000
OutA[7]~ 'Low
Else
Outa[7]~~ 'High
If XBee_Data[1] > 1000 'If Gimbal 1 Vertical A/D data larger than 1000
OutA[6]~ 'Low
Else
Outa[6]~~ 'High
If XBee_Data[2] > 2000 'Gimbal 1 Push Button
OutA[5]~ 'Low
Else
Outa[5]~~ 'High
If XBee_Data[17] > 2000 'Left Oval Pressed
OutA[4]~ 'Low
Else
Outa[4]~~ 'High
If XBee_Data[18] > 2000 'Toggle Switch 3 Flipped
OutA[3]~ 'Low
Else
Outa[3]~~ 'High
Thanks for the suggestion but that isn't working either. The LEDs do their initialization correctly but no response from any control movement on the transmitter. I've got the TX going to P1 and RX to P0. I'm supplying 5v to the XBee from the Developer Board. I'm using an AdaFruit adapter board for the XBee. Any recommendations on how to test that the XBee's are working right?
I just found that I also got a SparkFun XBee USB board also (forgot about that one). I'll download the Digi windows app and check the operation of both XBee's with that.
I think the issue is your XBee's are not communicating. I would pull both XBee's and read them to see how they are setup.
Baud Rate, CH, Pan ID, DL, MY, & the software version of each.
I think the issue is your XBee's are not communicating. I would pull both XBee's and read them to see how they are setup.
Baud Rate, CH, Pan ID, DL, MY, & the software version of each.
There were some differences between your settings and mine so I updated the firmware and matched your settings. I see you have them set at 57.6K but the code for the Transmitter and Receiver is set at 9600. Does the code overwrite the default setting then? I will have to test them tomorrow, getting late now and have other things to do first. Hope this solves this communications problem!
The codes posted in post #367 are using 57.6K for TX and RX. If the xbee's were never configured to run at 57.6K then that's probably the issue.
The XBee settings above will work with the code you posted and the orginal versions I have up on my site.
That was the answer! I was able to run the simple app and control the LEDs. Now I can start programming the transmitter to tell the master computer what commands to send out to the test leg. I'll start out with some simple stuff and work my way forward from there.
Here's a project update! For those who also browse the Prop 1 forum you will see topics I'm working on over there. The last item I have been experimenting with is the communications between multiple props. Right now I have the prop in the transmitter talking to the master board using XBee. That is working out pretty good now. The master prop has to be able to communicate with the 6 slave props for the legs. For this I am using 2 copies of a 4 port serial port in the master and one copy in each slave device. The slave devices need 2 ports themselves, one for the master and one for serial output to a monitor for troubleshooting.
I have just started experimenting using a single port and displaying the output on the monitor. Next I will add in another port and see how well I can send position commands via the transmitter to a slave prop via the master prop and display troubleshooting data on the monitor at the same time. That sounds even more complicated when I write it out! Then I'll be adding on additional legs as I solder together the RoboPi boards. The first test is controlling the position of the Femur using a potentiometer on the radio transmitter.
I took some video of the leg testing with the new serial interface where I manually enter the leg commands via the monitor. I will compile that and get a link in here soon. There isn't as much things to show once programming is happening, not like the build phase! Speaking of building, I picked up a nice 14 port fused power distribution block from our local marine store, I want to use this for computer power distribution. Each computer will have its own fused power with plenty of spots for future expansion.
Thanks for sticking with me through this project! It's getting closer all the time to when I start to see things moving automatically under full computer control. I'm not expecting to have this walking in time for the big get Propellor get together in August (anyone know what the dates are for this yet?) but parts will be moving this time.
After running into a problem earlier today with the new 4 port serial interface, I decided to work on the computer power distribution. This meant finding a suitable mounting surface for the distribution hardware. In addition, I wanted to mount the recharger connections for the batteries so that is easier to access. I drilled and mounted all the components, now I need to wire everything together.
I figured out that I wired the Tx and RX lines from the master computer to the wrong prop pins. Once that was changed I started to get an output on the terminal. I've got another problem to solve, but occasionally it works right!
I was able to use a potentiometer on the radio transmitter to change the position of the femur! This is the first time I've got 3 separate props to talk to each other. The transmitter is a prop-based computer sending XBee radio comms to the master prop computer which then sends the leg movement information to the slave prop which then moves the leg to the requested position. The comms are still intermittent so some corrections in the slave prop coding is required to ensure the commands are coming in right. For me this is a big step that's been a long time coming.
Once that problem is ironed out then I can look at adding additional legs and being able control them from the transmitter. I'll be doing this slowly, one leg at a time so I can make sure everything is working right first. I don't want unexpected movements out of a robot this big and powerful!
I got the reliability issue sorted out so the leg is responding to the transmitter pretty well. I am starting to add in some additional functionality more for testing and learning how to set up the programming correctly for later. I'm figuring out how to send an error notice and the 'wait until I finish this movement' notice back to the master prop. Sending the signal is easy, how to respond to it is the head scratcher. I also want to add in another leg and start running more than one leg at a time.
In the meantime I'm also wiring up the computer and aux power distribution. Just following a schematic at this point and a lot of crimping of ring terminals.
I am planning on going to Orrville, Ohio on August 30 for the get together there and I will bring the hexapod. Hopefully it will be able to do something interesting by that point! I don't expect walking but it would be nice to be able to individually control each leg from the transmitter and maybe program in some multi leg coordinated movement like raise and lower itself or spin in place.
I can't make the Aug 8th date this time, maybe next year. I am signed up for the event in Orrville, Ohio on Aug 30th. I hope to see some of you there. It won't be walking but at least there will be movement in some legs! How much depends on how much time I can get in the basement programming.
I almost missed out on knowing about the Orrville Mini Expo/Hackathon, August 30, 2014 (http://propellerpowered.com/forum/index.php?topic=583.0). Unfortunately I can't go to either as my project is on display in Grand Haven, MI. Maybe next year.
I put together a short video of current progress. I haven't been moving as fast as expected, too many summer distractions. But I do have the transmitter sending commands to the master computer which is then instructing a slave computer for a leg to move. What isn't in the video is the work over this last weekend where I was able to configure all 3 motors to run independently using the transmitter. However I did run into some issues with getting all 3 motors to move at the same time. I need to track that problem down, I think it is a timing issue from the master to the slaves as the master is showing the correct commands being processed but the slave is only responding to the last command programmed. It takes quite a bit longer to troubleshoot multiple propeller boards as there are 3 separate chips involved in the process now.
[video=youtube_share;oZNkmzNv3MA]
The video shows commanding the leg from the master via the PST and then at the end is controlling via a XBee transmitter. I still have a ways to go before the robot takes that first step but I'm getting closer all the time. I want to get the code working so that I can control all 3 motors simultaneously using the transmitter. Then I'll be ready to pull in a second leg to run both at the same time. I may try putting together some of the Inverse Kinematics routines with a simple gait control around 1 or 2 legs to see how that part works also. Don't think I'll have that ready for the end of Aug together.
Fun weekend, displayed one of the hexapod legs at the Tormach Open House. Tormach is the manufacturer of the CNC mill I used for the hexapod parts. Lots of questions from machinists instead of microprocessor and robot enthusiasts. The questions were coming from a different direction than most of the folks on here. Saw a lot of nice tools that I'd love to have...
I have been having several software issues that I haven't been able to solve after several weeks of study and troubleshooting. Most notably is that while I can control each axis independently of each other, the system is not reliably responding when 2 or 3 motors get commands to move. I've verified there are no global variables that are being shared, each axis is running on its own cog and I've run out of tests I can think of to narrow this down. So I'm thinking of taking a step back and re-examining the concept of having all the motors running on a single cog in a single routine vs each motor on its own cog.
The initial idea I'm flowcharting is that there are no loops within the main motor routine for individual motors. Each motor movement is broken up into 4 phases, acceleration, steady state, deceleration and stopped. Variables would track the phase, current speed, current position, desired position for each motor. All motors will continue through the routine until all complete the specific movement. The key for this type of movement schema is to keep the individual movement distances as smaller, incremental values so you aren't stuck waiting for a long movement before another movement can be started.
I still have some thinking through and roughing out the flow path to see how well this will work. I am taking a break from working on the old software for a bit so I can come back and look at it with fresh eyes, maybe I'll see something different then. I'll have one leg capable of movement for the Aug. 30th show but I won't be as far along as I had hoped at that point. Maybe someone at the show can see the problem in the code!
Voltage issues were one of the first items I checked. The motors are powered via HB-25s which have their own battery supply independent of the computer supply. No indications that there are any significant spikes in the computer supply. I really think the problem lies in my program setup, today I had the idea it might be around the individual motor done flags not setting/resetting properly. I hope to check that out soon (working way too late tonight for any meaningful time in the code ). Have to figure out how to test that now....
The battery is a LARGE capacitor, indeed; however, it's the voltage at the HP-25s that matters. Wire length, size and circuit may make a difference. Would you be able to determine if the HP-25s are resetting?
Is the main controller sending a single pulse or a stream of pulses to the HB-25s? Multiple simultaneous single pulses may be missed at the HP-25s. A stream of pulses can be measured at the HP-25s. The absence of pulses will confirm your software issue.
Bob: I just watched your 7/28 video. Amazing robot overall and your steady progress is exemplary.
Just curious how much torque your coxa motors have. They move silently (no load) in your video and much faster than your other (weight-bearing) motors. How do you calculate how much torque is needed there? Is there a max goal load there, like climbing a 5% slope?
The battery is a LARGE capacitor, indeed; however, it's the voltage at the HP-25s that matters. Wire length, size and circuit may make a difference. Would you be able to determine if the HP-25s are resetting?
Is the main controller sending a single pulse or a stream of pulses to the HB-25s? Multiple simultaneous single pulses may be missed at the HP-25s. A stream of pulses can be measured at the HP-25s. The absence of pulses will confirm your software issue.
Software design has a pulse sent every 40 ms. I'm pretty sure that no signal is going to the motors that aren't moving based on some of the tests I ran earlier. Thinking further about the situation and the software design I'm starting to believe the problem isn't in the actual motor control routine but in the way the motor done flags are set and reset. Each motor has its own done flag that is set to 1 while the motor is moving and then reset once the move is completed. I think the symptoms are pointing toward the flag not being reset properly so it won't accept a new command yet the motor run routine has either completed a run or there was a condition that caused the motor to stop.
I'll have to devise some tests for this now.
Thanks for helping me start to think in a different direction!
Bob: I just watched your 7/28 video. Amazing robot overall and your steady progress is exemplary.
Just curious how much torque your coxa motors have. They move silently (no load) in your video and much faster than your other (weight-bearing) motors. How do you calculate how much torque is needed there? Is there a max goal load there, like climbing a 5% slope?
Thanks for the kind words! I'm not as positive about progress, the first two years went more or less as planned but this was the year for software and I thought I'd be much further along than I am. The programming has turned out to be much more difficult than anticipated. I'm learning a lot and there is progress but at times it's painfully slow. It doesn't help that its summer here in Michigan with scuba and bike riding taking up time too. However it looks like a long winter coming so maybe I'll spend some more time on the project!
I measured the torque back when I found the Coxa motors but can't recall the value now but it was pretty significant at the rated voltage of 12v. I know that I can barely slow down the motor when I put a pair of pliers on the shaft and it's turning 190rpm! The fact that the motors were designed to move car seats with large people in them is what originally got me interested in testing them in the first place. Since the rpm is further slowed down to about 25rpm the torque increases about 7 times. I did grab a leg once while the Coxa was moving and it kept going and almost knocked the whole thing onto the floor! No more testing like that planned! I like to think the Coxa movement is quiet because of how well the reduction gear is designed! It does make noise but it just runs for a much shorter time than the other motors.
The other item is that the design of the system has the femur and tibia taking the majority of the load, the Coxa should normally be moving the body perpendicular to the force of gravity which should minimize the amount of torque needed. Once it's walking on its own I'll test and see how well it handles slopes but it will be flat, level ground at first!
Sounds like you need to tweak how everything moves using interpolation. In short all motors move from point A to B no matter the distance, at the same time.
Even though a motor/leg doesn't move it should still receive a pulse. My idea which I used to make my code was to constantly update every motor/servo non-stop. Even if it didn't move. You have a cog constantly looping feeding data to you motors. The Q4 feeds the values in a mian loop to alter the motor loop.
Can you post your code/codes. Since your using multiple props, post all of the files.
Sounds like you need to tweak how everything moves using interpolation. In short all motors move from point A to B no matter the distance, at the same time.
Even though a motor/leg doesn't move it should still receive a pulse. My idea which I used to make my code was to constantly update every motor/servo non-stop. Even if it didn't move. You have a cog constantly looping feeding data to you motors. The Q4 feeds the values in a mian loop to alter the motor loop.
Can you post your code/codes. Since your using multiple props, post all of the files.
Here is a copy of the Transmitter, Reciever (master computer) and leg computer codes. Warning, the last person to look at the leg code complained his eyes were bleeding! So be careful! Anyway, see if anything jumps out, there is a lot of troubleshooting code in there to push data to a serial terminal which can make it hard to read. There is a seperate routine for each motor however all three are very similar in structure. Thanks for looking!
Comments
I did a quick test this afternoon with the XBee, I loaded the transmitter app in the Q4 transmitter, the only change I made to Paul K. Program was to the LCD display to show the output for 5 controls; X and Y axis on gimbal 1, the pushbutton on Gimbal 1, a toggle switch and a pushbutton switch. The reciever app was wired to display 5 LEDS, one for each control would lite, a slight variation on Paul K's reciever app. Unfortunately it didn't work and I ran out of time to troubleshoot. I don't have any experience with XBee so this could be a long process! Like, how do you know it's actually transmitting and receiving? Should be fun to figure out.
Bob
I just went over the code and didn't find any wiring errors or any obvious programming snafus. The transmitter program shows the desired output values on the LCD correctly. I'm using a Parallax Developer board for the RX and the XBee reciever is connected to +5v, GND, TX and RX lines only.
I hope you can see what is going wrong! Is there any way to validate the transmitter is transmitting and the reciever is recieving data?
Bob
Q4 TX Code V3.61.spin
Q4 Rx V3.61.spin
Using a Propeller BOE I ran your RX code with the changes below. I loaded my Q4 with your TX code so I could see the channel values on the LCD.
Just swap the Output Test portion of the RX code with the lines of code below.
Repeat If XBee_Data[0] > 1000 'If Gimbal 1 Horizontal A/D data larger than 1000 OutA[7]~ 'Low Else Outa[7]~~ 'High If XBee_Data[1] > 1000 'If Gimbal 1 Vertical A/D data larger than 1000 OutA[6]~ 'Low Else Outa[6]~~ 'High If XBee_Data[2] > 2000 'Gimbal 1 Push Button OutA[5]~ 'Low Else Outa[5]~~ 'High If XBee_Data[17] > 2000 'Left Oval Pressed OutA[4]~ 'Low Else Outa[4]~~ 'High If XBee_Data[18] > 2000 'Toggle Switch 3 Flipped OutA[3]~ 'Low Else Outa[3]~~ 'HighI just found that I also got a SparkFun XBee USB board also (forgot about that one). I'll download the Digi windows app and check the operation of both XBee's with that.
Bob
Baud Rate, CH, Pan ID, DL, MY, & the software version of each.
My Setup:
Q4 controller
Baud: 57.6K, CH: 12, Pan ID: 5010, DH: 0, DL: 1, MY: 0, V10ED
RX
Baud: 57.6K, CH: 12, Pan ID: 5010, DH: 0, DL: 0, MY: 1, V10ED
Paul
The XBee settings above will work with the code you posted and the orginal versions I have up on my site.
That was the answer! I was able to run the simple app and control the LEDs. Now I can start programming the transmitter to tell the master computer what commands to send out to the test leg. I'll start out with some simple stuff and work my way forward from there.
I have just started experimenting using a single port and displaying the output on the monitor. Next I will add in another port and see how well I can send position commands via the transmitter to a slave prop via the master prop and display troubleshooting data on the monitor at the same time. That sounds even more complicated when I write it out! Then I'll be adding on additional legs as I solder together the RoboPi boards. The first test is controlling the position of the Femur using a potentiometer on the radio transmitter.
I took some video of the leg testing with the new serial interface where I manually enter the leg commands via the monitor. I will compile that and get a link in here soon. There isn't as much things to show once programming is happening, not like the build phase! Speaking of building, I picked up a nice 14 port fused power distribution block from our local marine store, I want to use this for computer power distribution. Each computer will have its own fused power with plenty of spots for future expansion.
Thanks for sticking with me through this project! It's getting closer all the time to when I start to see things moving automatically under full computer control. I'm not expecting to have this walking in time for the big get Propellor get together in August (anyone know what the dates are for this yet?) but parts will be moving this time.
Bob
I was able to use a potentiometer on the radio transmitter to change the position of the femur! This is the first time I've got 3 separate props to talk to each other. The transmitter is a prop-based computer sending XBee radio comms to the master prop computer which then sends the leg movement information to the slave prop which then moves the leg to the requested position. The comms are still intermittent so some corrections in the slave prop coding is required to ensure the commands are coming in right. For me this is a big step that's been a long time coming.
Once that problem is ironed out then I can look at adding additional legs and being able control them from the transmitter. I'll be doing this slowly, one leg at a time so I can make sure everything is working right first. I don't want unexpected movements out of a robot this big and powerful!
In the meantime I'm also wiring up the computer and aux power distribution. Just following a schematic at this point and a lot of crimping of ring terminals.
I am planning on going to Orrville, Ohio on August 30 for the get together there and I will bring the hexapod. Hopefully it will be able to do something interesting by that point! I don't expect walking but it would be nice to be able to individually control each leg from the transmitter and maybe program in some multi leg coordinated movement like raise and lower itself or spin in place.
It appears that the Unofficial Propeller Expo moved to the East Coast. See:
https://www.eventbrite.com/e/unofficial-propeller-expo-north-boston-tickets-11674261029
This is a two day event: Friday, August 8, 2014 at 7:00 PM - Saturday, August 9, 2014 at 3:00 PM (EDT) in Waltham, MA
Dennis
[video=youtube_share;oZNkmzNv3MA]
The video shows commanding the leg from the master via the PST and then at the end is controlling via a XBee transmitter. I still have a ways to go before the robot takes that first step but I'm getting closer all the time. I want to get the code working so that I can control all 3 motors simultaneously using the transmitter. Then I'll be ready to pull in a second leg to run both at the same time. I may try putting together some of the Inverse Kinematics routines with a simple gait control around 1 or 2 legs to see how that part works also. Don't think I'll have that ready for the end of Aug together.
Bob Sweeney
The initial idea I'm flowcharting is that there are no loops within the main motor routine for individual motors. Each motor movement is broken up into 4 phases, acceleration, steady state, deceleration and stopped. Variables would track the phase, current speed, current position, desired position for each motor. All motors will continue through the routine until all complete the specific movement. The key for this type of movement schema is to keep the individual movement distances as smaller, incremental values so you aren't stuck waiting for a long movement before another movement can be started.
I still have some thinking through and roughing out the flow path to see how well this will work. I am taking a break from working on the old software for a bit so I can come back and look at it with fresh eyes, maybe I'll see something different then. I'll have one leg capable of movement for the Aug. 30th show but I won't be as far along as I had hoped at that point. Maybe someone at the show can see the problem in the code!
Bob
If I recall correctly, each motor is controlled by its own HB-25. Is the main controller sending a single pulse or a stream of pulses to the HB-25?
LARGE capacitors are in order at each location, but I think that has been taken into consideration?
Is the main controller sending a single pulse or a stream of pulses to the HB-25s? Multiple simultaneous single pulses may be missed at the HP-25s. A stream of pulses can be measured at the HP-25s. The absence of pulses will confirm your software issue.
Just curious how much torque your coxa motors have. They move silently (no load) in your video and much faster than your other (weight-bearing) motors. How do you calculate how much torque is needed there? Is there a max goal load there, like climbing a 5% slope?
I'll have to devise some tests for this now.
Thanks for helping me start to think in a different direction!
Thanks for the kind words! I'm not as positive about progress, the first two years went more or less as planned but this was the year for software and I thought I'd be much further along than I am. The programming has turned out to be much more difficult than anticipated. I'm learning a lot and there is progress but at times it's painfully slow. It doesn't help that its summer here in Michigan with scuba and bike riding taking up time too. However it looks like a long winter coming so maybe I'll spend some more time on the project!
I measured the torque back when I found the Coxa motors but can't recall the value now but it was pretty significant at the rated voltage of 12v. I know that I can barely slow down the motor when I put a pair of pliers on the shaft and it's turning 190rpm! The fact that the motors were designed to move car seats with large people in them is what originally got me interested in testing them in the first place. Since the rpm is further slowed down to about 25rpm the torque increases about 7 times. I did grab a leg once while the Coxa was moving and it kept going and almost knocked the whole thing onto the floor! No more testing like that planned! I like to think the Coxa movement is quiet because of how well the reduction gear is designed! It does make noise but it just runs for a much shorter time than the other motors.
The other item is that the design of the system has the femur and tibia taking the majority of the load, the Coxa should normally be moving the body perpendicular to the force of gravity which should minimize the amount of torque needed. Once it's walking on its own I'll test and see how well it handles slopes but it will be flat, level ground at first!
Bob
Even though a motor/leg doesn't move it should still receive a pulse. My idea which I used to make my code was to constantly update every motor/servo non-stop. Even if it didn't move. You have a cog constantly looping feeding data to you motors. The Q4 feeds the values in a mian loop to alter the motor loop.
Can you post your code/codes. Since your using multiple props, post all of the files.
Here is a copy of the Transmitter, Reciever (master computer) and leg computer codes. Warning, the last person to look at the leg code complained his eyes were bleeding! So be careful! Anyway, see if anything jumps out, there is a lot of troubleshooting code in there to push data to a serial terminal which can make it hard to read. There is a seperate routine for each motor however all three are very similar in structure. Thanks for looking!
Bob
Hexapod IK Test 3c - Archive [Date 2014.08.15 Time 17.50].zip
Q4 Rx V3.61 - Archive [Date 2014.08.15 Time 17.52].zip
Q4 TX Code V3.61 - Archive [Date 2014.08.15 Time 17.51].zip