Community Blog Buy Now
Blog

Misty Community Forum

Misty VM; contributions welcome!

I am making a VM-like program that simulates behavior of a Misty robot. My goal is to reduce development time by allowing quick testing against a program that mocks the Misty APIs and runtime behavior. This will be useful for other activities, e.g., as the basis for supporting Misty in a simulator like Ignition.

The initial implementation is part of a static analyzer called mistygrind, which is implemented mainly in Python, with some JavaScript. If you have Python 3.5 or higher, try

pip install mistygrind
mistygrind --vm

Then, in your web browser go to the Misty Command Center, and in the address box enter 127.0.0.1:8888

Coverage of the REST API is in progress.

If you want to work on this, reply below, and we can coordinate with issues on GitHub. Though development began in Python, I think that switching to another language and starting a repository dedicated to a Misty VM might eventually be better. Let me know your thoughts!

1 Like

Unfortunate naming aside, this is a great project :stuck_out_tongue_winking_eye:

ha! I was motivated by the name Valgrind, but I am happy to consider other names.

Hey @slivingston I made this a while back and you might find this interesting but I made a mock of Misty’s api with openapi and stoplight.io GitHub - KyleGrieger/misty-openapi: The Misty API Open API Spec right now it does driving commands but once you have an openapi spec you can generate client libraries in any language and run a mock server as well as a server on another device and bind the commands to the appropriate hardware action like I did with a raspberry pi + Sphero RVR and jetbot. The server is written in python so in theory a binding layer could be written for any hardware that has a python library. Also, openapi specs can be run as a server using pretty much any other language as well. https://vimeo.com/394787900 Cheers!

@kyle.grieger thanks for the reference about prior work. I will study it!

Actually I know OpenAPI, but I thought it would be more flexible to manually implement the Misty API to

  1. to better support debugging and special features like tracing some requests, and
  2. because the Misty API continues to evolve in ways that are not backwards compatible.

I like Open API cause you can auto generate client libraries from a spec as well as serve an api from the same spec. In terms of tracing I don’t have too much experience implementing tracing/debugging solutions with Open API. In terms of backwards compatibility, I think you can publish various spec versions via stoplight.io and github which I might do in the future if I get around to it.

As always, best of luck with all of your endeavors!