linuxpcrobot.org

JGCASEY wrote:


I use these quite a bit. In general they are a good option if you don't have to do video processing on your robot. You can also get separate transmitters and cameras (you can also do this with capture hardware on board the robot). This is nice, since webcams usually have a fairly narrow FOV. Security cameras on the other hand generally don't. Frame latency should never be an issue.
The major disadvantage here is that if you want to take your robot on the road, you have to lug other stuff around to do video processing. Also, you need to choose your frequencies carefully, since many of the common 2.4 ghz bands used for video are also used by other consumer stuff -- such as wifi, cordless phones, bluetooth devices, etc. If you want to do stero, make sure your transmitters support multiple channels.
The TV tuner card will look just like any other video for linux device. As Mark pointed out, you'll send it a couple of ioctl requests to set it up, and then you can read frames directly from it just as you'd read any file. You can also memory-map buffer directly into the driver space -- which makes for a more efficient read, but I haven't tried that yet.
The major drawback to running a framgrabber under linux will be getting a device with supported drivers. Be aware that linux driver support tends to seriously lag capture card releases, so you will almost certainly be better off with an older device, rather than a shiny new one. The bt848-based cards are well-supported -- such as the older Hauppauge WinTV cards. I also use the Hauppauge WinTV usb with the usbvision driver (not included in the kernel source distro, though).
If you run a linux board (or any other OS on a PC) on the robot and intend to send frames back via wlan, you'll want to compress the raw frames first -- and since you're doing image processing, I assume you want lossless compression. I have used simple predictive encoding and rle for this, which works reasonably well and is easy to implement. You can also pre-process the image prior to sending it to reduce the amount of data being sent (say, by doing edge extraction). Be aware that latency may be more of a problem than data throughput if you're using wlan to transmit video back to another machine.
A good book on video compression in general, btw is Peter Symes' "Video Compression Demystified". "Video Codec Design" by Iain EG Richardson is also pretty good.
Hope that helps -- m
--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JGCASEY wrote:

Not related to diameter, but broader wheels create larger encoder inaccuracies. Borenstein found this out, and documented it well. Slick, hard wheels are also to be avoided, for obvious reasons.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

My robot does not rely on encoders for navigation so accuracy isn't an issue. Broad wheels are good for sandy situations. If the are big enough with nice tread the robot could even cross a river :)
The reason for solid wheels is to avoid the problem I had with the wheels going flat!
-- John
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JGCASEY wrote:

You're right, but MLW is using encoders, and his wheels are hard, slick, and broad. I can understand his desire to change them out. This is one of the problems with those kid rider toys. The wheels are often a smooth styrene or ABS plastic, and not a rubber that has some grip.

Airless tires (for wheelchairs and such) are nice for this, if you can afford them.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

I am using the same toy motor/gearbox/wheels except they have a strip of sticky rubber with tyre tread marks like this |||||
Maybe mlw could find a rubber belt that might fit around the slippery plastic wheels?
-- John
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JGCASEY wrote:

Yes, that might work. I've gotten some rubber anti-slip tape at the home improvement store that has a waterproof adhesive. It's for lining spas, tubs, and such. Goey sticky. It's worked well in adding "gription" to some slippery tank tread segments I regularly work with.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.