Tag Archives: html

Simple remote controller

For some upcoming work, I needed to drive the quad A1 around without being tethered to a computer. To date, my control mechanisms have been:

Note, both of those methods involve being tethered to a computer, which makes it hard to be mobile. As a possibly short term solution to this problem, I went ahead and got a bluetooth “gaming” controller for my phone (non-affiliate amazon link):

It turns out the web interface I updated previously works just fine on the phone, as does the javascript “gamepad” interface. The only glitch was that this particular gamepad requires that you manually sweep the analog sticks through their full range of motion at each power on before they start providing correct values. Until then, they act as digital inputs. That can be a little disconcerting when the robot starts running ahead at full speed!

Updated web UI

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.

HTML + websocket joystick control

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:

quad A0 diagnostics architecture.png

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.

2019-10-25-094942_1918x1058_scrot.png
HTML at its finest