I used the same code in this large hexapod as I had used with my mini hexapod. Apparently the servos in the two different hexs have different range of motion with the same control pulses. The large hexapod's leg's bang together if I have it walks too quickly. It also does a sort of bucking bronco act part way into the video (I haven't watched it yet, I hope it looks cool).
I'll stop with the apologies before erco gets mad. Here's the first test walk.
The control board is a Propeller QuickStart board and the remote is a wireless Wii Nunchuck. Pretty cool IMO, even with its current warts.
Looking very slick there Duane...I like it....
.... I have been wanting to include bearings on some of my servo mechs for a while now ... so its good to see how your tackling it (better you than me ;-)
Regards G
With 356 days to go, I have the hex up and walking.
The video is uploading now but to give you an idea of the awesomeness of this robot, here are a few pictures.
One of the many parts of the program I still need to fix is the eye display code.
YouTube says the video just has another two minutes so come back soon for more hexapod goodness (but keep your expectations kind of low (it was a first test after all)).
What a great project. Did you end up using the MG996 servos? (I'm too lazy to scroll back). When you're buying 18 servos, value counts!
I think my main problem with these types of projects is the servo pots wearing out. Don't most joints rotate less than 90 degrees? That's a big load on the gears and pot over a small range of motion. True for humanoid walkers as well. I guess you just need to keep several spare servos on hand for those oops moments.
Seems like there's an opportunity to make a servo add-on kind of like the heavy-duty pan & tilts (see https://www.servocity.com/assets/images/SPG785_Power_Gearbox_with_text.jpg) which gear a servo down for higher torque. Put a pinion on a standard servo (which rotates 180 degrees usually) and gear down 2 or 3 times to a gear sector built into the attached pivoting limb. You'd gain torque and fine control plus extend servo life but you'd add complexity & weight.
Hmm. Probably a wash. Never mind! Forget we had this conversation. I'm also too lazy to go back and edit it down.
Right now the hex is kind of taken apart so I can fix the eyes. I had them in upside down and backwards.
This project is kind of on a back burner right now as I work on updating the Eddie code to use the Activity board for Ken. I'm pretty close to having my "Eddiefied Arlo Bot" ready to roll.
What a great project. Did you end up using the MG996 servos? (I'm too lazy to scroll back). When you're buying 18 servos, value counts!
No, I didn't use the MG996. I'm using the HobbyKing HXT12K servos. IMO, they're much better than the MG996R servos I purchased. I did hear from someone on Let's Make Robots, some servos marked Tower Pro MG996R have dual ball bearing. As I mentioned earlier, the MG996R servo I have use bushings rather than ball bearings.
As I mentioned in post #39, I'm using these little PCBs to make it easier to power the servos while connecting them to the Propeller.
While these aren't necessarily the best solution to adding servos to the Propeller, I think they work reasonably well. I thought I'd attach the gerber files in case anyone is interested in have a few made at OSH Park. A recent post fromTeam_Mantis made me think these could be useful to other robot builders.
These are the same files I submitted to OSH Park so they should work.
The hexapod has been really screaming for attention lately. I've felt bad I stopped working on this robot just as I was almost to the point of making it presentable.
I still have some work to do on it but I think it's coming along nicely.
The servos move the eyes to point towards the direction the robot is traveling. The "blinks" have a random pause and a random speed. There's a 10% chance a blink will be a double blink.
The eyes could display text if I find a reason to do so.
The LED arrays are from ICStation. I have several other LED arrays I've been playing with lately but these ICStation arrays seemed like the best size for this application.
I still need to find places to mount the switch and wireless Nunchuck receiver but I like how the robot is looking so far.
Very nicely done! The leg movements are good, didn't see any slipping as it was moving.
Thanks, I also like how the legs are moving. I had to reduce the stride length since the previous stride caused the legs to hit together. I'm using the same base code as the I used with my small hexapod but these larger servos don't appear to have the same pulse to angle relationship as the small servos.
I'm using using 1000us equals 90 degrees as my conversion between angles and pulses. I think this conversion factor is working well enough to look good but I don't think it's really precise.
In case any of you missed it, make sure and watch the video embedded in post #73.
I wanted to add tilt control to the robot. Right now the hexapod walks with the top of the hexapod level with the ground. I'd like the hexapod to be able hold any orientation as it walks.
Before adding tilt control, I wanted a way to adjust the tilt of the robot. Since I'm using a wireless Wii Nunchuck as the controller, I'm really limited to controlling two parameters of the robot at once. I'm already controlling the direction and rotation so in order to control the tilt, I'll need to swap either the direction control or the rotation control for tilt control.
The need to switch control modes got me thinking about a good strategy for doing this. I posted some of my thought in a blog at Let's Make Robots. Before I breakout my Quantum Robotics Q4 or my PlayStation 2 based robot remote, I want to see how well I can control the hexapod with a Wii Nunchuck.
I think I have the basic control swapping code figured out so it's time to make my brain strain as I modify the IK equations to include tilt.
DiverBob's recent post reminded me I was going to mention my efforts of reclaiming some of the code space used by the PASM sections of objects. I was able to move the PASM sections of both the servo object and the floating point object to the EEPROM. The PASM sections are copied from EEPROM and launched into their cogs one at a time. After all the PASM sections have been launched, the buffer used to hold these PASM sections is then reused as stack space for additional cogs running the Spin interpreter.
I'm not sure of the exact about of space freed up but I believe it was close to 1,000 longs. I plan to do something similar with the serial object but I need to modify the object to assigned areas of RAM for the TX and RX buffers.
Duane: That is such an AWESOME bot. Love those eyes, a great use if the pan/tilt mounts.
Can an autonomous figure 8 be far away?
And I won't request an aerosol flamethrower, but such a great spider robot could sure benefit from an onboard can of silly string to do some web-slingin'. Just sayin'.
Hopefully you'll recall I have had a hexapod perform a figure 8 and hopefully it won't sound too boastful if I say I could easily get this hexapod to travel in an autonomous figure 8. However, a figure 8 at this point wouldn't look much different from my earlier figure 8 and I'm waiting until I have better control over the hexapod before making another attempt.
I still don't have control over the tilt of the hexapod. I've like to add a few more features to make the next figure 8 a bit more interesting.
I'm posting my convoluted code. The code I'm posting was used when I made the last YouTube video. I know it's an absolute mess but I didn't want to delay letting DiverBob see the code if he thinks it might be useful.
This version of the code doesn't include the changes I made which moved the PASM section of several objects to upper EEPROM.
While normally if I post code, I leave it up, I will warn people this code is here temporarily and I plan to remove this code once I move my current working code to my GitHub account. If anyone wants to see how messy Spin code can become, you won't want to miss the opportunity to download this code.
As I've mentioned, I've made several changes (and I think improvements) to the way the Nunchuck input is used. The changes/improvements are not included in this upload since I haven't tested the recent changes very thoroughly. Once I get these changes tested, I'll move the code to my GitHub account.
Edit(3/8/15): The code I had posted here was just too embarrassing to leave up.
And I won't request an aerosol flamethrower, but such a great spider robot could sure benefit from an onboard can of silly string to do some web-slingin'. Just sayin'.
While I can feel a flamethrower is in my future, I doubt I'll be adding one to this bot. I'll have to give the web-slinging idea some thought. I'm afraid web slinging might turn out to look like the robot is performing some other biological function rather than spinning a web. Plus this robot has six legs. If I'm going to have a robot spider, it's going to have full set of eight legs.
That's a nice hexapod Duane, I really like the blinking eyes.
Have you looked at doing those equations in fixed instead of floating point, and simplifying them by looking for common sub-equations and such? Going from floating to fixed point can reduce calculation time by a factor of 10 to 20, and calculating common sub equations once and using the result can also make a big difference.
I generally avoid floating point math but when I have a bunch of trig calculations I use floating point math. I know there's code which performs trig calculation using integer math but I haven't used it. I probably should and compare the speed between using F32 vs the integer trig.
I do make use of "sub equations". I avoid performing the same calculation multiple times where possible.
Having the legs positioned 60 degrees from each other makes the math more involved than if I had kept the three legs on each side pointed at the same angle but I think the hexapod looks better with it's legs pointed 60 degrees from each other.
I still think I'll be able to get the hexapod to move the way I want, it's just taking me longer to write the code than I had thought it would.
Really Great! project You got to like those eyes. It maneuvers quite well.
Thanks Bob. It's often surprising how sometimes small and simple additions to a robot make a huge impression on spectators. This robot has been a hit wherever I show it. People especially like the eyes.
I'm guessing that the bottleneck is your presumed reliance on floating-point when properly-scaled integer computations would do the job just as well -- and a lot faster. In the course I'm teaching, I won't let my students even close to F32 or its ilk. It's totally unnecessary.
I've learned a lot from both kwinn and Phil and I'm always very hesitant not to agree with them. This is one time I do disagree. I think F32 is extremely necessary useful for this hexapod project. I just ran some time tests between Kye's integer trig object "SL32_INTEngine_2" and "F32." F32 came out the winner with the trig functions.
Possibly just as important as the speed advantage is the huge increase in precision F32 offers over the integer trig object I tested. While it's easy to scale distances to increase the accuracy of integer calculations, I'm not aware of a way of scaling angles to increase the precision of integer trig calculations.
I plan to proceed using F32 but if someone has a suggestion of an alternate integer trig object I should try, I hope they let me know about it.
So far I haven't found a way to do these calculations with integers any faster than using floating point calculations with F32.
I mentioned elsewhere on the forum (and maybe in this thread) my use of a wireless Wii Nunchuck as the controller for this robot. Most generic game controllers I've used have been a big disappointment. Some joysticks are far from linear in their feedback and I've also found controllers which use lower precision ADC for the joystick and then scale the low precision value so the range matches the original controller. The PlayStation 2 controller SparkFun used to sell had 5-bit precision on their joysticks rather than 8-bit precision.
My experience with generic game controllers caused to me to have low expectations when I purchased a wireless Nunchuck from Amazon. I was very pleasantly surprised to find the Nunchuck appeared to work as well as a Wii original.
The wireless Nunchuck comes with its own receiver. This can present a challenge when connecting the receiver with a microcontroller since you no longer have the option of cutting the wire and using the wires directly. To use the wireless Nunchuck, you need some sort of adapter to plug into the receiver.
I added pads for pull-up resistors incase they were needed.
I suppose I shouldn't call it "my own design." It's obviously a copy of the one I purchased from SparkFun. My version doesn't fit as well as the SparkFun (ThingM) version. I made the PCB a little too narrow.
It works, but it doesn't stay nice and straight like the original.
I have two of the Nyko wireless Nunchucks and I think they work great.
I'm using JonnyMac's object to read the Nunchuck. I couldn't find Jon's object in the OBEX but here's a link to a forum post with the code attached. Jon's object uses a Spin I2C object so it doesn't read from the Nunchuck really fast but I think it's plenty fast for what I'm doing.
Today I saw a working robotic hexapod for the very first time - this one https://www.youtube.com/watch?feature=player_embedded&v=f520FM9Z9is -
and afterwards a few others, all moving amazingly smooth and stable. This thread shows it is quite a big project to actually make one!
I guess the same design could be used on a larger scale, a 'hexpodchair' as a replacement of an electric wheelchair in case you can't walk yourself but still want to cross the dunes, the beach, ...
I'm sure you must have given it a thought. I have been thinking about robots for this purpose with two or four legs before (while working on improvements for my little brothers wheelchair, car, ...) but never thought of a hexapod. Nowadays, with light and strong enough batteries, it might be possible to make a bigger one which may carry a small person?
I'm hoping to find time to work on the Halloween Hex but as of right now, it doesn't work.
I have been helping someone in Canada with a Mouse Droid robot.
The Mouse Droid is the first bot I'm worked which uses Ackermann steering. I hope to post some photos of the robot's guts (the part I'm working on) sometime soon.
Comments
I'll stop with the apologies before erco gets mad. Here's the first test walk.
The control board is a Propeller QuickStart board and the remote is a wireless Wii Nunchuck. Pretty cool IMO, even with its current warts.
You do good work Duane!
I have this image in my head that is sticking there.
A Red Hat, White beard, Santa's Helper Hex.
gg
A beautiful start, Duane, and well worth the wait! A very complex project. 18 servos? Yikes!
BTW, I don't get mad. I get even...
.... I have been wanting to include bearings on some of my servo mechs for a while now ... so its good to see how your tackling it (better you than me ;-)
Regards G
And more when he gets around to articulating those eyes.
Indeed, a great project!
Well done Duane!
I think my main problem with these types of projects is the servo pots wearing out. Don't most joints rotate less than 90 degrees? That's a big load on the gears and pot over a small range of motion. True for humanoid walkers as well. I guess you just need to keep several spare servos on hand for those oops moments.
Seems like there's an opportunity to make a servo add-on kind of like the heavy-duty pan & tilts (see https://www.servocity.com/assets/images/SPG785_Power_Gearbox_with_text.jpg) which gear a servo down for higher torque. Put a pinion on a standard servo (which rotates 180 degrees usually) and gear down 2 or 3 times to a gear sector built into the attached pivoting limb. You'd gain torque and fine control plus extend servo life but you'd add complexity & weight.
Hmm. Probably a wash. Never mind! Forget we had this conversation. I'm also too lazy to go back and edit it down.
https://www.servocity.com/html/spg785a_top_mount.html#.VGaAwDwtBIc
Right now the hex is kind of taken apart so I can fix the eyes. I had them in upside down and backwards.
This project is kind of on a back burner right now as I work on updating the Eddie code to use the Activity board for Ken. I'm pretty close to having my "Eddiefied Arlo Bot" ready to roll.
No, I didn't use the MG996. I'm using the HobbyKing HXT12K servos. IMO, they're much better than the MG996R servos I purchased. I did hear from someone on Let's Make Robots, some servos marked Tower Pro MG996R have dual ball bearing. As I mentioned earlier, the MG996R servo I have use bushings rather than ball bearings.
While these aren't necessarily the best solution to adding servos to the Propeller, I think they work reasonably well. I thought I'd attach the gerber files in case anyone is interested in have a few made at OSH Park. A recent post fromTeam_Mantis made me think these could be useful to other robot builders.
These are the same files I submitted to OSH Park so they should work.
I still have some work to do on it but I think it's coming along nicely.
The servos move the eyes to point towards the direction the robot is traveling. The "blinks" have a random pause and a random speed. There's a 10% chance a blink will be a double blink.
The eyes could display text if I find a reason to do so.
The LED arrays are from ICStation. I have several other LED arrays I've been playing with lately but these ICStation arrays seemed like the best size for this application.
I still need to find places to mount the switch and wireless Nunchuck receiver but I like how the robot is looking so far.
Thanks, I also like how the legs are moving. I had to reduce the stride length since the previous stride caused the legs to hit together. I'm using the same base code as the I used with my small hexapod but these larger servos don't appear to have the same pulse to angle relationship as the small servos.
I'm using using 1000us equals 90 degrees as my conversion between angles and pulses. I think this conversion factor is working well enough to look good but I don't think it's really precise.
I wanted to add tilt control to the robot. Right now the hexapod walks with the top of the hexapod level with the ground. I'd like the hexapod to be able hold any orientation as it walks.
Before adding tilt control, I wanted a way to adjust the tilt of the robot. Since I'm using a wireless Wii Nunchuck as the controller, I'm really limited to controlling two parameters of the robot at once. I'm already controlling the direction and rotation so in order to control the tilt, I'll need to swap either the direction control or the rotation control for tilt control.
The need to switch control modes got me thinking about a good strategy for doing this. I posted some of my thought in a blog at Let's Make Robots. Before I breakout my Quantum Robotics Q4 or my PlayStation 2 based robot remote, I want to see how well I can control the hexapod with a Wii Nunchuck.
I think I have the basic control swapping code figured out so it's time to make my brain strain as I modify the IK equations to include tilt.
I'm not sure of the exact about of space freed up but I believe it was close to 1,000 longs. I plan to do something similar with the serial object but I need to modify the object to assigned areas of RAM for the TX and RX buffers.
Can an autonomous figure 8 be far away?
And I won't request an aerosol flamethrower, but such a great spider robot could sure benefit from an onboard can of silly string to do some web-slingin'. Just sayin'.
Hopefully you'll recall I have had a hexapod perform a figure 8 and hopefully it won't sound too boastful if I say I could easily get this hexapod to travel in an autonomous figure 8. However, a figure 8 at this point wouldn't look much different from my earlier figure 8 and I'm waiting until I have better control over the hexapod before making another attempt.
I still don't have control over the tilt of the hexapod. I've like to add a few more features to make the next figure 8 a bit more interesting.
I'm posting my convoluted code. The code I'm posting was used when I made the last YouTube video. I know it's an absolute mess but I didn't want to delay letting DiverBob see the code if he thinks it might be useful.
This version of the code doesn't include the changes I made which moved the PASM section of several objects to upper EEPROM.
While normally if I post code, I leave it up, I will warn people this code is here temporarily and I plan to remove this code once I move my current working code to my GitHub account. If anyone wants to see how messy Spin code can become, you won't want to miss the opportunity to download this code.
As I've mentioned, I've made several changes (and I think improvements) to the way the Nunchuck input is used. The changes/improvements are not included in this upload since I haven't tested the recent changes very thoroughly. Once I get these changes tested, I'll move the code to my GitHub account.
Edit(3/8/15): The code I had posted here was just too embarrassing to leave up.
While I can feel a flamethrower is in my future, I doubt I'll be adding one to this bot. I'll have to give the web-slinging idea some thought. I'm afraid web slinging might turn out to look like the robot is performing some other biological function rather than spinning a web. Plus this robot has six legs. If I'm going to have a robot spider, it's going to have full set of eight legs.
I generally avoid floating point math but when I have a bunch of trig calculations I use floating point math. I know there's code which performs trig calculation using integer math but I haven't used it. I probably should and compare the speed between using F32 vs the integer trig.
I do make use of "sub equations". I avoid performing the same calculation multiple times where possible.
Having the legs positioned 60 degrees from each other makes the math more involved than if I had kept the three legs on each side pointed at the same angle but I think the hexapod looks better with it's legs pointed 60 degrees from each other.
I still think I'll be able to get the hexapod to move the way I want, it's just taking me longer to write the code than I had thought it would.
Really Great! project You got to like those eyes. It maneuvers quite well.
Thanks Bob. It's often surprising how sometimes small and simple additions to a robot make a huge impression on spectators. This robot has been a hit wherever I show it. People especially like the eyes.
Here's Phil's comment:
I've learned a lot from both kwinn and Phil and I'm always very hesitant not to agree with them. This is one time I do disagree. I think F32 is extremely necessary useful for this hexapod project. I just ran some time tests between Kye's integer trig object "SL32_INTEngine_2" and "F32." F32 came out the winner with the trig functions.
Possibly just as important as the speed advantage is the huge increase in precision F32 offers over the integer trig object I tested. While it's easy to scale distances to increase the accuracy of integer calculations, I'm not aware of a way of scaling angles to increase the precision of integer trig calculations.
I plan to proceed using F32 but if someone has a suggestion of an alternate integer trig object I should try, I hope they let me know about it.
So far I haven't found a way to do these calculations with integers any faster than using floating point calculations with F32.
I mentioned elsewhere on the forum (and maybe in this thread) my use of a wireless Wii Nunchuck as the controller for this robot. Most generic game controllers I've used have been a big disappointment. Some joysticks are far from linear in their feedback and I've also found controllers which use lower precision ADC for the joystick and then scale the low precision value so the range matches the original controller. The PlayStation 2 controller SparkFun used to sell had 5-bit precision on their joysticks rather than 8-bit precision.
My experience with generic game controllers caused to me to have low expectations when I purchased a wireless Nunchuck from Amazon. I was very pleasantly surprised to find the Nunchuck appeared to work as well as a Wii original.
The wireless Nunchuck comes with its own receiver. This can present a challenge when connecting the receiver with a microcontroller since you no longer have the option of cutting the wire and using the wires directly. To use the wireless Nunchuck, you need some sort of adapter to plug into the receiver.
This adapter from SparkFun works well.
I made my own design with DipTrace.
I added pads for pull-up resistors incase they were needed.
I suppose I shouldn't call it "my own design." It's obviously a copy of the one I purchased from SparkFun. My version doesn't fit as well as the SparkFun (ThingM) version. I made the PCB a little too narrow.
It works, but it doesn't stay nice and straight like the original.
I have two of the Nyko wireless Nunchucks and I think they work great.
I'm using JonnyMac's object to read the Nunchuck. I couldn't find Jon's object in the OBEX but here's a link to a forum post with the code attached. Jon's object uses a Spin I2C object so it doesn't read from the Nunchuck really fast but I think it's plenty fast for what I'm doing.
Today I saw a working robotic hexapod for the very first time - this one
https://www.youtube.com/watch?feature=player_embedded&v=f520FM9Z9is -
and afterwards a few others, all moving amazingly smooth and stable. This thread shows it is quite a big project to actually make one!
I guess the same design could be used on a larger scale, a 'hexpodchair' as a replacement of an electric wheelchair in case you can't walk yourself but still want to cross the dunes, the beach, ...
I'm sure you must have given it a thought. I have been thinking about robots for this purpose with two or four legs before (while working on improvements for my little brothers wheelchair, car, ...) but never thought of a hexapod. Nowadays, with light and strong enough batteries, it might be possible to make a bigger one which may carry a small person?
I have been helping someone in Canada with a Mouse Droid robot.
The Mouse Droid is the first bot I'm worked which uses Ackermann steering. I hope to post some photos of the robot's guts (the part I'm working on) sometime soon.