Building a PC-based robot

For use in robots, I'd rather have the output directly in memory. If you are storing the file to disk, then reading the file from disk again before you begin to process it, you are going to hit problems when it comes to the speed of the vision system (especially if you have a lot of other disk activity going on, e.g. data logging). I guess it depends how fast you want the robot to move, but I'd not want to go less than

5-10fps on the vision system. Depending on the type of storage you use, this could be difficult to reach.

I'll have to look into it. Hopefully a camera is as easy as accessing a normal device if you use Video4linux (it would seem that way after a few minutes googling).

Absolutely.

Matt

I have a VIA-Eden based mini-itx board, using a laptop harddisk, 12V power supply (PW-60 from mini-box.com) and of course Linux. I have a USB wireless adapter to comminicate with the robot and a camera to see what it is seeing. I'm very happy with my setup. I'm looking forward to having Nano-ITX board (I'will be among the first ones buying it). The total cost is: MB~$140, HD~$100, Memory~$70 PW-60~$35. Forgot the

12V battery price.

Husey> Hi all.

/dev/cam0 doesn't mean that its actually on the disk.. Linux has a device tree which looks like a directory but can actually exist in any form: serial port, parallel port, even RAM.

On my mac, for instance, I have:

/dev/mem /dev/kmem /dev/null /dev/random

etc.

These are obviously not files on disk.

Yes, you're quite right on that issue, but I was referring to the idea of using a separate executable to save a file to the disk and then read that file. Don't worry, I am quite familiar with the Linux file system :-)

Oops, the way you quoted it I thought you were talking about /dev/cam0. I see now the part above about "getpic -...". Yes, that does seem like a bad idea to me.

On the other hand...I don't know how pipes work at an operational level, but it seems to me that a program can pipe information without ever writing to disk. One poster was making the point that part of the linux paradigm is to chain tools together, ie.

getpic -h 640 -w 480 -d 32 -jpg | findedges | neuralscan | etc...

I assume this works?! (I mean, without using the disk.) Not having used linux much, I would tend to just write all this stuff into one app.

: getpic -h 640 -w 480 -d 32 -jpg | findedges | neuralscan | etc...

: I assume this works?! (I mean, without using the disk.) Not having used : linux much, I would tend to just write all this stuff into one app.

Yes, conceptually this would work, and data would not go to the disk.

At a conceptual level, yes this would work - basically it just connects the output of the first programme to the input of the second programme. For use in robotics, this is probably not ideal as you'd need to run the programme for every single frame you get from the capture programme (in this example, "getpic") - i.e., this does not set up a permanent pipe, rather only a pipe for a single instance (unless you scripted it all etc).

If you are familiar with Linux system programming it is possible to setup a longer lived pipe through software that might be more effective. Persoanlly I'd rather access it as a system device rather than a third party, potentially closed-source, application as I'd like to optimise it to the maximum.

Matt

vgrabbj outputs to stdout by default. Do whatever you want with it from there.

It's easier.

--kyler