Propeller-Powered Wild Thumper Inspection Platform
George Sutton
Posts: 180
Propeller Pipe InspectionRobot (P-PIR or “PEEPER”)
In a previous post under the General Discussion forum, I briefly set forth an idea I have of building a robotic platform to inspect culverts and pipes for signs of failure; I thank those who provided me with ideas and comments. This Project thread is my attempt to document the design that I have in mind to build, along with its actual and concurrent construction and eventual deployment. I am asking for any ideas from the greater Parallax forum community to help make this a successful robotic inspection platform. Note that this project is being financed by myself to develop a proof-of-concept vehicle with which I can approach my superiors and convince them to fund the building of several identical (or similar) inspection vehicles. Accordingly, I have no problems with treating this project design and development as an Open Source project. To me, such a designation means that I am open to all comments and suggestions that may improve the functionality of the inspection vehicle; after all, the end result, should it prove successful and be financed by my employer (a state transportation agency), will be used in routine work-related tasks and hopefully save the taxpaying citizens a substantial amount of money. I also invite comments that may indicate why an Open Source concept is not the best way to advance my project goals. This inspection vehicle will hopefully be documented at least periodically as I progress with the design and construction of the Propeller Pipe Inspection Robot (P-PIR), or "Peeper" for short.
PROJECT DESCRIPTION (AND REQUEST FOR IDEAS)
I am wanting to design and construct a mobile platform that is capable of navigating a drainage pipe or culvert structure and providing visual documentation of any signs of failure within the pipe or culvert. The most significant signs of failure would include rusted-out floor or side areas of a metallic pipe, or cracks in the walls or floor of a concrete culvert.
The Peeper will use a Wild Thumper chassis. This rugged 6-wheeled platform is well-suited for the proposed environments, and will allow for many sensor and equipment additions as time goes on. It should have little difficulty in navigating over minor accumulations of debris within the pipes and culverts. If anyone has experience with the Wild Thumper, I would like to hear of any problems that have been encountered when operated in wet conditions.
I will use a PING))) with rotation to sweep in front of the Peeper and hopefully along a portion of the sides. I will also use a PING))) with possibly a servo to monitor the ceiling/top of the culvert/pipe; at a minimum this will provide me with a diameter/height, and will also give me an estimate of collapsed areas along the pipe length.
The biggest challenge for me is the type of video camera to use. I would like to send real-time images to be viewed on a laptop, but I need to research this much more. I am having to educate myself on video technology, as I know nothing about it (and many other things). Recommendations are welcomed here.
The Wild Thumper comes with a Propeller Project Board (PPB). I am trying to decide whether or not to replace the PPB with a Propeller Activity Board (PAB) that I already have. The PAB will allow me to easily utilize Xbee modules, provide storage on micro SD cards, provide for convenient A/D and D/A, and other possible features of interest.
Power Supply: I know nothing about R/C-type batteries and chargers, so I will address this as I discover more about what I may need to power the Peeper.
Programming Language: I had planned to code the Peeper using C with the Simple IDE, but lately I am hearing more about various benefits using the Spin language. This is something that I must figure out first. Experienced Forum members are really welcomed to chime in on this.
*** ….. ***
In a previous post under the General Discussion forum, I briefly set forth an idea I have of building a robotic platform to inspect culverts and pipes for signs of failure; I thank those who provided me with ideas and comments. This Project thread is my attempt to document the design that I have in mind to build, along with its actual and concurrent construction and eventual deployment. I am asking for any ideas from the greater Parallax forum community to help make this a successful robotic inspection platform. Note that this project is being financed by myself to develop a proof-of-concept vehicle with which I can approach my superiors and convince them to fund the building of several identical (or similar) inspection vehicles. Accordingly, I have no problems with treating this project design and development as an Open Source project. To me, such a designation means that I am open to all comments and suggestions that may improve the functionality of the inspection vehicle; after all, the end result, should it prove successful and be financed by my employer (a state transportation agency), will be used in routine work-related tasks and hopefully save the taxpaying citizens a substantial amount of money. I also invite comments that may indicate why an Open Source concept is not the best way to advance my project goals. This inspection vehicle will hopefully be documented at least periodically as I progress with the design and construction of the Propeller Pipe Inspection Robot (P-PIR), or "Peeper" for short.
PROJECT DESCRIPTION (AND REQUEST FOR IDEAS)
I am wanting to design and construct a mobile platform that is capable of navigating a drainage pipe or culvert structure and providing visual documentation of any signs of failure within the pipe or culvert. The most significant signs of failure would include rusted-out floor or side areas of a metallic pipe, or cracks in the walls or floor of a concrete culvert.
The Peeper will use a Wild Thumper chassis. This rugged 6-wheeled platform is well-suited for the proposed environments, and will allow for many sensor and equipment additions as time goes on. It should have little difficulty in navigating over minor accumulations of debris within the pipes and culverts. If anyone has experience with the Wild Thumper, I would like to hear of any problems that have been encountered when operated in wet conditions.
I will use a PING))) with rotation to sweep in front of the Peeper and hopefully along a portion of the sides. I will also use a PING))) with possibly a servo to monitor the ceiling/top of the culvert/pipe; at a minimum this will provide me with a diameter/height, and will also give me an estimate of collapsed areas along the pipe length.
The biggest challenge for me is the type of video camera to use. I would like to send real-time images to be viewed on a laptop, but I need to research this much more. I am having to educate myself on video technology, as I know nothing about it (and many other things). Recommendations are welcomed here.
The Wild Thumper comes with a Propeller Project Board (PPB). I am trying to decide whether or not to replace the PPB with a Propeller Activity Board (PAB) that I already have. The PAB will allow me to easily utilize Xbee modules, provide storage on micro SD cards, provide for convenient A/D and D/A, and other possible features of interest.
Power Supply: I know nothing about R/C-type batteries and chargers, so I will address this as I discover more about what I may need to power the Peeper.
Programming Language: I had planned to code the Peeper using C with the Simple IDE, but lately I am hearing more about various benefits using the Spin language. This is something that I must figure out first. Experienced Forum members are really welcomed to chime in on this.
*** ….. ***
Comments
This is a really cool project IMO. I've wanted to do something like this myself but I don't really have the need.
I bet you'll want to use both your Propeller Project board and your Activity board with this project. You can use one on the robot and one on a base station/remote. I'd be inclined to put the Project board on the robot.
A couple of days ago, I would have said to definitely use Spin. Now, I'm not so sure. It looks like Parallax is going to put a lot of effort into the C lessons. I may eventually switch over to C myself. (Did I really just type that?) At this point, I think there's a lot more Spin code that would be useful to you than there is C code. It won't be a waste of time to learn Spin since the real trick in programming in thinking about how to organize tasks in appropriate loops. I think programming experience gained in one language will be very helpful when using the other (IMO Spin and C are very similar).
One concern I have about this project is the robot getting stuck. I suppose it may be possible to design a robot that couldn't get stuck but I don't think the Wild Thumper is it (though I do think the WT is a great choice for this project). There will likely come a time when you're going to need to retrieve your robot from whatever pipe it's in.
I kind of liked your tether idea. I'd just make sure the tether was strong enough to be used a tow line to retrieve a stuck or disabled robot. A tether will introduce all sort of problems and may be more trouble than it's worth, but I wouldn't be quick to discard the possibility of using one.
XBees are easy to use but they're expensive. I keep pushing Nordic nRF24L01+ modules since they're so cheap. I have some Nordic links in post #1 and #2 of my index (see my signature).
The Nordics won't have the range of 900 MHz XBees but they should work reasonably well on robots close by. As much as I like the Nordic modules, I think 900MHz XBees might be a better choice for wireless telemetry from inside a pipe.
In general, lower frequency radio waves have better range than higher frequencies (for radios with identical power output). This has something to do with the physics of radio waves (which I don't understand even though I minored in physics).
I do make my recommendation of 900MHz XBees conditional on what other wireless equipment you may be using. You may want to use a 900MHz video transmitter. In which case, you don't want your telemetry also on or near 900MHz. I'm not sure about this though. I'm just repeating what I've read. I haven't tested my 900HHz video transmitter with my 900MHz XBees to see if they interfere with each other or not.
2.4GHz XBee Pros may be a good option for telemetry if you use a 900MHz video transmitter.
It may be possible to use the video transmitter to transmit your telemetry. One option would be to overlay text on the video signal with a circuit similar to that used in a Propeller Backpack. Another way of using the video transmission for telemetry is to use a text to speech device to send data over the audio channel of the video transmission.
One drawback of adding telemetry to the video link is it's one way. You wouldn't be able to transmit data or instructions to the robot.
I've had trouble with radio interference from switching power regulators in a couple of my projects. I think this is something to keep in mind. I've had projects work just fine on the bench but when I used a battery with switching regulator they completely lost their wireless capabilities (including GPS).
I agree with your choice to use RC hobby batteries. The RC world has pretty much gone over to LiPo packs as power sources now. I think LiPos are the best choice for this sort of robot.
If you haven't visited HobbyKing's website do so. They have also sort of great stuff for good prices. I buy lots of batteries and wire from them. Keep in mind their shipping is either slow or expensive. It generally takes three weeks to receive an order from them unless you use the expensive shipping option.
There's a lot of stuff to learn in a project like this. I look forward to watching your progress.
If you have the time, take pictures and make videos. It's fun to read about robot projects but it's even more fun if there are pictures to go with the words and it's even better if there are videos so we can see the robot in action.
Tethering using single twisted pair for data and video over 100 meters is in use by a lot people building ROVs. This guy is worth a quick read - http://openrov.com/forum/topics/teardown-of-a-homeplug-adapter
An acelerometer would give you a really good idea of a slop angle and you'll find lots of code and other robot projects to work from. In addition to a live video feed it would help keep you out of trouble too. You could use it to impose limits on movement for tilt to keep the robot from flipping over.
Speaking of flipping over you may also want to implement some kind of arm on each side to prevent that from happening.
Can you find some video online of an equivalent environment you're putting this thing into?
That was an interesting read. I don't think one needs to go through that much trouble to get a good signal down a tether.
I'd think RS-485 would be easier and less expensive than using those data over power line modules. The Prop can't do much with data coming in faster than about 115,200bps. The serial driver may be able to send and receive bits faster than this but a program running Spin can't move the data around much faster than 115,200 bps (IIRC, the limit is a little above this but 115,200bps is a common baud and pretty close to the limit).
JonnyMac has at least one RS-485 article among his (IMO excellent) Spin Zone offerings. There's a link to the Spin Zone articles in post #3 of my index.
If you want full duplex with with RS-485, you'll need four wires otherwise the robot and base station have to take turns transmitting (taking turns generally isn't a problem).
I just thought of something. If the data over power line module can transmit video, then I take back what I said about using RS-485. I imagine if it does transmit video it needs to be encoded to packets suited for streaming over the internet. An ethernet camera would do this automatically. Otherwise the robot would need a small PC to encode the video.
Even if you need a tethered option in some circumstances, I think you'd want to use wireless whenever it's practical. While it wouldn't be hard to switch between sending data over a tether or wirelessly, the video may not be so easy depending on what type of video signal you're using. There are a couple of different wireless video options. It used to be if you wanted to transmit video from a robot, you'd use a transmitter which use a NTSC signal. This is the kind of transmitter I have. Now there are several digital video transmission options. I think some video can be transmitted over wifi link. Smart phone can also transmit video. I haven't used these digital techniques myself. The digital video transmission options require a lot of computation power to convert the video to a digital signal. A smart phone, IP camera, or small PC are ways to digitize video (with the right kind of camera for the purpose).
If you wanted to use the same type of video signal on both the wired and wireless transmissions I can see a couple options. One would be to use a NTSC signal and use an analog video transmitter for the wireless and some sort of wire for the video signal on the tether. I purchased a bunch of NTSC video cameras from Woot once and they came with long (50') wires for both video and power. the video wire looked like if was coaxial. I don't know how thin and long you could have an analog video tether. If you use cameras with digital output then you should be able to send the digital video back through a tether if you had a fast data rate. This would require some sort of PC on the receiving side to output the video signal.
Did I mention there's a lot of stuff to learn?
Ping -- slow update rate (IIRC)^H^H^H^H^H^H^H^H edit: I don't recall correctly and quite likely am full of it.
Maxbotics -- also sonar, but faster update rate
Sharp Infrared sensors, reasonably accurate, ~40Hz update rate, cheap, various ranges.
I'm working on an analog to digital converter board (A2D) that will lower the noise and improve resolution for the Sharp sensors and hopefully Maxbotics and others.
Some other thoughts... what's the effect on radio of being inside a very long metal tunnel ?
You're welcome to join us on diyrovers on Google Groups. We're mostly about scratch-building rovers of various types, typically autonomous.
In the arena of video, take a look at FPV options the folks are using on DIYdrones. Lots of options.
shimniok, how sure are you about the slow update rate of the Ping? One (of many) nice things about the Maxbotix sensors is they don't require a trigger pulse. They just continually output the data from the reads in multiple ways. They're cool sensors but also kind of expensive (as is the Ping).
The Maxbotix sensor has a 20Hz update rate. I'm pretty sure the Ping on SR04 sensors can also be used at 20Hz. I'm pretty sure the refresh rate is limited by how long it takes for the ultrasound echos to dye down. I don't think one sensor has an advantage over another in this aspect (though I'm not sure).
I don't think all ultrasounds are created equal. I think the Maxbotix and Ping are more reliable than the cheap SR04 sensors. The SR04 sensors are so darn cheap it may be worth testing them to see if they would work well enough for your needs.
I personally think you'll want both ultrasound and IR sensors. I think the two sensor types compliment each other. There are plenty of obstacles one sensor will see that the other wouldn't. I was very interested to see which sensor would detect obstacle first with my ultrasound enhanced Scribbler 2. (The ultrasound added to the S2 was a Maxbotix.) It turned out flat smooth objects will bounce the ultrasound away from the sensor instead back to it. In these cases the IR sensor of the S2 had the advantage. There were lots of furniture legs the S2 would have run into if not for the ultrasound. My experience with the S2 has made me an advocate of including both ultrasound and IR sensors on robots.
As erco's signature used to say: "An ounce of testing is worth a pound of speculation." I think you're going to need to do a lot of testing. You might want to use a small robot in some of your tests. If you do, I have a thread about making a robot with inexpensive parts here. I think you could have a small robot for quick tests for a little over $50.
I haven't checked out diyrovers myself. I plan to do so. I know you're already familiar with Let's Make Robots. I think there's a lot of cool stuff going on at LMR.
I think I'm full of it actually. I should have gone back to the datasheet to refresh my memory.
http://parallax.com/sites/default/files/downloads/28015-PING-Documentation-v1.6.pdf
I just glanced but if it's only 18.5ms + 200µsec that's like > 50Hz. I may have to break mine out and verify that.
I prefer the Maxbotix sensors, at least in principle (I've yet to actually use one on a project; I've only done some testing) 20Hz is pretty good.
TOTALLY agree. Nothing helped me more with my rover than testing subsystems. E.g., how much does motor current *really* impact magnetometer. Rather than going with common wisdom, my experiment revealed something rather different.
LMR does have cool stuff. Would love to have you join us on diyrovers mailing list. (note: diyrovers not to be confused with DIYdrones which is also neato)
Michael
One other good thing about tethering is it could provide you with an easy odometer. Pay out 100' of cable and see a crack you'll know it's around 100' down the pipe.
It might be overkill to use Ethernet over the tether. RS-485 would be inexpensive and easy to implement given all the example code you can find is geared for it and you wouldn't need any network interface. You can also send analog video over another twisted pair using Baluns.
I would imagine a good combo to be RS-485 for remote control and analog CCTV camera with IR night vision - augmented with LEDs on the bot if you need color.
John Abshier
Of course, until you hit the first bend.
NWCCTV, 1.2ghz is a way better option when you need the signal to penetrate. 5.8ghz looks awesome, but you'll lose signal real fast.
Here's my example of 500mw 5.8ghz (circular polarized antenna) line of sight, it was dropping out pretty fast and just my body would block the signal. It doesn't work indoors well, I doubt it will work in a pipe but I have no experience in that area.
[video=youtube_share;g60RS_07Ya0]
I don't know what frequency would be best for your purposes.
In my limited experience, my 900MHz transmitter works better than my 2.4GHz system. This doesn't really mean much since the 900MHz system is a higher power system and cost more than the 2.4GHz system.
A camera with a built-in transmitter may cost less than purchasing the two components separately but I like having the option of using different cameras with a transmitter. I also like being able to use various displays on the receiver end.
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.