Robot Not a Dev? Pre-order Now
Not a Dev?

Misty Community Forum

Thoughts on the development experience


Hey all… I was at the Minnebar coding workshop, and thought I’d offer some thoughts:

My first attempt to work with Misty was with – a (new?) interface to upload JavaScript directly to Misty.

The experience was in a kind of JavaScript-uncanny-valley, not a normal experience:

  • console.log wasn’t available (of course we learned about misty.Debug(), but it seems unnecessary)
  • Using let instead of var seemed to cause silent failures. Oddly portions of the module would execute, instead of simply getting a SyntaxError. But it wasn’t exactly an old version of JavaScript, as string interpolation was supported.
  • setTimeout and setInterval aren’t available. Both myself and the person working next to me immediately wanted to use these functions, as it’s the natural way to do something that appears “autonomous”
  • Someone did show us the Timer functions, but we never got them to work. This might be a limitation of, which doesn’t allow for JSON metadata.
  • The way callbacks work is unusual. From the docs, nothing like a normal callback is in the API, only named callbacks.

I would recommend:

  • Implement console.log yourselves, it’s not a protected function, and you can implement it in terms of misty.Debug.
  • I think I overheard this is using Chakra. Obviously not a great platform for the future since it’s deprecated. But even so, by translating the code appropriately using Babel you can make it look like normal JavaScript.
  • You should be able to do better error catching at the JavaScript level too, to improve the debugging output. Careful use of try/catch can go a long ways.
  • Use Promises for one-off asynchronous code (like misty.GetAudioList())
  • Use an addListener/removeListener style API for pubsub-like APIs.
  • If the current APIs reflect the underlying architecture, you can still probably simulate these more idiomatic APIs, so long as the JavaScript process is long-lived.

After banging my head on the on-board JavaScript, I made a short attempt at using the WebSocket API. I was directed to the liveClient libraries, which are pretty sparse. Unfortunately I only managed to get as far as establishing the WebSocket connection in the few minutes I had left.

I would strongly recommend preferring the WebSocket client over the REST client, though currently it appears the REST client is more complete. There is a kind of simplicity to REST, sure, but a robot needs to be able to initiate events, and that can’t happen over simple HTTP. WebSockets are pretty easy to use, and with them you have a nice live message-based channel between the remote code and the robot. The only big downside I see is that it’s a lot harder to work with WebSockets from Python. Using WebSockets you can have a very similar API across remote and local development, and you can start to talk about the programming API for the robot instead of the over-the-wire API.

I think you have something that’s close, the protocols seem to expose what they need to, it just needs some hacking to make it happen.


Awesome stuff, Ian. Thanks! We’re discussing now.


have you tried GitHub - aaugustin/websockets: WebSocket implementation in Python 3 ?


I think the last time I tried this was before async/await. That it works better now is all the more reason to use WebSockets!


Thanks, @ianbicking, this is really helpful for me as I’m currently reading the documentation to become familiar with developing for Misty II.

1 Like
Javascript Impersonation Syndrome