I first wrote about the very very simple web UI for the quad A1 some time ago. That UI served its purpose, although it was largely inscrutable to anyone but myself, as the primary data display was a giant wall of unformatted JSON which filled most of the page. It was also pretty easy to accidentally pick the wrong mode, cause the robot to jump instead of walk, or cut power to everything.
In advance of some wider testing, I went ahead and made the first revision to this now. It has the same basic structure as before, in that the robot serves up one each of an html/css/js file, and provides a websocket interface for ongoing command and control. The change here is just that the html and javascript are even minimally usable:
Clearly I’m not going to win any design awards… but since all the styling is done with CSS, it should be not too hard to make something that looks arbitrarily nice without a whole lot of effort. As a bonus, I also added some minimal keyboard bindings for movement, so the joystick isn’t required if you don’t care about precise or aggressive maneuvers.
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.
A Modicum of Fun 