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.

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

"mlw" wrote

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

You can use the apache web server as a base for controlling simple things over the internet. Below are some setups using the serial port to control servos and some simple parallel port setups.

bob wrote: > 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

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:

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.

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.

The speed is available, but Internet needs an upgrade ;-)

Hi,

Go have a look at my website. The webcam is controlable through the internet. It consists of an AVR,NE2000 nezwork card, 2 RC servos, and a Display I ripped from a cash till. The AVR is programmed in Bascom (Basic dialect) and the NE2000 driver is a standard LIB available from the website.

Web browsers communicate with the AVR with UDP.

Regards Ian Dobson

Home of the Atmel based UDP mobile web cam

"Si Ballenger" schrieb im Newsbeitrag news: snipped-for-privacy@news.comporium.net...

Below is an avr setup I tried to duplicate a long time back, but couldn't get the chip to program.