Subject:
|
Re: A Generic Idea
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 6 Jan 2003 14:04:37 GMT
|
Viewed:
|
795 times
|
| |
|
|
In lugnet.robotics, Steve Baker <sjbaker1@airmail.net> writes:
> Henrik Erlandsson wrote:
>
> > Well, to find outline of objects you'd need a low-res (easy to simplify and
> > automatically filters out irrelevant details), color (to avoid two objects
> > of the same material getting their outlines fused together by the image
> > processing software). A 64x64 image that is automatically reduced to 256
> > colors (by a filter like in Photoshop) would be perfect! That would take 4KB
> > per image, uncompressed. With simple RLE compression probably much less than
> > half that.
>
> Yeah - but the amount of CPU horsepower to do that (on the robot remember)
> is comparable to the horsepower you'd need to extract the edges and do some
> simple image recognition. So why transmit the image at all?
Sigh. I wish you would read the rest of my message and discover that I
address that issue(!), instead of chopping the messages up into neat pieces
which you can "deal with".
> > The problem is finding a camera that does that BEFORE transmitting the
> > picture. The only equipment that is reasonably cheap that does this is the
> > cel phones I was talking about.
See?
> Yes - but they don't compress images like that. They do adaptive motion
> compression. For example - if you are looking into the camera talking
> to the person at the other end of the line, the camera notices that your
> head isn't moving much and sends just the pixels in the region of your
> mouth. You notice this immediately on using one of these things because
> any sudden motion in the scene causes the frame rate to drop precipitously.
>
> That's OK for the kinds of things cell phone video is used for - but for
> navigating a robot around a room, it's hopeless since the robot is moving
> around a lot - the image changes in ways that are really bad for the
> compression algorithm.
Who talked about live video? I was talking about still images. Image
processing, you see, not video processing. To identify an object, the robot
would probably have to be still anyway, for scale/matching/etc reasons.
> > Hmm I think we're straying from the topic. The generic idea was to provide a
> > constant link between robot and a better brain. And the celphone (which is
> > prolific in Europe, every teenager has one, and 1/3 of the grown-ups have
> > one ;)) seemed to be the most generic of the links. It also seemed simple
> > and cheap to use, as compared with a PDA+camera which may run you $500-$800.
>
> Yes - that's certainly true - but I think you are missing the point that
> cell-phones are not in any way 'hackable'. There are no good interfaces
> for getting at their internal goodies.
I'm sorry I brought up image transfer with cel phones. Use it for making
spybots or teaching the robot, nothing else. As a wireless link, they would
still work fairly well imo. For example, calling up one of 100 sound effects
stored in your pc. You could even sample C-3PO from a movie and have a
'line' for every occasion :P
> The RCX's CPU is pretty slow by modern standards. But if you are using
> a PDA with it, that's irrelevent. The RCX would only have to turn motors
> on and off and report back sensor data...that's a *tiny* amount of work.
> There is plenty of bandwidth to send motor data and sensor reports back
> and forth at insanely high speeds. Nothing on the RCX really needs to be
> updated more than (say) 10 times a second - and with only three sensors and
> three motors, that's at most 30 bytes per second in each direction.
The link is supposed to EXPAND the RCX's capabilities, not replace them. I
don't expect to send motor commands over the cel phone :P even though for a
bomb robot it would suffice.
> > But I haven't opened the RCX, maybe there's a port which can be used for
> > direct serial, (parallel) or USB cable transfer ? Has anyone built a cable
> > data interface PC<->RCX?
> Well, the IR interface is basically a serial port - so you probably could
> hack the hardware to connect the RCX directly to the PC - but if the PC
> is the brains, you don't need much bandwidth to the RCX and the IR link
> should be just fine for the job.
Before you complained that there wasn't enough bandwidth to transfer images
to the PC, and now the IR link is enough?
> If the 'brain' is a PDA, then getting it to talk to the RCX using IR
> would make a lot of sense. However, not all PDA's can do that because
> the IR port on the RCX is like a TV remote - and not like the irDA port
> that most PDA's have. You need a PDA that can act like a 'learning remote'
> for your TV.
The reason I brought up "opening the RCX" and "Has anyone built a cable data
interface PC<->RCX?" was because it's easier to solder a couple wires than
use an IR comm that I don't know much about. Why, then, do you say it makes
sense using IR, and then bring up the technical problems with using IR? :)
The point of a cable would be that you might expect potentially higher
bandwidth from it - to transfer images. Because the PDA and RCX would be
close together, you could make it short and shield it if that would improve
the rate.
Don't get me wrong Steve, I'm here to make friends and not enemies - I
respect your technical knowledge, for example. But sometimes you get too
expansive and see technical complications with issues that you invent and
doesn't even come from my ideas!
To put it simply:
* Wouldn't a cel phone in the robot give a link to your PC? Thus relieving
you, in a low-cost way, of the limitations of the IR tower?
* Couldn't you press the buttons to call any function? At the very least, it
could be used to give the robot a 100-word prerecorded vocabulary, or
eavesdropping (with sound analysis).
* Isn't it more generic than buying a microphone set and a speaker set and
use the extreme limitations, soundwise, of the RCX? Everyone has a cel
phone! (And even with a mike and speaker you'd still have to transmit the
sound somehow or use the RCX for sound analysis...)
* If someone wrote a program (for the PC, using any language) which samples
the PC's sound input and detects DTMF tones, and users were able to connect
a DTMF number with any executable file, couldn't the robot do just about
anything your PC could?
This is my vision of it anyway, and I can't see why this wouldn't work.
I hope you don't take offense by me criticising you a little. ;-) I just
wanted to bring this technology forward with simple means, and you seem a
little too eager to confuse the thread with technical problems with detail
issues, when the general issues aren't even addressed yet.
It's not that I don't want to "get technical", I love technical! (If you
want to know my technical level, I've made an EPROM programmer (par. port),
a tiny microcomputer (Z80-based), created misc sound and data compression
algorithms, and written misc. utilities for PC/Windows, including a complete
Z80 Cross-assembler and a DirectX 3D game. I program in Delphi, and
assembler, and C.)
|
|
Message has 1 Reply:
 | | Re: A Generic Idea
|
| (...) Ah - OK. But other things in the world (like people) are moving around - it's not always going to be possible to stop, capture a static image - and then reliably navigate based on it. I guess there are niches where such a robot could be (...) (21 years ago, 6-Jan-03, to lugnet.robotics)
|
Message is in Reply To:
| | Re: A Generic Idea
|
| (...) Yeah - but the amount of CPU horsepower to do that (on the robot remember) is comparable to the horsepower you'd need to extract the edges and do some simple image recognition. So why transmit the image at all? (...) Yes - but they don't (...) (21 years ago, 5-Jan-03, to lugnet.robotics)
|
38 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
