Arduinos In Space: Arduino library for OiS controllers

[stibbons]

I’ve been putting off designing hardware until I’ve logged a fair bit more time in game. But that doesn’t mean I can’t work on the code for it, right?

Arduinos In Space is a library to encapsulate the OiS serial protocol and provide what I hope is a friendly, easy to use interface while still being fairly fast. As an example, here’s a demo that lights an LED when EMCON is active

#include <ArduinosInSpace.h>

const int ledPin = 13;

ObjectsInSpace OIS(Serial, 1);

void setup() {
  // Open the serial connection and perform handshaking
  Serial.begin(9600);
  OIS.begin();

  // Synchronisation phase
  // We register data we want to receive, and associate it with an output pin
  OIS.registerBool(EMCON_MODE, ledPin);

  // Complete synchronisation and activate the link
  OIS.activate();
}

void loop() {
  // Check for new serial data
  OIS.update();
}

All known request and command types are supported. The library includes example sketches covering sending command and requesting different kinds of data, as well as integrating with some external devices.

ArduinosInSpace is still in development, but is slowly edging towards completion. Refer to the README at https://bitbucket.org/pjhardy/arduinosinspace for installation and getting started documentation.

[Nocturnal]

Looks good. A generic callback within the library to handle simple buttons and leds might be a good addition, especially since it’s likely to be the major use case. I’m assuming with the callbacks, channel is the unique number assigned to each request type. So one callback function can handle multiple requests. Something small that seems to be missing, instructions on downloading and “installing” the library for people not familiar with the process. I didn’t look to closely, so I might have missed that.

I look forward to trying it out with this.

[stibbons]

Just pushed a 0.2 release. This changes how callbacks are handled - the library now takes care of converting data from the game. I think I’ll be adding “raw” callbacks back in, to get similar behaviour to previous versions. But removing the need to manage data types like that was one of my goals.

At this point, barring any major problems, the only real work left to do is flesh out the API docs and write some more examples. Should be ready for a general release after that.

[stibbons]

A generic callback within the library to handle simple buttons and leds might be a good addition, especially since it’s likely to be the major use case.

I’ll have a think about a general way to do this that covers most use cases. But to be honest it’s not a major priority.

I’m assuming with the callbacks, channel is the unique number assigned to each request type. So one callback function can handle multiple requests.

Yep, that was the intention. Right now the register functions return a boolean for success/failure. But changing that to return the ID instead sounds worthwhile. There’s no real elegant way to get the IDs otherwise, except knowing that they’re deterministic and increment in the order they’re added.

Something small that seems to be missing, instructions on downloading and “installing” the library for people not familiar with the process. I didn’t look to closely, so I might have missed that.

That was slightly deliberate. Once I’ve got a stable release it’ll be installable via the Arduino library manager, and I have a strong preference for automatic installation. Until then, I’d suggest grabbing the zip file from the repository downloads page, and install it following the Arduino library docs. Will add that to OP.

[stibbons]

And because hacking code on the train is fun and exciting, I’ve finished a 0.3 release. From the changelog:

• Added registerBoolRaw(), registerIntRaw(), registerFloatRaw() to handle data requests with a “raw” callback - this callback receives the int from the game directly with no postprocessing.
• All register functions now return an int instead of a boolean. This int represents the channel ID of the request - it correlates to the channel int passed to callbacks. A return value of -1 indicates failure - the channel was not registered. This is a breaking change.
• Refactoring of the registration code. Even with the other changes existing example sketches clock in at a handful of bytes smaller.

[stibbons]

Move fast, hopefully don’t break anything major. I’ve pushed a 0.4 release to bitbucket. The changelog:

• Added some debug code with an error callback. #define OIS_DEBUG, then add a callback using the errorHandler() method, and the callback will be called when errors are caught. Currently only alerts when the serial receive buffer is full.
• Shuffled some code around for tidyness.

