Remote Sensing and Control with Netmeeting
The aim is to set up a system that will allow 'remote' sensing and control across the Internet. Solutions exist, but generally involve very expensive software, or a command of CGI, or Java programming. The technique described below is one solution to the problem and it's FREE!
The basic approach is to set up a Netmeeting between the 'master' computer to which is attached a camera, sensors and an output interface and a 'remote' system connected across a LAN, or the Internet. In this case a light sensor is attached to the Games Port (see: http://www.southwest.com.au/~jfuller/logotut/games.htm ) and the output is connected to the Printer Port (see: http://www.southwest.com.au/~jfuller/sio5.html ). I have chosen MSW Logo as the 'control' software, but any 'executable' package would work.
The Steps ...
1. Launch Netmeeting and connect the two systems (either on a LAN, or across the Internet).
I had problems using Netmeeting 2 with Netmeeting 3. I suggest you use Version 3 on both systems. The software can be downloaded from: http://www.microsoft.com/windows/netmeeting/
2. Open the software you intend "sharing" (In this case, MSW Logo.) and minimise it to the Task Bar.
3. In Netmeeting go to Tools/Sharing.
4. Click on MSW Logo Screen (or any other software you wish to share) and click the Share button.
The Allow Control button will become active (click on it). If you select the Automatically accept requests for control option the remote user will be able to gain control without your intervention. Leaving it blank will pop up the dialogue below, requiring your approval before a connection is made. (After you click the Allow Control button it changes to Prevent Control as indicated above.)
5. The Control window below will appear on the 'remote' system. Select Control/Request Control
6. On the 'master' system open MSW Logo from the Task bar. The package will now be available in the Control window on the 'remote' system ...
Any commands you enter on the remote system will be activated on the master system. You can run files directly from the master system. In effect, the remote system becomes the user interface for the master system. You will no longer be able to operate the master from its keyboard, or mouse (until the remote user releases control, or you press a key on the master system). If you have 'real world' interfaces connected to the master system you will be able to see input from the Games Port and control devices connected to the Printer Port.
It's not fast, but it is cheap and simple!
NOTE: In the example above, the remote user has TOTAL control over the master system. Since MSW Logo is able to carry out system-based instructions like deleting files, I would not recommend providing this sort of access openly. It would be preferable to write a small 'executable' I/O file with limited functions and allow the remote user access to that, rather than your entire system.
General Comments:
NetMeeting generates a LOT of web traffic (especially when video is used). Some
Internet Service Providers (ISPs) will charge you for traffic, regardless of whether it is
within their 'catchment', or external. Check before you start experimenting. Peel District
schools using South West Internet Systems (SWIS) are fortunate in that SWIS is only
concerned about 'external' traffic that actually costs them money. If the traffic is
kept 'internal' between other SWIS clients, there is no extra charge.
(Also see: http://www.southwest.com.au/~jfuller/netmeeting/netmeet.htm)
Good Luck.
(With thanks to Garry for the suggestions and support.)
So What? - What do we do with it now?
Some possibilities ...
1. Set up just ONE master system with input and output devices and allow individual
students at 'remote' systems in the classroom to test their code.
2. Connect a Robot arm to the master system and allow students at remote systems in the
classroom to take turns controlling it.
3. Set up 'environmental sensing' probes (eg light and temperature) in one area of the
school (on the LAN) and have students collect data, save it on their own systems and
present the results in graphical form.
In each case above, only ONE set of interfaces is required for the whole class.
4. Perform similar activities across the Internet
with 'trusted' schools who perhaps don't have the hardware, or expertise to set up the I/O
interfaces. Students at the 'remote' school will be able to see the results of their
commands. This sort of activity could be carried out in the same District, State, Country,
or even across the World!
5. Set up a 'robot' web camera and allow remote systems to control its field of view.
Use the robot web camera as a 'security' camera.
Set up a 'mock' traffic, or railway Control Centre using model race
tracks, or railways.
Connect a long cable to the web camera and have students remotely
control a vehicle along the lines of the Mars mission.
Make a model head, or full bodied person (or animal) and 'interact'
with visitors at an exhibition.
6. etc, etc, etc.
I'm sure there are lots more ideas you can come up with. Please drop me an email and I'll include them here ...