internet remote control

This is a great question in as much I have never seen it covered end-to-end.

First of all, you need to create a website or something that you can access
from the internet. That alone is sort of a chore. Using DSL or Cable you
can never really depend on your IP address unless you specifically order
one which does not change.

The internet web server port, 80, is usually blocked depending on your
provider. You can usually setup a web server on another port and access it
as http:myipaddress:myport

Then, you need some sort of web application which can talk to your robot. If
you use Linux or FreeBSD (or any UNIX really) you can cobble things
together using ssh, or whatever. Using Windows, it is harder.

Essentially, you need to write something in some web application language
that can send commends to your robot. You can, maybe, use off the shelf
webcam software to return feedback.

I know this is probably not the depth you wanted, but for the most part it
is doable, it is just stringing together a whole chain of applications to
do it.

"mlw" wrote
<snip>

Nice explanation, just a few comments.

Harder in what sense? And harder for whom? Not trying to incite another
languague/environment/OS flame war, but it is only harder if your knowledge
is more inclined to linux. How much easier it is in linux from creating a
class in C# and dragging it to an ASP page using ASP.net?

Padu

This is along the lines that, "if you have to ask the question, the answer
probably won't help you."

While I am, yes, being flip, here is the *easiest* UNIX based end to end
robot control.


ssh into the robot from the internet, and run a console or GUI application
remotely using ssh -X.

Run webcam application on robot and connect with local browser.

Done.

I have done this by once. I had a webcam placed on the shaft of a
steppermotor, connected to the web server. The aim was to turn the cam to
the left, or to the right. I had a web page with two arrows placed on it:
one for turning left, one for turning right. Pressing the left arrow called
a small program om the web server which turned the motor a few steps to the
left. The other one for the oposite direction. Pressing an arrow more then
once made the cam turning more and more in one direction.

Steve

I have mounted some wheels onto my laptop and I am going to have to
figger out how to control it over WiFi soon, so I would like to know
more about this sort of thing too.

More simply, I would be interested to see a tutorial on how to
communicate a bidirectional data stream between a pair of PCs on my
home network. The next step is to seperate those PCs over the internet,
assuming the IP addresses are known.

-howy

 > i want to learn how to control, say, a motor, remotely over the
 > internet. does anyone know a good resource for learning the basics of
 > this? thanks.

A complete reference?  Sorry; I don't have one.  However, here's my $0.02US.

Unless your project is for other people who don't like installing
programs, don't try interfacing with a web browser.  They really
restrict what you can do.  Webpages tend to be static; browsers were not
meant for real-time applications, although things are improving in that
regard (e.g. Ajax).  A custom application gives you a lot more freedom
with the types of commands you can send and receive.

A few years ago, I would have recommended using Java.  Right now, my
personal bias is leaning towards Qt (C++).  If you don't mind the GPL,
Qt is free for use; get it at
http://www.trolltech.com/download/opensource.html

Cross-platform C++ goodness.  In addition to their GUI libraries, they
have a few easy to use networking classes.  For example, I've used these
to stream camera images across a local network.

There package comes with a whole host of example programs, including
example network programs; you can see what these are on their website:
http://doc.trolltech.com/4.1/examples.html

Other than the difficulties with networking, the added time delays can
introduce interesting problems.  Basically, you want the actual motor
controller near the motor and sensors.  If you try sending the control
signals over the network, they can arrive to late; this can lead to
oscillation, just like an echo down a long hall.  In short: the user
should send target positions to the robot; the robot has a local
controller that knows how to achieve these goals, and it sends frequent
status updates back to the user.

As long as you don't need force-feedback, people can easily adapt to
moderate delays.  Less than a tenth of a second are not a problem.
Visual feedback delays over a second may become annoying, and result in
operator impatience.  Finding effective ways of dealing with this is
actually a hot research topic right now (teleoperation).  Aggressive
approaches use a local simulator to approximate what the remote system
is doing, and feedback is used to keep the simulator accurate.  In order
to avoid oscillation caused by delays, such systems generally present a
"soft" or "squishy" feeling to the operator; this keeps the operator
from reacting too fast.

Later,
Daniel

Depends on the skill of the developer. The real problem is the
unknowable and uncontrollable latency. You can easily send a
'motor start' command, and it will start sometime later.
And a 'motor stop' command will also happen. Whether that
is acceptable is a question of the application.

If you are controlling the fan in a home A/C, it is fine.
If you are controlling the drive motor of a robot installing
a windshield in a car, it is not so good.

Once upon a time GM invented their own networking
protocols because hardwired Ethernet had too much
latency.


The first part of this is incorrect these days.
The second part is correct, still.

It depends on how 'soft' the control has to be, but
in general, seems like a bad idea to me.

--
Pat