In post #12 of my index I have a section called "Robot Controllers". There are several remotes listed which use XBees.
My favorite is Paul's remote (a successful Kickstarter campaign).
Besides XBees, I also like to use Nordic nRF24L01+ modules for remotes since they're so inexpensive (there are several nRF24L01+ items in post #1 of my index). XBees are much easier to use than the nRF24L01+ modules.
Duane, I looked at the link you provided, and perhaps using the XBee is way too much for me at present. I didn't think it would be that difficult to get up and running, but now I am not sure. But I have a unit in the event I decide to implement it. If you can think of some possible ways I could use it, please post them. Thanks.
EDIT: Can you suggest some possible uses of XBee (or Nordic) modules in a rover such as I have in mind? Thanks.
I got a set of the Parallax XBees from RS... full price. Anyway these are low power modules so only useful for shorter ranges. You'd need the higher power modules for remote control or telemetry.
IMHO you'd be infinitely better off using a real RC remote control and some kind of RC Multiplexer to allow you to take control. That's what I've been doing with Data Bus for the last couple years. Works great. RC remotes have good range and reliability. I use a 3CH FlySky GT3B (cheap but very good). A dedicated Mux board/MCU means if your main MCU hangs, crashes, etc., you can still take control of your robot.
Coincidentally I sell a 3CH Rover RC Mux on Tindie Its the design I'll be using on Data Bus for the 2014 Sparkfun AVC.
I got a set of the Parallax XBees from RS... full price. Anyway these are low power modules so only useful for shorter ranges. You'd need the higher power modules for remote control or telemetry.
IMHO you'd be infinitely better off using a real RC remote control and some kind of RC Multiplexer to allow you to take control. That's what I've been doing with Data Bus for the last couple years. Works great. RC remotes have good range and reliability. I use a 3CH FlySky GT3B (cheap but very good). A dedicated Mux board/MCU means if your main MCU hangs, crashes, etc., you can still take control of your robot.
Coincidentally I sell a 3CH Rover RC Mux on Tindie Its the design I'll be using on Data Bus for the 2014 Sparkfun AVC.
Thanks for the info. I may still use the XBee in some manner, perhaps on a future project if I can not find a need for it on the present design. But it sure sounds like I need to try out your MUX. I have looked at your site and the price is right. Now I need to educate myself on RC... can you point me to some of your projects with RC, your MUX, and the Propeller so I can get some ideas? That would be great if you can.
EDIT: I found your Bots Thoughts code postings and the Main.C code is pretty intense. I could use a Propeller cog to deal with the RC MUX tasks and would have lots of capability remaining. I will continue to check out the RC and MUX aspects for potential use in my rover. Man, like Duane said, lots to learn!
Duane, I looked at the link you provided, and perhaps using the XBee is way too much for me at present. I didn't think it would be that difficult to get up and running, but now I am not sure. But I have a unit in the event I decide to implement it. If you can think of some possible ways I could use it, please post them. Thanks.
EDIT: Duane, can you suggest some possible uses of XBee (or Nordic) modules in a rover such as I have in mind? Thanks.
I could use a Propeller cog to deal with the RC MUX tasks and would have lots of capability remaining.
This is pretty easy for the Propeller. You'd just check the timing of how frequently new pulses were received and if the pulses didn't arrive within a set time limit, you'd have the Propeller take over control.
In a relatively recent thread started by NWCCTV, I posted a link to my version of a 6-channel RC receiver code. There is also a link to the code in post #2 of my index. In the thread started by NWCCTV, someone posted code to use a RC receiver to control two CR servos. This code should also work with motor controllers you're using on the WT. What the example doesn't have is a time limit to trigger autonomous control. If you want to go this route, let me know. A time limit would be pretty easy to add.
I've been impressed by several RC setups I've used. I've flown airplanes 1/4 mile away. Usually you lose sight of an airplane before it flies out of range. I doubt you'll get nearly the same range with a robot underground as one gets with an airplane in the sky.
While I use RC gear (I'm using the term "RC gear" to describe radio control equipment commonly used to control airplanes and helicopters) with several of my robots, I really like using two way radios so I can receive telemetry back from the robot. (I think there are some RC systems that now have telemetry.) The ability to receive telemetry give me reason to prefer Nordic and XBee type transceivers over RC gear. The main reasons I often use the RC gear with my robots are I already have the gear, it's pretty easy to use with the Propeller and the transmitters come with ready to use (and ergonomic) joysticks and switches.
I think the RC gear has better range than most XBee modules and pretty much all the Nordic modules. There are a few XBee radios which (I believe) have comparable range to RC gear.
EDIT: Duane, can you suggest some possible uses of XBee (or Nordic) modules in a rover such as I have in mind? Thanks.
I have limited experience in this regard. I've used these Xbee 900 Pro XSC modules. I left one in at home and started walking down the street with the other. It had a good signal as I walked a block away. At the end of the block I turn the corner and the line of houses between the XBees completely blocked the signal. These XTend radios look like they have even better range than the XSC modules. Apparently the range with both these types of radios is improved with directional antennas.
I don't know how these would work underground.
One option I really want to try sometime is to make a network of wireless modules and have the messages hop from one transceiver to the next. This would require a pretty smart robot(s) if you used the robot to deploy the network. I want to make a bunch of wireless nodes with inexpensive Nordic modules (there's a link in post #1 of my index to inexpensive modules). Each module could be enclosed in something like a plastic Easter egg. The robot would drop one of these modules every few hundred feet as it traveled down a pipe. The messages would then hop from one node to the next as they made their way down the pipe and back.
It would be nice if the nodes could be inexpensive so if the robot wasn't able to retrieve a couple, it wouldn't be a big loss. I've used an AVR ATtiny (which are pretty inexpensive) to interface with Nordic modules, but I don't know if I'd be able to program in all the message hopping algorithms in an ATtiny. I have programmed multiple Propellers to use message hopping. It would be nice if I could find a lower cost microcontroller than the Propeller to use in the wireless nodes but it may be easier just to use the Propeller since I'm more familiar with programming it than other microcontrollers.
I'm pretty sure Gareth (a smart guy with lots of very cool projects) was working on a project using a bunch of Nordic modules. I'm not sure what he is planning on doing with the many transceivers.
Getting a robot to leave a trail of transceiver nodes is far from a simple task but it's one of those things I'd really like to try sometime.
This is pretty easy for the Propeller. You'd just check the timing of how frequently new pulses were received and if the pulses didn't arrive within a set time limit, you'd have the Propeller take over control.
In a relatively recent thread started by NWCCTV, I posted a link to my version of a 6-channel RC receiver code. There is also a link to the code in post #2 of my index. In the thread started by NWCCTV, someone posted code to use a RC receiver to control two CR servos. This code should also work with motor controllers you're using on the WT. What the example doesn't have is a time limit to trigger autonomous control. If you want to go this route, let me know. A time limit would be pretty easy to add.
I've been impressed by several RC setups I've used. I've flown airplanes 1/4 mile away. Usually you lose sight of an airplane before it flies out of range. I doubt you'll get nearly the same range with a robot underground as one gets with an airplane in the sky.
While I use RC gear (I'm using the term "RC gear" to describe radio control equipment commonly used to control airplanes and helicopters) with several of my robots, I really like using two way radios so I can receive telemetry back from the robot. (I think there are some RC systems that now have telemetry.) The ability to receive telemetry give me reason to prefer Nordic and XBee type transceivers over RC gear. The main reasons I often use the RC gear with my robots are I already have the gear, it's pretty easy to use with the Propeller and the transmitters come with ready to use (and ergonomic) joysticks and switches.
I think the RC gear has better range than most XBee modules and pretty much all the Nordic modules. There are a few XBee radios which (I believe) have comparable range to RC gear.
I have limited experience in this regard. I've used these Xbee 900 Pro XSC modules. I left one in at home and started walking down the street with the other. It had a good signal as I walked a block away. At the end of the block I turn the corner and the line of houses between the XBees completely blocked the signal. These XTend radios look like they have even better range than the XSC modules. Apparently the range with both these types of radios is improved with directional antennas.
I don't know how these would work underground.
One option I really want to try sometime is to make a network of wireless modules and have the messages hop from one transceiver to the next. This would require a pretty smart robot(s) if you used the robot to deploy the network. I want to make a bunch of wireless nodes with inexpensive Nordic modules (there's a link in post #1 of my index to inexpensive modules). Each module could be enclosed in something like a plastic Easter egg. The robot would drop one of these modules every few hundred feet as it traveled down a pipe. The messages would then hop from one node to the next as they made their way down the pipe and back.
It would be nice if the nodes could be inexpensive so if the robot wasn't able to retrieve a couple, it wouldn't be a big loss. I've used an AVR ATtiny (which are pretty inexpensive) to interface with Nordic modules, but I don't know if I'd be able to program in all the message hopping algorithms in an ATtiny. I have programmed multiple Propellers to use message hopping. It would be nice if I could find a lower cost microcontroller than the Propeller to use in the wireless nodes but it may be easier just to use the Propeller since I'm more familiar with programming it than other microcontrollers.
I'm pretty sure Gareth (a smart guy with lots of very cool projects) was working on a project using a bunch of Nordic modules. I'm not sure what he is planning on doing with the many transceivers.
Getting a robot to leave a trail of transceiver nodes is far from a simple task but it's one of those things I'd really like to try sometime.
Thank you for a detailed and informative post, Duane. I am wanting to see if I can work into my design the use of RC gear much as you have described. I need to keep reading up on this and your receiver code is a great resource.
As a Project Update, I really hope to finally be able to purchase a Wild Thumper Robotics Kit soon. It really looks to be the absolute best available choice for a mobile platform for my planned rover. With the HB-25 motor controllers, the on-board Propeller Project Board, and the six brushed DC motors, this is the best value for the money that I have found. My plan is to eventually build a proof-of-concept device that will do everything I want to do, then either replicate it (essentially make clones), or construct a rover from scratch that uses the same overall layout and functionality.
I had hoped to be able to purchase a Wild Thumper kit by now, but stuff happens and it will be a little later until I can do that. But the dreaming and planning continues...
I have two NiMH battery packs that I found on sale at Radio Shack, rated 7.2v/3000mAh. Is it possible that I can get by with using one pack for locomotion and one pack for sensors/mini video camera? I know it all depends on the demand and many variables, but could one pack allow the Thumper to operate for say 30 minutes off and on? Or is this just way too much to expect from this battery capacity?
I got a set of the Parallax XBees from RS... full price. Anyway these are low power modules so only useful for shorter ranges. You'd need the higher power modules for remote control or telemetry.
IMHO you'd be infinitely better off using a real RC remote control and some kind of RC Multiplexer to allow you to take control. That's what I've been doing with Data Bus for the last couple years. Works great. RC remotes have good range and reliability. I use a 3CH FlySky GT3B (cheap but very good). A dedicated Mux board/MCU means if your main MCU hangs, crashes, etc., you can still take control of your robot.
Coincidentally I sell a 3CH Rover RC Mux on Tindie Its the design I'll be using on Data Bus for the 2014 Sparkfun AVC.
I see that your R/C MUX is down to 4 units. Will this be available at a later time, should they sell out before I can purchase one?
Also, could you please indicate a specific R/C TX-RX system that I may consider using with my Propeller-based rover? Many thanks!
I see that your R/C MUX is down to 4 units. Will this be available at a later time, should they sell out before I can purchase one?
Also, could you please indicate a specific R/C TX-RX system that I may consider using with my Propeller-based rover? Many thanks!
I personally won't bother with an external mux. It would mainly be there in case the Propeller crashes (which can happen). I don't think it's essential to start with a mux. You can see how things go without one and decide later if you need one or not.
It just seems like there are other more pressing needs than the $12 mux. (Not that I think it's a bad deal or not a good device to have.)
As long as your code is stable (which can be a big if) the Propeller can take care of deciding who is in control of the robot.
I personally won't bother with an external mux. It would mainly be there in case the Propeller crashes (which can happen). I don't think it's essential to start with a mux. You can see how things go without one and decide later if you need one or not.
It just seems like there are other more pressing needs than the $12 mux. (Not that I think it's a bad deal or not a good device to have.)
As long as your code is stable (which can be a big if) the Propeller can take care of deciding who is in control of the robot.
Duane,
Indeed, I have many other pressing considerations with my rover design. And I can always add this at a later time if I think it is important. I was thinking that having RC available would be nice to steer the rover where desired, when autonomous control was not the best option. It may also provide for a nice way to walk a rover out of a situation should it become caught so to speak.
I am going to look over your personal projects again for ideas. Thanks for the comment.
I see that your R/C MUX is down to 4 units. Will this be available at a later time, should they sell out before I can purchase one?
Also, could you please indicate a specific R/C TX-RX system that I may consider using with my Propeller-based rover? Many thanks!
I do plan to make another batch when these sell out. Also they're on sale for $9 on Cyber Monday so wait until then.
As for a specific RC radio system, I've set up the firmware with wide timing tolerances so a very wide variety of standard RC systems should work. The tolerances can always be widened and the firmware updated by using an AVR programmer or an Arduino as ISP. I'm using the FlySky FS-GT3B and it's been tested with a few other radio systems.
RIght now I have the period set to between 20 - 200Hz (typically 50Hz) and on time of 3ms-30ms (typically 0.5ms-2.0ms)
I personally won't bother with an external mux. It would mainly be there in case the Propeller crashes (which can happen). I don't think it's essential to start with a mux. You can see how things go without one and decide later if you need one or not.
It just seems like there are other more pressing needs than the $12 mux. (Not that I think it's a bad deal or not a good device to have.)
As long as your code is stable (which can be a big if) the Propeller can take care of deciding who is in control of the robot.
Good points. Keep your speeds low enough and have a kill switch if you're worried about the robot crashing into curbs or people. If you go faster than a walk, some kind of RC mux capability is nice to have.
When I built Data Bus I wanted something external and highly reliable as I had planned to go fast (the robot does 20mph on the straights). Even starting out at a walking pace of 5mph I was glad to have the mux to take over the robot. Was it essential? No, I could've run after the bot easily enough. I was glad to have it as I ran the robot faster and across longer distances, though, which happened later in development.
Also of note, I didn't trust the rest of my code -- I was writing on a single core ARM MCU with complex interrupts and code running. I didn't trust all that to reliably multiplex; all it'd take is me goofing up an ISR or some such to hang the MCU and render the robot out of control. And believe me I've hung the MCU more than a few times.
Propeller is a different ball game. You don't have interrupt handlers that can hang, you can run multiple cogs dedicated to tasks. So you can save the money and simply dedicate a cog to the RC mux duties and call it good. The main advantage of an external mux in this case is you save a cog. Take a look at my source for ideas on how to detect the signal.
Propeller is a different ball game. You don't have interrupt handlers that can hang, you can run multiple cogs dedicated to tasks. So you can save the money and simply dedicate a cog to the RC mux duties and call it good. The main advantage of an external mux in this case is you save a cog. Take a look at my source for ideas on how to detect the signal.
But it's still possible to throw a wrench into a Prop's inner workings. I've lost count of how many times I've written to address zero of hub RAM instead of the intended location. If you mess up the clock setting (by writing to low RAM addresses) it will interfere with all the cogs. I like the idea of an external MUX, but I'm not sure if it should be a really high priority to start with if funds are short.
But it's still possible to throw a wrench into a Prop's inner workings. I've lost count of how many times I've written to address zero of hub RAM instead of the intended location. If you mess up the clock setting (by writing to low RAM addresses) it will interfere with all the cogs. I like the idea of an external MUX, but I'm not sure if it should be a really high priority to start with if funds are short.
Yes, definitely. Agreed. Didn't mean to suggest otherwise. I didn't really finish reading the thread when I replied. Sorry 'bout that.
If it helps, I did my first mux super cheaply using a home etched board with (mostly) salvaged analog parts and other parts I already had in my stash. http://www.bot-thoughts.com/2011/03/avc-bot-kill-switch.html This could just as easily be done on perfboard or protoboard or whatnot. Anyway... hopefully this will be helpful to others. Back to the regular discussion
I do plan to make another batch when these sell out. Also they're on sale for $9 on Cyber Monday so wait until then.
As for a specific RC radio system, I've set up the firmware with wide timing tolerances so a very wide variety of standard RC systems should work. The tolerances can always be widened and the firmware updated by using an AVR programmer or an Arduino as ISP. I'm using the FlySky FS-GT3B and it's been tested with a few other radio systems.
RIght now I have the period set to between 20 - 200Hz (typically 50Hz) and on time of 3ms-30ms (typically 0.5ms-2.0ms)
I have your site bookmarked and am trying to learn from some of your posts and project offerings. I have also looked at your code and find it to be well done and documented. I am learning C language, trying to understand motor control and all those algorithms, etc. You, Duane, and all the others have proven to me that I have a long way to go. Thanks for the RC recs.
Good points. Keep your speeds low enough and have a kill switch if you're worried about the robot crashing into curbs or people. If you go faster than a walk, some kind of RC mux capability is nice to have.
When I built Data Bus I wanted something external and highly reliable as I had planned to go fast (the robot does 20mph on the straights). Even starting out at a walking pace of 5mph I was glad to have the mux to take over the robot. Was it essential? No, I could've run after the bot easily enough. I was glad to have it as I ran the robot faster and across longer distances, though, which happened later in development.
Also of note, I didn't trust the rest of my code -- I was writing on a single core ARM MCU with complex interrupts and code running. I didn't trust all that to reliably multiplex; all it'd take is me goofing up an ISR or some such to hang the MCU and render the robot out of control. And believe me I've hung the MCU more than a few times.
Propeller is a different ball game. You don't have interrupt handlers that can hang, you can run multiple cogs dedicated to tasks. So you can save the money and simply dedicate a cog to the RC mux duties and call it good. The main advantage of an external mux in this case is you save a cog. Take a look at my source for ideas on how to detect the signal.
My rover will be used more often than not to navigate fairly easily accessible drainage pipes and culverts. However, part of the duties of the rover will be to traverse very steep sloping terrain, although at slow speeds. A RC system could prove to be useful on such areas, keeping me from having to climb up after it more than I want. It will certainly be a consideration for me after I obtain the chassis and begin working on my rover. And thanks for the heads-up on the sale.
The TREKKER mobile platform featured by Beatty Robotics at http://beatty-robotics.com/all-terrain-gps-robot/ is pretty much what I had been envisioning in my mind for my own rover, except I want to add a wireless camera. The Trekker is built on a Wild Thumper platform, as mine will be.
I am unsure whether to program in C or in Spin/Assembler. I used to code in Assembly on many devices, and with Spin I see that there are lots of great offerings in the Object Exchange. But there are only a few examples for C in OBEX, which makes it much harder for me to develop code. I have programmed with other high level languages, and I am sure I can learn to do so with C, especially with the great tutorials here. But with the Spin objects available, and with the power of the 8 cogs of the Propeller, it may make sense for me to try Spin first. Will this be feasible (sufficiently fast enough) to run the HB-25's, a PING or two, a Parallax GPS, an XBee, and perhaps a few other systems without too much loss in speed or accuracy? I figure it should be sufficient, as the Trekker operates with an Arduino (single core device), and the Propeller has 8 cogs. Comments are certainly invited and welcomed.
I think that right now, if you use SPIN you will have the fastest route to a working prototype. The reason I say that is because the majority of existing Propeller code is in SPIN/PASM. The Propeller can easily handle the hardware you mentioned. I think that with your previous experience SPIN will be fun and easy for you.
Another way to figure it out is to work in both environments. For instance I used SPIN and C to perform one simple task. By doing small individual projects I could instantly tell that I will continue to use SPIN and would much rather start learning PASM than C. I think the support for C is great but I don't think it is better or worse than SPIN, especially for a not-too-complex robot.
I think that right now, if you use SPIN you will have the fastest route to a working prototype. The reason I say that is because the majority of existing Propeller code is in SPIN/PASM. The Propeller can easily handle the hardware you mentioned. I think that with your previous experience SPIN will be fun and easy for you.
Another way to figure it out is to work in both environments. For instance I used SPIN and C to perform one simple task. By doing small individual projects I could instantly tell that I will continue to use SPIN and would much rather start learning PASM than C. I think the support for C is great but I don't think it is better or worse than SPIN, especially for a not-too-complex robot.
Thanks for the reply. I think I may just proceed with SPIN at this time, letting the wealth of knowledge within the OBEX help me without recreating the wheel so to speak. Once I feel comfortable with what I am doing, then it may be time to try my hand at C. I am still working on the C tutorials with my Propeller Activity Board and what I learn from that will be helpful in my "porting over" my code to C in the future.
There's a LOT to be said for building on the work of others. I'd go SPIN for the reasons you mention. Much easier to get started when there are many objects and code examples to work with. Not saying it's plug and play but it's better than staring at an empty editor window with not many ideas where to start
I am reading through the Information and Assembly Guide documentation for the Wild Thumper Robot Kit and I see that it states that any I/O pins can be selected to power the motors from the Propeller Project Board. Are there any particular I/O pins that would be better to use for this, or does it really even matter? Thanks for any feedback.
They're talking about the signal wire to the HB-25. I'd go with what they recommend until you find a reason not to. Using Pins 0 and 1 make sense because there is nothing else connected and the pins are side by side to keep things neat. The motor controllers are also going to be a higher priority than most other IO pins, so knowing that they're the lowest pins make it easy for you to remember they're the lowest pins.
Unless you're building a sigma-delta ADC there might be some pins you'd want to use but other than that I think it will come down to personal preference and aesthetics. It's easy enough to change later, so it's important in your physical connections you not do anything too permanent. Using headers are great for this, you change the code and jumpers and be completely reconfigured in minutes. Just keep in mind that can happen for anything while you're building it and you should be good to go.
Basically, use headers and jumper wires and it won't matter so much.
They're talking about the signal wire to the HB-25. I'd go with what they recommend until you find a reason not to. Using Pins 0 and 1 make sense because there is nothing else connected and the pins are side by side to keep things neat. The motor controllers are also going to be a higher priority than most other IO pins, so knowing that they're the lowest pins make it easy for you to remember they're the lowest pins.
Unless you're building a sigma-delta ADC there might be some pins you'd want to use but other than that I think it will come down to personal preference and aesthetics. It's easy enough to change later, so it's important in your physical connections you not do anything too permanent. Using headers are great for this, you change the code and jumpers and be completely reconfigured in minutes. Just keep in mind that can happen for anything while you're building it and you should be good to go.
Basically, use headers and jumper wires and it won't matter so much.
Now this is why I like and need this forum! Thanks for the explanation and for the several good ideas and considerations:
Pin Proximity/useful location;
Priority consideration and useful memory jog;
Headers for reconfiguration.
Comments
EDIT: Can you suggest some possible uses of XBee (or Nordic) modules in a rover such as I have in mind? Thanks.
IMHO you'd be infinitely better off using a real RC remote control and some kind of RC Multiplexer to allow you to take control. That's what I've been doing with Data Bus for the last couple years. Works great. RC remotes have good range and reliability. I use a 3CH FlySky GT3B (cheap but very good). A dedicated Mux board/MCU means if your main MCU hangs, crashes, etc., you can still take control of your robot.
Coincidentally I sell a 3CH Rover RC Mux on Tindie
EDIT: I found your Bots Thoughts code postings and the Main.C code is pretty intense. I could use a Propeller cog to deal with the RC MUX tasks and would have lots of capability remaining. I will continue to check out the RC and MUX aspects for potential use in my rover. Man, like Duane said, lots to learn!
This is pretty easy for the Propeller. You'd just check the timing of how frequently new pulses were received and if the pulses didn't arrive within a set time limit, you'd have the Propeller take over control.
In a relatively recent thread started by NWCCTV, I posted a link to my version of a 6-channel RC receiver code. There is also a link to the code in post #2 of my index. In the thread started by NWCCTV, someone posted code to use a RC receiver to control two CR servos. This code should also work with motor controllers you're using on the WT. What the example doesn't have is a time limit to trigger autonomous control. If you want to go this route, let me know. A time limit would be pretty easy to add.
I've been impressed by several RC setups I've used. I've flown airplanes 1/4 mile away. Usually you lose sight of an airplane before it flies out of range. I doubt you'll get nearly the same range with a robot underground as one gets with an airplane in the sky.
While I use RC gear (I'm using the term "RC gear" to describe radio control equipment commonly used to control airplanes and helicopters) with several of my robots, I really like using two way radios so I can receive telemetry back from the robot. (I think there are some RC systems that now have telemetry.) The ability to receive telemetry give me reason to prefer Nordic and XBee type transceivers over RC gear. The main reasons I often use the RC gear with my robots are I already have the gear, it's pretty easy to use with the Propeller and the transmitters come with ready to use (and ergonomic) joysticks and switches.
I think the RC gear has better range than most XBee modules and pretty much all the Nordic modules. There are a few XBee radios which (I believe) have comparable range to RC gear.
I have limited experience in this regard. I've used these Xbee 900 Pro XSC modules. I left one in at home and started walking down the street with the other. It had a good signal as I walked a block away. At the end of the block I turn the corner and the line of houses between the XBees completely blocked the signal. These XTend radios look like they have even better range than the XSC modules. Apparently the range with both these types of radios is improved with directional antennas.
I don't know how these would work underground.
One option I really want to try sometime is to make a network of wireless modules and have the messages hop from one transceiver to the next. This would require a pretty smart robot(s) if you used the robot to deploy the network. I want to make a bunch of wireless nodes with inexpensive Nordic modules (there's a link in post #1 of my index to inexpensive modules). Each module could be enclosed in something like a plastic Easter egg. The robot would drop one of these modules every few hundred feet as it traveled down a pipe. The messages would then hop from one node to the next as they made their way down the pipe and back.
It would be nice if the nodes could be inexpensive so if the robot wasn't able to retrieve a couple, it wouldn't be a big loss. I've used an AVR ATtiny (which are pretty inexpensive) to interface with Nordic modules, but I don't know if I'd be able to program in all the message hopping algorithms in an ATtiny. I have programmed multiple Propellers to use message hopping. It would be nice if I could find a lower cost microcontroller than the Propeller to use in the wireless nodes but it may be easier just to use the Propeller since I'm more familiar with programming it than other microcontrollers.
I'm pretty sure Gareth (a smart guy with lots of very cool projects) was working on a project using a bunch of Nordic modules. I'm not sure what he is planning on doing with the many transceivers.
Getting a robot to leave a trail of transceiver nodes is far from a simple task but it's one of those things I'd really like to try sometime.
Thank you for a detailed and informative post, Duane. I am wanting to see if I can work into my design the use of RC gear much as you have described. I need to keep reading up on this and your receiver code is a great resource.
As a Project Update, I really hope to finally be able to purchase a Wild Thumper Robotics Kit soon. It really looks to be the absolute best available choice for a mobile platform for my planned rover. With the HB-25 motor controllers, the on-board Propeller Project Board, and the six brushed DC motors, this is the best value for the money that I have found. My plan is to eventually build a proof-of-concept device that will do everything I want to do, then either replicate it (essentially make clones), or construct a rover from scratch that uses the same overall layout and functionality.
I have two NiMH battery packs that I found on sale at Radio Shack, rated 7.2v/3000mAh. Is it possible that I can get by with using one pack for locomotion and one pack for sensors/mini video camera? I know it all depends on the demand and many variables, but could one pack allow the Thumper to operate for say 30 minutes off and on? Or is this just way too much to expect from this battery capacity?
I see that your R/C MUX is down to 4 units. Will this be available at a later time, should they sell out before I can purchase one?
Also, could you please indicate a specific R/C TX-RX system that I may consider using with my Propeller-based rover? Many thanks!
I personally won't bother with an external mux. It would mainly be there in case the Propeller crashes (which can happen). I don't think it's essential to start with a mux. You can see how things go without one and decide later if you need one or not.
It just seems like there are other more pressing needs than the $12 mux. (Not that I think it's a bad deal or not a good device to have.)
As long as your code is stable (which can be a big if) the Propeller can take care of deciding who is in control of the robot.
Duane,
Indeed, I have many other pressing considerations with my rover design. And I can always add this at a later time if I think it is important. I was thinking that having RC available would be nice to steer the rover where desired, when autonomous control was not the best option. It may also provide for a nice way to walk a rover out of a situation should it become caught so to speak.
I am going to look over your personal projects again for ideas. Thanks for the comment.
I do plan to make another batch when these sell out. Also they're on sale for $9 on Cyber Monday so wait until then.
As for a specific RC radio system, I've set up the firmware with wide timing tolerances so a very wide variety of standard RC systems should work. The tolerances can always be widened and the firmware updated by using an AVR programmer or an Arduino as ISP. I'm using the FlySky FS-GT3B and it's been tested with a few other radio systems.
RIght now I have the period set to between 20 - 200Hz (typically 50Hz) and on time of 3ms-30ms (typically 0.5ms-2.0ms)
Source: https://code.google.com/p/bot-thoughts-ugv/source/browse/tags/RoverMux_0.3/software/main.c
Good points. Keep your speeds low enough and have a kill switch if you're worried about the robot crashing into curbs or people. If you go faster than a walk, some kind of RC mux capability is nice to have.
When I built Data Bus I wanted something external and highly reliable as I had planned to go fast (the robot does 20mph on the straights). Even starting out at a walking pace of 5mph I was glad to have the mux to take over the robot. Was it essential? No, I could've run after the bot easily enough. I was glad to have it as I ran the robot faster and across longer distances, though, which happened later in development.
Also of note, I didn't trust the rest of my code -- I was writing on a single core ARM MCU with complex interrupts and code running. I didn't trust all that to reliably multiplex; all it'd take is me goofing up an ISR or some such to hang the MCU and render the robot out of control. And believe me I've hung the MCU more than a few times.
Propeller is a different ball game. You don't have interrupt handlers that can hang, you can run multiple cogs dedicated to tasks. So you can save the money and simply dedicate a cog to the RC mux duties and call it good. The main advantage of an external mux in this case is you save a cog. Take a look at my source for ideas on how to detect the signal.
But it's still possible to throw a wrench into a Prop's inner workings. I've lost count of how many times I've written to address zero of hub RAM instead of the intended location. If you mess up the clock setting (by writing to low RAM addresses) it will interfere with all the cogs. I like the idea of an external MUX, but I'm not sure if it should be a really high priority to start with if funds are short.
Yes, definitely. Agreed. Didn't mean to suggest otherwise. I didn't really finish reading the thread when I replied. Sorry 'bout that.
If it helps, I did my first mux super cheaply using a home etched board with (mostly) salvaged analog parts and other parts I already had in my stash.
I have your site bookmarked and am trying to learn from some of your posts and project offerings. I have also looked at your code and find it to be well done and documented. I am learning C language, trying to understand motor control and all those algorithms, etc. You, Duane, and all the others have proven to me that I have a long way to go. Thanks for the RC recs.
My rover will be used more often than not to navigate fairly easily accessible drainage pipes and culverts. However, part of the duties of the rover will be to traverse very steep sloping terrain, although at slow speeds. A RC system could prove to be useful on such areas, keeping me from having to climb up after it more than I want. It will certainly be a consideration for me after I obtain the chassis and begin working on my rover. And thanks for the heads-up on the sale.
I am unsure whether to program in C or in Spin/Assembler. I used to code in Assembly on many devices, and with Spin I see that there are lots of great offerings in the Object Exchange. But there are only a few examples for C in OBEX, which makes it much harder for me to develop code. I have programmed with other high level languages, and I am sure I can learn to do so with C, especially with the great tutorials here. But with the Spin objects available, and with the power of the 8 cogs of the Propeller, it may make sense for me to try Spin first. Will this be feasible (sufficiently fast enough) to run the HB-25's, a PING or two, a Parallax GPS, an XBee, and perhaps a few other systems without too much loss in speed or accuracy? I figure it should be sufficient, as the Trekker operates with an Arduino (single core device), and the Propeller has 8 cogs. Comments are certainly invited and welcomed.
Another way to figure it out is to work in both environments. For instance I used SPIN and C to perform one simple task. By doing small individual projects I could instantly tell that I will continue to use SPIN and would much rather start learning PASM than C. I think the support for C is great but I don't think it is better or worse than SPIN, especially for a not-too-complex robot.
Thanks for the reply. I think I may just proceed with SPIN at this time, letting the wealth of knowledge within the OBEX help me without recreating the wheel so to speak. Once I feel comfortable with what I am doing, then it may be time to try my hand at C. I am still working on the C tutorials with my Propeller Activity Board and what I learn from that will be helpful in my "porting over" my code to C in the future.
Have you worked any more on your Wild Thumper? I am still saving up for one. But I need o get cracking on code writing, at least pseudocode...
Page 10 (of 12), at the top of page.
Guess it means "Pin"? any other comments or ideas will be welcomed also. Thanks for the reply.
Unless you're building a sigma-delta ADC there might be some pins you'd want to use but other than that I think it will come down to personal preference and aesthetics. It's easy enough to change later, so it's important in your physical connections you not do anything too permanent. Using headers are great for this, you change the code and jumpers and be completely reconfigured in minutes. Just keep in mind that can happen for anything while you're building it and you should be good to go.
Basically, use headers and jumper wires and it won't matter so much.
Now this is why I like and need this forum! Thanks for the explanation and for the several good ideas and considerations:
Pin Proximity/useful location;
Priority consideration and useful memory jog;
Headers for reconfiguration.
Good ideas for anyone! Many thanks!