I know this update has been a long time coming, but preparing for Bugglebots was insane. Now that I’ve had a chance to breathe, I can talk about what I took to the competition.
In the interest of spoilers, I’ll refrain from talking about anything learned at-competition. That will be a separate post after my episodes go up. What I will say, Bugglebots was a tremendous amount of fun. We learned a lot, met some wonderful people, and we’re already plotting our next steps forward.
You can find the full schematic here. I’ve referenced schematic page numbers below.
The Processor (Page 1)
For the new board, I’ve switched to a standalone STM32F446RE as my processor. It can run at up to 160MHz, and has a nice variety of built-in peripherals. I like the STM32 line for my general processing, as I’ve got some experience with it already, and it has a lot of community support.
Is published here. It is a full rewrite, but there aren’t a whole lot of new concepts to dig into here. What I will mention is that I’m now adding some light autonomy.
The Juke Maneuver
This is something I devised at Maker Faire Orlando, but never got a chance to try until I wrote an automated function for it. In essence, if I’m faced against a box-rushing wedge bot, I can try to surprise rush past it, and then immediately start spinning up. By the time the wedge is able to turn around, it will be too late to pin me.
Previously this involved starting at zero throttle, jamming the stick forward for a second, then pushing up the throttle for spin mode. Possible, but clunky. Instead, I coded in an extra state that I can put the bot in from Idle mode. If I then go into spin mode, the bot first executes a pre-programmed Juke maneuver. No control fiddling required.
The “Oh shit” Maneuver
Another simple addition, with a big improvement. While in spin mode, if I click the stick button, it instead tries to lurch forward as if it was in drive mode. This is for if someone manages to pin me. My drive motors are pretty massive, so running them full-blast forward has a good chance of breaking me out of a pin.
The power supplies
I had solder problems with the nice surface-mount regulators I used before, so I swore them off in favor of easy-to-solder through-hole modules.
There was a downside to the supplies; I suspect they didn’t have enough bulk capacitance for my needs. When I really pushed my processor, it would randomly crash. I ended up having to throttle the clock down to 60MHz to keep the damn thing stable, and I strongly suspect power issues as the culprit. In the next version I’m going to improve my power routing, and add extra bulk capacitance. Later edit: I discovered that the Vcap_1 pin on the microcontroller needed a 4.7uF cap tied to ground, to provide stability to the internal 1.2V rail. The lack of such capacitor on this design could have caused the noted instability. Furthermore, the BOOT0 pin should have been tied low.
The IR reception (Page 2)
This got a lot of changes. As detailed before, the binary-output IR receiver wasn’t cutting it. I needed an analog output to measure the signal strength. There aren’t any integrated circuit I could find with everything built in, so it was back to basics.
The IR receiver I was using before had several parts combined in a single package. I’ll need to replicate each part, except for the comparator that turned the analog signal into a digital one.
I at first used a TEMD5110X01 as my sensor, but then later switched to a PD333-3B/H0/L2 when it was clear I needed a radial-lead component. The selection criteria for this component isn’t too demanding, so the exact component isn’t very important
Transimpedance is a fancy term for “current in, voltage out”. Photodiodes generate a small current when they see light. The more current, the more light. Current is harder to measure though, so we use this amp to produce a voltage signal right away.
I used this particular Op-Amp after following the TI example board for their TDC7200-based lidar system.
High pass filter, inverting amplifier
After converting the signal to voltage, we need to amplify it more (it’s still pretty small) and apply a high-pass filter. The high-pass-filter strips off noise due to lights, burning robots, etc.
This circuit went through a lot of revisions. I’m still not a great analog engineer, and my first attempt at a filter oscillated and otherwise failed miserably. I managed to get something together before bugglebots, but you’ll notice a cap labelled “R14” and a resistor labelled “C30”. It was a time.
This circuit is just a diode, a capacitor, and a weak load. It turns a sine wave input signal into a relatively flat output signal, where the level of the signal is roughly the height of the sine wave peaks going in. It allows my ADC to more easily measure the amplitude of the signal.
Full disclosure on this one, I wasn’t able to test this capability. Preparing for Bugglebots was nuts, and didn’t leave me any time for stretch goals. I’ll keep working on this, as I think it has promise.
The basic idea is you generate some light, and time how long it takes for the light to bounce back. The speed of light is constant, so with a precise enough timer you can get a pretty good idea of distance.
The bot is already spinning, so if I can get a LIDAR that can measure fast enough, I can “see” the environment around me. I will need to use the accelerometer to correlate LIDAR measurements together into a coherent picture. Since this sensor drifts, I need to build this picture in a single revolution before the drift skews too far. This necessitates a measurement rate in the neighborhood of 15KHz, which is faster than any of the off-the-shelf sensors I was able to find. So we’re going to build our own!
The LIDAR is based around this precision timer from Texas Instruments. It measures time in increments of picoseconds, which correlates to about a centimeter of spatial resolution. That’s plenty good enough for our purposes. Most importantly, it should be able to reach the 15KHz measurement rate we need.
The timer measures the time between a binary start pulse and a binary stop pulse. We use a TLV3502 comparator to turn our analog signals into digital ones for our timer. It has two channels.
The first channel generates the start pulse. It watches the IR LED source, and when the current through the source reaches a certain threshold (indicating it has fully turned on), it asserts the timer start pulse.
The second channel watches the the photodiode output. When a signal is seen on the output, it asserts the timer stop pulse. I have a summing amp on this channel that basically amounts to an overcomplicated high-pass filter. It’s way overcomplicated, and will be replaced with a simplified circuit in the next revision.
Both channels are hooked into a digital-to-analog converter on the processor, which allows me to tune the thresholds on the start and stop triggers.
The IR source
While Laser is actually in the name, “Lidar”, and I could use an eye-safe laser, it seemed like more hassle than I wan’t to deal with at the time. Instead, I found an IR LED with a 4º beam angle, which is practically a laser at this range. LEDs are much easier to drive than lasers, needing only a bipolar transistor and current-limiting resistor.
The Motor Controller Interface (Page 3)
When I originally designed this board, I was also working on a custom motor controller that required a lot of discrete signals. I still included pads for a 5V level shifter should I decide to use an off-the-shelf controller instead.
I ended up using an off-the-shelf controller in the end, though it was happy with 3.3V signals. I never had to solder on the voltage level shifter. Still, it’s always good to design your boards with flexibility in mind. You never know what will come up in testing.
Instead of connectors which are apparently prone to flying off, I just left bare pads of copper to directly solder to. It’s technically harder to pull the circuit board out this way, but it never caused me problems. I recommend solder pads over connectors for anyone building circuit boards for battlebots.
The LEDs (Page 4)
Are sort-of new. I replaced the five APA102-4040’s with seven APA102-2020’s, which should be smaller versions of the same component.
In practice, they are not exactly the same. Importantly, the internal PWM used for dimming control is a lower frequency than on the bigger package. This means that instead of looking like a solid line on the persistence-of-vision display, it looks like lots of dots! I had to run the LEDs at max brightness, which forced them to stay on 100% of the time. This saved my display, but I don’t have the ability to adjust brightness anymore.
There are an extra two leads on the package for some reason, and they may-or-may-not do anything. The documentation is a mess honestly. On top of that, no one has a good footprint for the part. The one footprint I did find ended up being terrible. The LEDs were the most difficult part to solder as a result.
However… They were a lot smaller. It made a big difference on the difficulty of the layout. I’ll probably use these LEDs again, but I’ll go back to five LEDs. The extra two LEDs were too close to the guards, and couldn’t be easily seen.