Category Archives: robots

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.


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.


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.

HTML at its finest

In my quest to create a more dynamic quadruped, I’ve started accumulating a lot of parts from bulk buys that could be reasonably useful to other hobbyists and experimenters.  To maybe make life easier for everyone, I’ve started up what may be the worlds ugliest online shop where you can buy some of these components.  For now, I have some bearings and custom gears that are useful when building servos for dynamic robots.

Check it out!

Unfortunately US shipping only for now, email me or DM on discord to arrange something internationally.

Some samples of what I have online now:

M0.5 100 Tooth Steel Ring Gear


55mm +0/-0.02 mm outer diameter and 5mm width, only $17 each.

M0.5 20 Tooth Sun Gear


5mm tooth width, 4mm ID bore, 8mm OD hub, only $6

6708-2RS ABEC-1 Bearing 40x50x6mm


50mm OD, 40mm ID, 6mm width, only $8



quad A0 chassis v2 – construction

After CADing up the second revision of the chassis, I set to work with the 3d printer and printed up all the pieces.


There were a few minor post-modifications I had to make, which were all much faster than printing the pieces again.  All the holes for M3 bolts were slightly undersized, so I drilled them out.  The battery holder had a channel to let the power wires out, which inexplicably terminated before reaching the edge of the holder.  I also had to install all the heat set inserts.

Mostly assembled
All put together, with a snazzy new sticker

I did attempt something new, which was to post-process the printing by smoothing out a corner by sanding.  An experiment it was.  I spent about 2 hours on it, of which 45 minutes was on the coarsest paper I had, about 80 grit.  I eventually gave up on that coarsest grit and started moving on, so there are still a few blemishes in the final result.

Smoothed out corner

Needless to say, until I get really bored, I probably won’t spend the full day required to do the other 3 corners of the chassis using this method.

There are a few other minor changes I’ll make before installing legs, which will be the next step!

quad A0 chassis v2 – design

As described in my roadmap, the chassis for the quad A0 was on the verge of failing, or causing the shoulder motors themselves to fail, after only a few hours of walking around.  Also, it was nigh impossible to assemble, disassemble, or change anything about it.  Thus, the chassis v2!


More than one piece

The old chassis was a single monolithic print that took about 35 hours of print time.  Because of its monolithic nature, there were lots of interference problems during assembly.  For instance, the shoulder motors could only have 4 of the 6 possible bolts installed, and 2 more of the bolts extended beyond the chassis entirely.  I decided to break it up into multiple pieces, which uses a lot more inserts and bolts, but should allow for a feasible order of assembly and manageable repair.

Now there are separate front and back plates, to which the shoulders can be attached in isolation.  Then the top plate can attach to that, followed by the side plates, the battery holder, and eventually the bottom plates.

Enclosing the electronics

V1 had the primary computer sitting on top of the chassis.  That was a legacy from the first Mech Warfare configuration, where the primary computer sat in the turret.  I’ve decided that for Mech Warfare, I’ll just put a second independent computer in the turret, which frees the robot computer to be placed inside the chassis where it is much less likely to get mangled.


The power distribution board is now mounted to the other side opposite the computer, instead of on the now top-plate.

Power switch and strap

I’ve left room for a recessed top mounted power switch on the top plate.  This should remove the need to unplug and re-plug the battery any time that power needs to be cycled.  That hole is marked in red below.


Also, while I’m at it, I left holes in the top through which a carrying strap can be threaded (marked in blue above).  The old chassis had some M3 inserts that I screwed eye bolts in and then threaded some cord through.  That didn’t work terribly well and was unsightly.


As mentioned in the roadmap, I was going to try and replace the battery with something with a smaller form factor.  I looked through a number of batteries, and got a Milwaukee M18 as the best of the options, but ultimately decided that the Ryobi style was the best compromise for now despite the wasted space.  All the lower profile ones required insertion sliding in from the side, which would have required that the chassis be much longer than it was already.


Thus, I still have the 3D printed Ryobi battery holder, only now it attaches to the top plate with just some bolts instead of a complicated dovetail arrangement I had previously.



Since this is being printed in multiple pieces, I wanted a separate piece to increase the longitudinal stiffness.  That is now just two plates which bolt to the front and back plate, and to the battery holder.


Next steps

Next up is printing and assembling this chassis!

quad A0 – Controlled jump

Now that I have a full rate inverse kinematics and dynamics solution, I can begin to do more interesting things.  A while ago I did the first jump on the quad A0 — in that video I used a limited technique just to verify that the platform was indeed capable of jumping.  The joints were commanded in an open loop fashion, and really only at the transition points of the jump sequence, relying on the control loops in the servo to actually achieve each stage of the jump cycle.  That resulted in the jump only being minimally controlled… tracking errors would result in the robot taking off from a not-level position and the timing was not super reliable to boot.

