Next up in Super Mega Microbot 2’s existence is being able to run untethered. Before that can happen, I need to be able to plug in a battery, and hopefully not have everything explode. As seen with the IMU junction board, even minor inductive links can result in chips getting toasted. I had thought that just adding sufficient capacitance to each of the point-of-load converters would resolve the issue, but in fact that almost made it worse.
Thus, I built a simple pre-charge board that I could put in line with the main power. It has two big FETs, one power resistor, an ATTiny44, and the random regulators and glue necessary to make it work. The microcontroller has one job. On power on, it waits a bit, energizes the “pre-charge” FET which has the power resistor in line. Then, a short while later, it energizes the main FET through which all power will flow.
I did some minimal qualification testing first with a single motor which went fine. Then I tested it against the whole quadruped, where I scoped the output ground line. Here, you can see that the output ground line initially rises linearly with the ramp up rate of the lab supply I was using to test. Then, about 80ms later after the ATTiny has powered on, it energizes the pre-charge FET and the output ground asymptotically approaches the resistance of the power resistor. Then again, at 100ms after that, the main FET is engaged and the output ground voltage drops all the way to 0 (or close enough modulo the FET on-resistance).
After that, all that was left was to try it with a real battery:
More time consuming was updating the control software to communicate with it. The old turret used the HerkuleX protocol, and when I integrated the moteus RS485 based servos, I took a few shortcuts that I knew would need to be resolved later. And the future is now!
In any case, the class which operated the servo actually owned the RS485 transport, which had to be factored out so that the turret class could share. Also, I went above and beyond and tried to maintain the HerkuleX based operation too, in case I ever went back to the old chassis and turret.
Higher input voltage: The old system ran at 2S, so 7.2V nominal. Now we’re running at 5S, so 18.5V nominal.
RS485 data: The HerkuleX based robot used TTL level data communications. moteus uses RS485.
Daisy chained power: With the new raspberry pi based computer in the turret, I now need to have an additional power and data port up on the mobile part of the turret.
No camera passthrough: Similarly, since the camera is directly attached to the raspberry pi 3, I don’t need to mess with having a connector to pass it through anymore.
As usual, I sent it off to MacroFab and waited. A seemingly very short time later and poof, here it was!
Bringing this up was more annoying than it could have been, mostly from a software perspective. The moteus and imu junction firmware were both based on the original gimbal software, but refactored to be usable across different projects. At the same time, that was where I had developed the RS485 based multiplex transport library. So, now was the time to bite the bullet and convert the gimbal software to use those common libraries.
Since the gimbal board has another unique processor compared to everything else, I broke it out into a separate git repository:
The old project was initially CubeMX based. When porting to rules_mbed and moteus/mjlib, I was in a hurry, so just copy and pasted much of the CubeMX initialization into the new tree and didn’t use any mbed APIs at all. It took me a while to remember how all the CubeMX initialization was glued together and which pieces of it were relevant before all the peripherals started working properly.
I then proceeded to mechanically integrate it together into the unused turret.
I once again had to remember how to calibrate and operate the thing. Doing this once every 9 months is kind of painful! However, I did manage to get it all working again, and ready to be integrated onto the mech.
As an intermediate forcing function, I’ve been preparing Super Mega Microbot to enter the Mech Warfare event at Maker Faire Bay Area May 17-19 in San Mateo, CA! The Mech Warfare event is a competition where scale size “mechs” or robots compete with airsoft cannons in a scaled down cityscape. Teleoperation is allowed, but the human operators are only allowed to see “what the mech sees”, which means driving from a video screen.
My goal for some time has been to try and improve the dynamic motion of my quadruped robot. Entering into Mech Warfare isn’t directly in support of that, but it is a fine and fun diversion. That isn’t to say that the current quadruped iteration is necessarily a great fit. I’ve only recently gotten it walking on new actuators at all, and only have enough gearboxes for just the lateral joints. The current iteration is a little, ahem — shall we say large — compared to other entrants. Also, there are a lot of “non-core” technologies that have to operate for the robot to effectively compete in a Mech Warfare event. Things like the airsoft cannon, remote video display, armor, unattended robust operation, etc. On the balance though, it is probably only a couple of weeks total diversion and is a good forcing function to make something that actually works end to end.
At this point, I’m clearly in “make it work at any cost on a short time frame” mode … err… “demo” mode. Coming up are some posts describing all the pieces necessary for the event, followed by hopefully an event debrief!
Now that I have a chassis that can walk a little bit, I need to get the onboard computer working. To do that, I needed to update the raspberry pi 3 daughterboard I built for the previous turret for the new bus voltage and communication format.
The rpi3’s UART is incapable of controlling the direction line on the RS485 transceiver, so I added a small STM32 micro in line to control the transmit / receive direction. It adds a little bit of latency, but testing the firmware I was able to get it down to only a byte’s worth or so.
Here’s a quick render:
And a shot of the actual board:
Unfortunately, I managed to omit a necessary pullup on the enable line of the primary buck converter. To get things moving along, I blue-wired it under the microscope:
And tada! It can! Well, at least a little bit. I’ve only spent a short while with the gearbox based chassis, and have a lot of work left to do. However, here’s a quick video showing it walking around, slipping on a ruler, and almost falling over a few times.
While updating the mjmech code-base to interoperate with the moteus servos, I simultaneously was updating it to use C++17. C++ rarely removes or deprecates features, but one of those which actually was removed in C++17, after being deprecated in C++11, was auto_ptr. unique_ptr is strictly superior in all regards, and so there is no real reason not to switch.
However, mjmech depends upon a large amount of third party software. Amazingly, only one package actually was broken by this removal of auto_ptr, log4cpp. It actually saw some updates for C++17 compliance back in 2017, but otherwise hasn’t been updated since then. I went ahead and forked it, and got it compiling with clang in C++17 mode at least:
After completing one gearbox, I needed to build at least 4 more of them to replace the lateral servos on Super Mega Microbot (2). So, I got to work. First, I disassembled 5 more BE8108 motors.
Then, I drilled out the rotors, this time using the mill at AA.
Next I removed the stators from their backing. This was painful enough last time, that I tried a new technique using the mill to do most of the work. Unfortunately, one of the stators was critically damaged during my initial experimentation. So, now down to 4 survivors.
I went and printed 5 copies of all the printed parts:
I’ve since decided that it would make more sense to print this in pieces that are bolted together. Actually installing all the hardware was tricky down in the depths, but it does seem to be functional.