Serial port/USB control in the game client

Serial port access from the game client would greatly increase the utility of SL. This would include direct access to standard serial ports, and USB-serial ports.

The SL client would send information out the serial port about avatar gestures or from a scripted object to a PIC microprocessor connected to the computer's serial or USB port.

There are lots of cheap dev boards on the market which allow the processor to be programmed in Basic or C, and can accept/process text strings many times a second. They can control external devices directly via pinouts, or through motor controllers.

Sensors include proximity IR, ultrasound, contact, movement, acceleration, GPS - you name it.

These same microprocessors, coupled with a dev board from companies like Parallax or Basic Microe can directly control up to 3 amps current (a large battery stack) going to a motor inside a device.

Finally the processor can send status messages/queries back via the serial port.

Examples of use:

1. A notebook based GPS - The SL client would open the port, and receive the NMEA text strings - not to difficult to process directly with a SL script. If the SL client ever gets client-side scripting, the NMEA strings could be converted to coordinate data locally and uploaded, reducing server load.

2. Private toys - pretty obvious - sensors as well as motor control. Manufacturer tie-ins.

3. A virtual exercise class - a ipod mini-sized device strapped to the RL exerciser would relay movement and acceleration (Memsic chip) to SL - this would translate directly into calories burned. This would allow a virtual instructor to direct a real exercise class and tell how well their students were doing. The use of SL avatars would provide some of the group vibe to people exercising at home.

4. Remote-controlled robots using SL as a virtual interface.

Eh, i'd rather see support for Applescript in the OSX client and some other script (VBScript? DDE?) in the windows client, then you could extend the functionality as needed with your own programs.

If you want this functionality today, maybe you could use lhttprequest and wrap a cgi script around it on your webserver

True, but using a server to collect the data requires using your local workstation as a http server, which will cause significant latency. Ditto for running an external VBscript or Apple Script. Jumping directly from the client to the serial port objects should be faster.

Doing this in the client also has the advantage of standardizing SL communications with external devices. Otherwise, each device will have to have its own local server, custom script, etc. Since serial devices are already pretty diverse it seems like a better idea to standardize where possible. Anyone connecting a serial device already has to develop custom code for the microprocessor controlling the device.