Now I’ve taken that demonstration to the next level by controlling the full position, velocity, and force profile of each of the 4 legs at 150Hz during the jump maneuver.  In the launch phase, all four legs follow a constant acceleration trajectory while maintaining a level body.  During the flight phase, the force is cut to the legs and the velocity of each leg is monitored.  A few milliseconds after the legs have been detected as moving, the velocity is sampled and a controlled constant acceleration profile is selected which results in zero velocity when the robot reaches its initial takeoff point.  After that, it just moves at a constant velocity back to the starting height.

Next up is chaining these together into a pronking gait.


Full rate inverse dynamics on the quad A0

Last time I updated my inverse kinematics solution to also include dynamics, velocities and forces.  Now I’m in the process of integrating this onto the robot.

The old SMMB / HerkuleX control software commanded the servo positions in an open loop, which did not take into account the actual position of the joints in any way.  What I’ve done now is implemented a control flow where at each cycle the state of all 12 servos is sampled, then the control laws are applied based on that state, then the resulting commands are sent out.

So far, the only control laws I have ported are a simple one which just sends raw commands to each joint, and a somewhat more useful one which commands the end effector of each joint in terms of position, velocity, and force.  Here’s a quick video showing it commanding various constant forces with no position constraints.  The scale isn’t super accurate, nor is the actual force coming out of the device, but I think it should be good enough.

Mammal IK (and now dynamics) revisited

A while ago I derived some closed form solutions for the inverse force dynamics for a 2 dimensional mammal geometry leg.  Now that I want to execute more dynamic gaits, I need to be able to control the velocity and force of the 3 dimensional leg in real time.  That means I need to be able to go forward and back between the two representations.  The first being joint angles, joint velocities, and joint torques — the second being 3D position, velocity, and force.

Rather than derive those myself in 3 dimensions, I decided to save a bit of time now by using the DART kinematics and dynamics routines.  I might need to undo this later if it turns out to be too slow at runtime, but if nothing else it can be a good ground truth for anything I do myself.  I also took this opportunity to do all calculations in consistent rational coordinate frames, where before I had conventions that while documented, were rather unorthodox.

As it turns out, this demonstrated that my old 3 dimensional force calculation, was as I had expected, slightly incorrect.


The shoulder torque was the most affected, being off by 20% or so.

The source is at:

Next up will be using this to actually control a real leg.

mjbots discord server

Over the last couple of months, I’ve had an increasing number of people looking for help with self-built moteus controllers which is great!  However, until today there hasn’t been a great way to get help.  Blog comments fall off the front page quickly, and there is no real other mechanism.

Thus, I’ve created a discord server:

There you can chat about the moteus controller, servo, or the quada0 and get feedback and help in closer to real time.  Thanks for collaborating!

Failing more gracefully

My outdoor filming for the project update video was cut short when the machine cut power to the motors, fell down, and one of the legs snapped off.  Fortunately, I already had plenty of footage when that happened, so it didn’t really impact the video.

Robot down
Nice infill shot

First, this demonstrates the not too surprising fact that this particular part of the leg design could use to be improved.  Second, and the topic of this post, is improving what the machine does when the inevitable failure does occur.

What happened — just the facts ma’am

In this particular instance, I had been running the machine outside continuously outside for an hour or so on a relatively warm day.  This iteration of the servos has basically no heatsinking whatsoever on the servo control board.  With the gearboxes, it isn’t necessary for short duration or low power testing.  However in this case, one of the servos eventually reached its temperature limit and entered a fault state.

As implemented now, any individual servo that hits a hard fault immediately cuts all power.  Also, at that time, the overall gait control, upon sensing any servo failure, immediately cuts power to all the other servos too.  As you can imagine, when a machine that weights 10kg loses all power to all joints with a few milliseconds, it falls down pretty hard.

Areas to improve

There are of course many areas of improvement which this event demonstrates.  One, the servos need better thermal properties.  This was known, and I hope to address in the second revision where I can heatsink the controller properly.  Second, the leg should be strong enough to handle falling down.  And third, it would be nice, if it could, if the machine would do something more graceful when continuing on in a controlled manner isn’t possible.

I tackled that third step right now in two phases.  First, I set up an optional communications watchdog in the servo.  If control commands aren’t received in a timely manner, the servo enters a new mode where it merely commands a zero velocity with no position control at all.  This means that if the control software segfaults, or the primary computer goes out to lunch, the machine will gently lower to the ground rather than dropping like a rock.

Second, I modified the control software’s reaction to an individual servo fault.  Now, it commands this new zero-velocity state of all unfaulted servos so as to minimize the amount of damage done to the overall machine.  If only one or two servos have faulted, this will still result in a relatively gradual let down.

Here’s a quick video demonstrating the two failure types:



Bringing up FD-CAN on the STM32G4

To verify that I could make FD-CAN work in the next revision of the moteus controller, I made a simple desk setup between two NUCLEO-G474RE boards.  I started by soldering up some breakout boards for the TCAN334G CAN transceiver I’m planning on using:



And then wired those up with a lot of jumper wires:


After a fair amount of fiddling, bisecting against the ST CUBE example project, and fixing some problems with my STM32G4 support in rules_mbed, I ended up with some 16 byte CAN frames being sent and received with a data rate of ~4Mbit.

A whole frame
A single bit within the data part of the frame