mjbots quad

The last piece of the quad A1 puzzle that I didn't have on mjbots.com is here, the pi3hat

This is a Raspberry Pi (4b or 3b+) hat that provides 4 CAN-FD ports (up to 5Mbps), a low speed CAN port, an IMU, a DC/DC converter to power the Raspberry Pi from bus voltage, and a port to connect an nrf24l01 module.

I also wrote a brand new standalone client library which is a single C++11 header and source file with no dependencies.  It lets you access all of the features of the pi3hat in a performant way, although the SPI register mappings are publicly documented in github for writing your own client library.

I tested this version of the board and library in-situ with the quad A1:

After some optimization, I was able to get a full cycle of commanding and querying all 12 servos and reading the IMU down to 740us:

If you do that on one core of the raspberry pi, that leaves the other 3 cores for doing control work, and would let you achieve a 1kHz update rate.

As I mentioned, with the pi3hat, all of the custom boards and servos for the quad A1 are now up at mjbots.com, (the controllers and servos with now significantly reduced prices):

• moteus controller: $79
• mjbots power dist: $79
• pi3hat: $129
• qdd100 beta: $429

The quad A1 is nominally capable of aggressive dynamic motions, but so far the only implemented gait that takes advantage of that is the pronking one:

Pronking isn't a terribly efficient means of moving, so I wanted to start working towards better walking and running gaits.  I'm taking baby steps for now, so this is just a start.  To begin with, I'm tackling just making low-speed walking on flat terrain better.

I went through my old video footage and identified a number of instances where things weren't working as well as they could:

What happened in all of these instances was that during the flight phase (when only 2 legs are on the ground), the body end up tipping far over, resulting in one of the flight legs hitting the ground much sooner than expected.  This causes all sorts of problems, since the leg isn't where the software expects it to be, and now the body has an even larger angular roll rate as the early foot pushes the body back up.

I figured it should be possible to at least maintain balance during the flight phase as a first step.  My initial experiments were just in 1d, with a python script and a matplotlib rendering:

The key idea was twofold.  First, to keep the integral of time spend on both sides of the balance point the same, and the second is that this is trivial to do if there is no acceleration during the flight phase, as it means the distance and time traveled by the center of mass is the same on both sides of the support leg (and in any event, my formulation of acceleration can't actually accelerate the robot stably during the flight phase).  The example in 1D above shows acceleration happening when both legs are on the ground, and the timing of the flight leg is selected so that at the current velocity, equal time will be spent on both sides.

I added a maybe-good-enough heuristic to handle the case where acceleration causes the velocity to reverse, which in that case causes the leg switching order to reverse:

At that point, I extended the algorithm to 2 dimensions, where rotational rate is considered as well as linear translation rate and implemented it on the robot.  This just treats the pairs of legs each as a single "virtual leg", and calculates the time required for the center of mass to reach the support line drawn between the two stance legs to decide when to lift those virtual legs.

The result is pretty good on flat ground.  A much broader range of maneuvers can be executed now without tipping:

Lots still to do, mostly to go faster and handle a broader range of terrains.

The pictures I had on hackaday were pretty stale, so I switched out my gallery for an updated one of the quad A1, the moteus r4.3 controller and the qdd100 servo.

I've started working on improving the walking gaits... my first pass made some good improvements.  Up to 0.5m/s now, and greatly improved acceleration and decleration.

https://www.instagram.com/p/CAxPqDBATIU/?utm_source=ig_web_copy_link

I recently re-built the entire chassis and legs to improve my mounting setup and to get a belt gear reduction in the knee joint.  Here's a quick instagram post showing it move!

https://www.instagram.com/p/B_xwT4gHaiw/

I just got a batch in from the fab and have gone through and flashed and tested many of them!

Since I was getting enough to have a panel to myself, I customized the solder mask color.  It was a bit of a crapshoot, but I think it turned out really well.  These boards are identical in performance to the r4.2 boards I have in the quad A1 now, just they look nicer and I have more of them.

Top of the line specs:

• 3 phase brushless FOC control
• Integrated absolute magnetic encoder
• Voltage: 12-34V
• Current: 60A peak
• Control: 40kHz PWM and control
• Comms: 5 Mbps CAN-FD
• Daisy chained power and data connectors
• Open source firmware: https://github.com/mjbots/moteus

I've made up some devkits too, which have a random motor attached, and come with a CAN-FD converter, power supply, and STM32 programmer:

All available at shop.mjbots.com for shipping worldwide!

I wanted to measure the realized torque from the qdd100 servos, so built up a simple fixture that let me attach a 1m long pole:

I used that to push down on a digital scale and figure out the actual torque mapping.   The plot of phase current vs torque looks like:

I've got some more learning to do to fully understand why the torque constant is lower than I expected, why it drops off as much as it does at higher currents, and why I have the variability I have between devices.

Here's a video showing the testing:

I ported my simple walking gait into the full rate 3D force controlled framework and ran it on the quad A1.  That alone made the walking work much better than before.

Also, I have a limited number of the qdd100 servos available for beta testing: https://shop.mjbots.com/product/qdd100-beta-developer-kit/