The library is as feature complete as I can think of. My basic tests work, will hopefully find some time to build out a larger demo with a number of different inputs and outputs before OiS goes early access, to make sure nothing goes haywire at scale. But at the very least I plan to have more complete docs than the README, as well as a real, slightly easier to install release.

[Segwegler]

Do you mind if I add this to the wiki?
https://oiswiki.sysadninjas.net/wiki/Arduino_Librarys

[stibbons]

Minor 0.4.1 release fixing some bugs in the float request handling

• Send correct command for float request.
• Convert float data properly.

I also realised there’s some other things that need to be fixed, but it’s late here.

Do you mind if I add this to the wiki?

https://oiswiki.sysadninjas.net/wiki/Arduino_Librarys

Oh! No I don’t mind. I’ve gone ahead and taken the liberty. Also started to flesh out what I’ve learned about data returned from the game in the Serial Requests page.

[stibbons]

Last update before Early Access. For 0.5 I’ve rewritten the serial receive code, and it’s much more stable under heavier traffic. Still needs some work, but it’s less embarrassing at least!
A little sad that I’m skipping out of town and will miss the EA launch. But on the plus side I’ll be drinking craft beer in front of an open fire, so it’s not all bad.

[taotetek]

Hello! Is it possible to connect to Objects In Space from a program running locally on the computer the game is running on? It looks like it should be, but I can’t find any documentation on how to find the virtual serial interface the game is using, etc. I have some ideas I’d love to try out, just looking for enough info to get started.

[stibbons]

Not sure. This thread is only about some Arduino code I’ve written.

That said, it seems fairly simple to do if you write some code that creates and listens on a virtual serial port. In Windows, the game scans COM*.
(I’ve been mildly interested in doing something similar on macOS, but haven’t yet figured out the foo to get something like pyserial to listen on a pty interface)

[smt]

I’ve been wondering about this too, very interested in having the same capabilities exposed over a local network port if possible, though I’m going to try messing with virtual serial stuff too

[Nocturnal]

If your on mac, have a look at socat.

I wonder how long until someone tries making consoles for a multiplayer experience similar to star trek bridge crew.

[taotetek]

Do you know how to determine which serial port the game is connecting to? Does it send data to every COM port? I’m familiar with serial programming (used to program modems, hah) but I’m not certain how the game determines where to send its data

[stibbons]

I’ve only tested this library with Arduino-compatible boards with Atmega16U2 serial-USB chips. No problems with Windows or macOS. I’ve read other threads reporting that the game only seems to scan /dev/tty.usbmodem* on macOS, so FTDI or other serial chips may need some symlinking to work. But all signs point to the game just probing every COM port on Windows.

[Nocturnal]

It scan for com ports, I can’t tell you how far it goes. It’s probably also looking for multiple com ports. The “official” controllers use multiple arduinos, so multiple com ports.

[stibbons]

A generic callback within the library to handle simple buttons and leds might be a good addition, especially since it’s likely to be the major use case.

Swinging back to this, I’ve written the bits required to set a pin on and off for boolean data requests. That will be in a new release this week.

I’m not sure of a nice way to deal with inputs though. Doing button debouncing in the library is possible, but I’m not yet convinced I can make it fast, portable and scalable. Although to be fair I’m not happy about the existing code using relatively slow digitalWrite(), so I guess I’ll just write it up and see how well it runs.

[Nocturnal]

If you limit polling the buttons to around 10-20 times a second, debounce shouldn’t be necessary.

[stibbons]

I’ve just uploaded version 0.5.1. This release just cleans up the existing code, fixing compiler warnings and what looks like a pretty nasty edge case that’s technically undefined. No user-facing changes, but if you happen to be playing with this code I’d strongly suggest grabbing the latest version.

Over the weekend I’m hoping to take some time to finish up the code for the new release, as well as flesh out the test suite that drove these fixes.

[creativesamurai]

Hi stibbons, i finaly got round to playing with my arduino. iv compiled ur example engine script and uploaded it. but when i run the game the arduino just continues to try and handshake. the game doesnt respond. i can for the arduino to respond by sending any text data down the serial monitor. have i done something wrong?