Alert! I’m at Maker Faire Bay Area all weekend in the Mech Warfare area in Zone 2 (May 17-19, 2019 for you time travelers from the future). Drop by and say hi!
If you were left in suspense last time, yes, the robot can walk! Getting it to do so in a minimal way was relatively painless. What I found, which hadn’t happened in earlier iterations, is that many types of dynamic motions would cause the lower leg belts to jump a tooth. Needless to say, this was nearly universally fatal, as there is no direct position sensing of the lower leg. This robot is heavy enough that my simulacrum 3d-printed timing belt pulleys just don’t cut it.
Well, there wasn’t enough time to actually get better pulleys now, so I just tuned the walking to be slow and gentle enough that nothing went awry. Here’s the first bit of a 13 minute video I took of it walking around and shooting targets.
Now, that that was over with, I had a few minor things to finish up before heading out to Maker Faire. I made some covers for the motors to keep BBs out.
And I made a bracket so that I could attach the front and rear target panels to shoulder joints:
And here’s a glamour shot of the whole thing in fighting form!
Now that it was all ready, time to take it all back apart and pack it for shipping.
As mentioned last time, I needed to build a lot of gearboxes and new leg assemblies in a very short amount of time. So, I got to work.
I made a new fixture for holding stators to be extracted:
I turned down 8 more internal gears. To begin with, my mandrel had warped enough from the first gears that I had to add some heat set inserts to hold a cap to keep the gears on. Then on the last 2 gears, I got greedy, went too fast, and my lathe mandrel melted entirely.
So, I had to spend 12 hours printing another one to finish up the last two internal gears, although their roundness was debatable after their encounter with the mangled mandrel.
I also at this point machined out a bunch more rotors, but didn’t manage to capture any photos.
Now for some assembly:
At this point I was 3d printer limited, and when I got to starting assembly, I only had 7 sets printed. Thanks to some very generous help from Beat and Roxi (thank you triply in advance!) I had a second Prusa MK3 that was also working 24/7 on the problem.
Notice how now I’m up to 8!
When I went to put on the backplates, I discovered that due to tolerance stackup, some of the units were having trouble fitting. To move on quickly, I post-machined all the backplates to move the rotor bearing back a bit with a dremel, and then made a little bit of clearance for the sun gear holder screws.
And then, TADA!
Now, in parallel to all that, I also designed a new leg which would mount to the gearbox output. I wouldn’t have time to get a shoulder bracket made out of metal like I had before either, so I needed to design that for 3d printing too.
I made a few improvements this iteration. The biggest was that I added a tensioning mechanism inside the upper leg, so that tension could be increased after installing the lower leg. The old leg was nearly impossible to assemble without breaking it, and was just as difficult to disassemble. Also, I managed to have an actual order of assembly that was feasible and that an appropriate tool could fit in at all places at each stage of the process.
What I didn’t try to do was to try a more mini-Cheetah like geometry, or really optimize for mass or looks or anything. I was trying to get something which would likely work for the length of a Mech Warfare match in as few drafts as possible.
Of course, the first iteration wasn’t necessarily functional. It came off the press at something like 3am Friday morning. I spent the next 4 hours machining, debugging and squeezing until I found about a dozen problems or things that needed to be fixed. Then, straight back to the printer for a second try, and voila, two was all I needed this go around!
Here is the final part-set with all metal bits installed:
I drew and printed up the shoulder in a separate effort, but managed to capture no pictures of it whatsoever until I went to put it all together.
Now, here is a shoulder attached, with the upper leg motor and upper leg installed.
And from the other side:
And, the entire first leg:
After carefully managing my 3d printing queue 24/7 to get all the legs, shoulders, and gearboxes printed, here’s a picture of all the legs on at the same time!
Now that I could stand up and sit down, I needed to be able to walk reliably for the length of a match. This wasn’t going to be easy because the direct drive motors were always a bit marginal in their power output to support the full robot, so I had my work cut out for me.
The short story is, I tried many things, spent about a day examining high speed video of walking, and made some improvements:
Inverse Kinematics: I discovered that my inverse kinematics were broken when the coaxial lower leg had a non-unity belt drive ratio, which I switched to partway through my mammal leg experiments.
Less bounce: I updated the leg to stay in the world frame until it was fully lifted and to enter the world frame before lowering. This would ensure it had zero lateral velocity relative to the ground when starting and stopping the swing phase.
More less bounce: I added a separate slew time for the lowering part of the phase, this allowed it to lower more slowly for a more gentle landing.
Event more less bounce: I used the moteus servo’s advanced features to lower the P controller term while the leg was lowering, so that it would hit more softly.
Despite all these improvements, the walking was still barely functional. Also, the robot was just too tippy. The servos didn’t have enough control authority for the mass of the machine, and it was likely going to tip over if another mech did so much as graze it. Also servos that were hot for long periods of time kept having their encoder calibration drift. This seemed to occur in a positive feedback cycle… if a motor was a little bit out of calibration, it might be a bit saggy, and thus would need more torque, which would make it hotter, which would make it more out of calibration.
Here’s a quick slow motion video of about the best walking gait I had achieved:
At this point, I was certainly somewhat dispirited. It was pretty clear that this machine could not reliably walk around the arena for the length of a match. But, there was still some time left and I figured I would not give up just quite yet.
In the spirit of failing upward, I decided to try and make a sprint towards a fully gearbox driven machine. Granted, I didn’t really have enough time to pull this off. The first 4 gearboxes I built each required about a day of 3d printing time and took me about 1.5 days of machining and assembly. When I made this call, there were about 8 days before my plane flight to Maker Faire. I would need to make at least 8 more gearboxes, as well as entirely new legs and shoulders, along with spares and then make it all work in an incredibly short period of time.
Before SMMB could function in the Mech Warfare event it needed to be able to start and stop unattended. That meant standing up and sitting down on its own. Being that hack that this was, I went for a two pronged approach.
The direct direct servos I have for the upper and lower legs are somewhat underpowered for this size of robot. Especially so when the machine is fully squatting down. Also, the servos aren’t really encapsulated at all, and there are plenty of leg configurations that can self-intersect resulting in robot harm.
To avoid all of that, I 1) installed a second pair of permanently affixed “resting legs”, that mean the robot never has to squat down all the way. These are just some PVC pipe with squash balls glued on to the bottom. I printed bottom plates for the chassis with small cutouts to hold the top of the PVC pipe.
Next, I added a short startup and shutdown sequence. The startup sequence first moves the motors from wherever they happen to be to some fixed distance above their intended idle position, purely on a servo-by-servo basis. I don’t yet have position feedback making it into the C++ application, but the servos themselves can interpolate form their current position, so this was a fair way to get the whole thing into a known state. The only trick was that I had to linearly ramp up the power applied to the lower leg so that it didn’t get stuck dragging along the ground. A future solution that used position feedback, and thus IK, wouldn’t have that problem. The next part of the startup sequence just smoothly lowers the legs until the full robot weight is resting on them. At this point, the robot is freestanding.
The shutdown sequence only does half of the inverse. It smoothly raises the legs until there is no weight on the robot, then cuts power.
Once I get a robot made fully with gearbox servos instead of direct drives, and positioning sensing working at full rate back into C++, I should be able to undo some of these hacks and get it starting from arbitrary configurations without the help of the resting feet. However, this is good enough for now.
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.