Now that I had a controlled jump with the quad A0, I wanted to chain those jumps together into a pronking gait.  The first part of that was creating a mechanism by which I could actually command varying motion commands.  For the previous full rate experiments, all I had built was a CLI that allowed you to type commands.  That sufficed for initiating a single jump, but not really for moving around in space with a dynamic gait.  Something with a joystick would be necessary.

For Super Mega Microbot, we had a Mech Warfare dedicated client application which, for various reasons is something I want to get away from and its control protocol isn’t even that suited to the things that the quad A0 is capable of anyways.  For the quad A0 I want to eventually have 2 command and control systems: a high bandwidth one that uses wifi, and a low bandwidth robust one that uses a spread spectrum RC style transmitter.  For now, I figured I would start by making a first minimum viable product of the high bandwidth diagnostics tool, since it would be more useful initially.

Architecture

The intended system roughly looks like this:

The client in this case is a regular web browser.  It connects to the embedded web server which is running in the robot control process and fetches some static assets, including HTML, CSS, and Javascript.  Then, the diagnostics client is a single page javascript application which makes a separate websocket connection to the embedded web server for real-time control and status data.

Implementation

Initially, I spent a half day making a standalone proof of concept server and client.  The server was based on boost::beast / boost::asio and the client was vanilla JS using the gamepad API.  All it did was render the state of the joystick into a text string at 10Hz, stick that into an HTML element and send it over the websocket connection.  Anything it received over the websocket connection it stuffed into a different HTML element.  The server just sent an incrementing number over.  Once this was working mostly well enough, I felt confident enough to move on and integrate it into the actual robot control application.

For that, I implemented a more generic “WebServer” class which just serves the static files and accepts websocket connections at configurable endpoints.  Then a separate “WebControl” class uses WebServer to report the quadruped status and send commands.  For now, I just exposed the raw C++ status and command structures over the websocket interface as JSON, so the control class doesn’t have a whole lot of work to do.

On the client side, I spent zero effort on presentation, and just dumped raw JSON into HTML elements for now.  There is minimally enough logic to command the robot through the states that are implemented now based on joystick commands.  The result is just about the ugliest web application you can imagine, but it gives me a place to start from both to make it more functional, look nicer, and more importantly lets me once again use the joystick to command variable gaits.