Also, the amount of work necessary to support external scripting, or to write/configure custom servers to manage serial connections is probably greater than simply exposing the standard serial port methods found in the development environments the SL client is created in. Both Mac and PC dev environments have standard serial port objects with relatively simple interfaces. Under Windows C++ (I don't know about Mac even though I used to be a Mac programmer a long time ago) it is pretty easy to discover all the serial ports, figure out if they are in use, and send and receive serial commands without writing your own polling loops - it is handled in the background and can be threaded.

In summary, this would be a pretty simple set of commands to add to the SL client, and would standardize communication with external devices, making things easier on developers.

The interface to the client should be TCP, not serial or USB, so that you can easily write your own controllers rather than having to set up a fake USB interface to it.

The best scheme would simply be to allow a script in an attachment to open a listening socket and connect it to a channel... then you could test your script with llSay(), debug it with listen(), and so on...

The channel would open at (say) port 22000 + the "port" paraneter to llSocket().

writes to the port would come out as says on the channel, and vice versa.

integer chan; = llFrand(31768)+1000;
default
{
  state_entry()
  {
    chan = llFrand(1000)+1000;
    llListen(chan);
  }

  on_rez(integer p)
  {
    if(llGetAttached())
    {
      llSocket(1, chan);
    }
  }

  listen(integer c, string n, key k, string s)
  {
    if(c != chan) return;
    if(s == "hop") llApplyImpulse(<0,0,10>*llGetMass(), FALSE);
    //...
  }
}

Would this method work with a microprocessor-based device plugged into my local computer via the serial or USB port?

Sure, you'd just need to write an interface program that talked to the SL client on the socket and to your device on the serial or USB port. You'd pretty much have to write a custom interface between your device and SL anyway, no matter what protocol they use, so it might as well be one that's easy to prototype and implement for more than just serial devices.

The only thing the devices I am thinking of typically can do is run standard serial communications at a low speed (e.g. 38.4k). They aren't sophsiticated enough to run a network protocol like TCP. This is because to keep them cheap you use a PIC-style single-chip computer with very limited speed (4MHz) and performance(2k RAM). They don't have any operating system at all - just a single, dedicated program.

So writing the protocol for a microprocessor-controlled device is usually extremely simple. The device accepts a finite set of commands via serial port only and can write back a small set of strings. The typical program managing this plus reading sensors and/or writing output is under 100 lines of Basic or old-style C code for something like a variable-speed motor or accelerometer set.

In contrast, using an intermediate server-style program is work - somebody would have to write and support the software, which would be far more sophisticated than a simple microprocessor program. Then you still have to write the microprocessor program. Either you would have to create a server for each kind of microprocessor you wanted to hook up (meaning two programming jobs) or use a generic system requiring either purchase/licensing.

With the server middleman you also create a new locus for attacks - particularly if you allow TCP in/out through the system.

So....I see a direct serial port via the SL as better for controlling these kind of devices. If the SL client allowed simply reading/writing short strings (80 characters) to a serial port, along with COM port discovery one could get an external device running via SL in a matter of minutes. Since the SL client was doing the connection, and there was no network protocol other than standard serial allowed, you wouldn't be reducing the security on a home user's computer.

Finally, the work needed to implement it in the SL client would be low. Enabling serial port communication is not a major project, and the slow speeds of connection would be unlikely to zap the client's regular work.

That being said, I'm probably going to explore just how hard it would be to make a simple(?) middleman server that can handle TCP/HTTP. This would allow some demonstrations of the external device idea using the current HTTP ability. But i'd sure prefer a couple of serial port open/read/write/close commands that could be triggered from a remote script in the SL client - I'd have a working demon by lunch.

You're talking about teledildonics here... You should find a lot of support for this suggestion if you just come out and say it.

Paging qDot Bunnyhug to the thread!

In the mantime check out www.slashdong.org (Warning: as the name suggests, the focus of the site tends torward the afforementioned "private toys" and the tamer Nonpolynomial Labs at http://www.nonpolynomial.com/ . The general setup is LSL -> XML-RPC -> DirectX I believe.

They wouldn't run TCP/IP.

You would run a program wherever ytou're running SL that would talk to the serial device and to the TCP port. That way it would work with your USB sercial devices, your real serial devices, the 8 strings of christmas lights you're driving with relays on the parallel port, and everything else. You just need a small C, Tcl, Perl, Visual basic, Bash, Python, or whatever program to handle the protocol.
That's true, and that's true whether that someone is you, me, or Linden Labs. If it's Linden Labs, ever time there's a change in the serial port hardware model (like, say, the new version of your keyboard switches from USB IR to bluetooth with a widcomm stack) you'd have to wait for LL to update it.

Erm, we're talking 20 lines of Perl or Tcl or other PC/Mac/Unix scripting language. And you only have to write it once. And it would work with anything, including:

Konfabulator/Yahoo widgets on Windows or Mac.
Dashboard widgets on Mac.
Jscript and VBscript on Windows.
Any scriptable game enhancers.
Standard Microsoft Human Interface Devices - USB, Bluetooth, or PS/2.
Standard Macintosh Human Interface devices - USB or Bluetooth.
Serial devices on Mac, Windows, or UNIX.
Applescript glue on Macintosh, including iTunes integration.
IRDA and IRcomm devices.
X10 devices (usb and serial).
Bit-banger and bit stealer interfaces... you can talk to your microprocessor on COM1 as well as use the CD line on com1 to monitor whether your window's open...

TCP/IP listeners on localhost don't open you up to any kind of attack. Part of my job for the past 15 years has been network security, and if there was a remote hole in a localhost-bound port things would be a lot nastier than they are now.

So is it true that the new LSL commands for sending/receiving HTTP can contact the client computer via localhost? This doesn't seem to be the case.

Localhost would only work if the SL client was driving the server locally. As I understand it, LSL commands involving http input/output execute on the SL servers. So, unless Linden decided to support driving local servers, a localhost server would not work.

We would be back to a net-available server driven by LSL commands.