linuxpcrobot.org

[...]

No, I don't think there is any compression involved?

I am talking about those wireless video cameras that come with a wireless receiver that plugs into a TV. I don't know what the resolution is but I could find out. The images looked as good as a web cam.

formatting link
People like to put them on radio controlled cars or use them as "spy" cameras. The idea is to plug them into a pc tuner/grabber card and be able to access the hardware from your own program.

[...]

Actually I would need a complete example program not just a fragment.

It looks a bit more complicated when I googled for such programs...

formatting link
Like I say I have a long learning curve ahead and I have to start with a Linux C version of "hello world"...

-- John

Reply to
JGCASEY
Loading thread data ...

The wireless camera's that have a transmitter and reciever and plug into an RCA jack will require a video capture card.

The wireless webcams typically implement a web or streaming video server, and don't need an analog reciever.

I'd opt for the wireless webcam.

Dude, go here:

formatting link
The above link is the Linux quickCam driver project, download qc-usb. Download it to a file, and then open it with WinZIP. Look at the file, "testquickcam.c"

formatting link

Oh my god, you are talking about converting a video device to mpeg, 1000x more complicated.

Reply to
mlw

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

Reply to
the Artist Formerly Known as K

Thanks dude, that's the kind of information I think I will need.

-- John

Reply to
JGCASEY

In which case GPL isn't the best fit license. I believe there are licenses which do exactly what you describe.

Reply to
penguinista

Without wanting to start a flame war here. I am a huge fan of the protections of the GPL, however, I think that for it to be an effective license for an entity that wishes to share, but not lose ownership, care has to be taken to prevent the dilution of ownership.

There is a HUGE balancing act that has to take place. On my site, I want all contributions to remain the exclusive property of the original authors. This is important as many of the potential authors may use the code placed on the site for their professional work. Ownership dilution threatens the usability of the code.

What if someone GPL's code for the robot project, but someone donates a feature or functionality that the original author may have been planning or implementing? If the 3rd party addition is accepted, the code is tainted and the original author is no longer allowed to use the code as he or she sees fit without maintaining separate versions. Alternatively, if the feature is not accepted, and the riginal author brings their version of the feature online, I can see fights and law suits over ownership.

It is best that up front to state that patches to source modules become the property of the original author. This is not too harsh for small bug fixes and, hopefully, reduces wholesale reworking of modules by 3rd party contributors.

Secondly, many developers really really dislike radical changes on their code. I've been on a couple open source projects where someone's code gets virtually re-written while the original author was focusing on something else. Once the patch is applied, the original author no longer even recognizes his code, and has virtually lost any use of it. He is back to maintaining his own copy and will probably abandon the project. A radical rewrite should take place as a new source module.

Reply to
mlw

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.