Motorama 2015, Part I: RageBridge v2 Drama

Let it be known! I shall not update my blog with the Motorama event report until all other MIT-based Motorama competitors update theirs. If you see the Part II, it means I’ve finally been satisfied… or got sick of waiting. I am a man of unyielding principle. For some background on this, through a spectrum of high-pressure sales tactics and peer pressure, an astounding number of new builders are attending; by my estimates, we had 6 totally new entries (and attendant totally new builders). One group elected to complete in the Antweight (1lb) tournament that runs on Friday, something that even I don’t normally do!

As I mentioned last time, none of the bots were in bad shape pre-Motorama, but I’ve been expending immense energy trying to get RageBridge v2 working in time. So why not start with it?

RageBridge v2

Previously in the adventures of RageBridge, I had gotten the bulk of the automatic input-reading organized through a depth of register-diddling greater than what I’ve ever dared do before. If you know me and how I program embedded systems, you know that registers are my most favorite things about the process, and there’s nothing I look forward to more when starting a new microcontroller project than hunting through the thousand-page programming manual and trying to write bit manipulation expressions.

Now, with the retching out of the way, time to try writing an input-taking routine.

One programming challenge for RageBridge v2 was the automatic input-mode detection. I don’t have a rail of jumpers to select the operating mode, and don’t intend on having one since the board is already SLAM-PACKED WITH RAGE!If I can get a reliable automatic input detection, then great! If not, then different firmwares will be made available.

The inputs to decide between are R/C, Serial packets, and analog. On power-up, Rage will take a second to let the inputs stabilize and any partner electronics like receivers and master microcontrollers boot up. Then it will, ever second, check for…

  • Serial buffer byte presence. It will read the first few bytes of the serial buffer and check for 64 or 192 (out of 255, an 8-bit value). These are “idle” commands for left and right motors. This convention is common to several robot controllers that have “simple serial” protocols, where 1 – 127 controls one motor and 128-255 controls the other. If these bytes are present, then assume Serial operation.
  • If there are no valid serial bytes, it will set up the channels 1 and 2 input pins for analog voltage reading. Additionally, it checks if the MIX jumper is set. MIX assumes “joystick mode” where the sticks are centered at 2.5v, so both inputs have to be at this level (within a small deadband) to select that mode. Else, if MIX is not in, it assumes 0-5v with 1-4v as the active range, meaning the signal must be approximately 1V (within a small deadband) to select.
  • If the analog voltages aren’t within the correct band (or it’s pegged to 5v due to the internal pullups) it will initialize the R/C inputs and wait to collect input pulses. Once valid input pulses for both Channels 1 and 2 are received – which must be 1500us +/- a deadband – then the mode is selected. The forced neutral-only mode selection acts as a zero-power-on-startup check too.

This pattern repeats once per second, and the motors will not drive until the appropriate signals are received. Overall, the code looks something like…

I had thought the Analog part would be the most difficult, with the deadband requirement and all. But in fact it was quite easy. With a few test potentiometers and scooter throttle handles, I could get it to reliably pop into Mix or non-mix mode every time. R/C mode proved to be the issue – no matter how much delaying or waiting I had it do, across different receivers even, I couldn’t get R/C mode to work!

As a bit of background, I use the PinchangeInt library to capture R/C pulsewidth signals without having to use the blocking (prevents rest of program from doing anything) pulseIn() function in Arduiono. After writing up a quick R/C only input-taking test program, I noticed something peculiar. All of the inputs read, no matter one channel or the other, simply looked like they were overflowing the variable over and over:

The PinChangeInt interrupt service function takes the difference between the micros() calls of two functions, a rising edge and a falling edge, to get the delta-time. micros() is an unsigned long (32 bit) type, and my R/C pulsewidth variables are signed integers (to be used later in mapping/scaling math). The pattern of values said to me that something was just counting further and further up – not taking the difference at all.

Checking with an oscilloscope confirmed that only one interrupt was being serviced:

I set and cleared a pin on the chip whenever the rising edge or the falling edge interrupt was being triggered. As expected, only one edge appeared. With this test, however, I couldn’t tell if it was the rising or falling edge…

…especially when it seemed that SOME TIMES, both interrupts were working! This shot clearly showed a 1000us pulse width, with two triggers. So what the hell was going on?

By the way, this is the first official usage of the DSO Nano 4 channel digital scope I picked up in Shenzhen! All of the initial debugging shenanigans happened at my desk as a result.

I reached out to the Arduino Forum, where the developer of PinChangeInt had a thread about the library, and learned some interesting facts… namely, that the code should never have worked the way I wrote it in RageBridge 1, and a couple of projects before that.

Well, hmmm.

To clarify without having to read the thread, here’s the difference. I’ve written all my R/C input code in the form of two separate interrupts, RISING and FALLING edge, since 2011 when I first started using the library. The form is similar to this, which was an excerpt from TinyCopter:

The takeaway is that there are two interrupts per pin. Allegedly, this should never have worked!

Yet, compiled in the latest version of Arduino, with the latest version of PinChangeInt, this is what happened. The same kind of nonsense I saw in my initial testing. It seemed to me that only the interrupt I defined last was executing, which contradicted what I saw on the oscilloscope – that some times both interrupt service routines did execute. But I freely admit that this could have been a oscilloscope artifact.

Pictured above is the structure that SHOULD HAVE been used this whole time – a single interrupt service routine, executed whenever the pin CHANGE’d states, and which subsequently read the state of the pin:

As the collected 1500us (approximate) pulsewidth shows, this works fine.

So what gives? Not even the developer knows, apparently! My “two interrupt” form was never supposed to work. I can only assume that between Arduino version 1.0.1 from 2013 andthe current 1.6, and from the first version of the PinChangeInt library I used to the current, that enough changed such that whatever loophole I used was no longer possible.

Either way, with the solution found, I backtracked a little and modified my “two interrupt” program to show which interrupt “won”, so to speak.

I changed the two-interrupt type to only increment or decrement a variable depending on which component was called. As I suspected, the last ISR to be declared always “won”. Here, vol_ch1_pw is being sampled by the main program loop, which shows it always decreasing. if I swapped the declaration order, it would keep increasing.

Whatever. Chalk it up to falling victim to the stochastic nature of Arduino developers, and y’all can lecture me about this is why you always use the programming manual yadda yadda I-don’t-care. It works now:

The PINC & [byte gibberish] portions of each ISR simply “select” the pin to read. Notice how it starts at 0b00000100 – this is because the first two bits represent the first two pins of port C, PC0 and PC1, which are reserved for the current sensors. PC2, PC3, and PC4 are the three channels of input.

With that mystery resolved, the entire automatic mode detection code worked instantly:

Shown above is Analog (unmixed, with a scooter throttle) and R/C mode inputs. Serial inputs are hard to capture on video since it’s one microcontroller talking to another. I assigned different blink patterns for the different modes to help during debugging, but they will be retained for actual operation.

The blink routine itself is interesting by itself. It’s the first time I’ve used an otherwise unused hardware timer (Timer 2 in this case) exclusively as a blinking machine. Here’s the code snippet that makes it work:

The software “prescaler” portion was carried over from my previous different motors controllers’ code, where it was part of the main loop. Either way, something executes that if() and builds up the prescaler variable. After enough times of this happening, it executes the blink part of the code.  Timer 2 was set up during the initialization as a simple counter with a hardware prescaler of 64 from the system clock of 16MHz. This resulted in a counting speed of 250KHz – every 4 microseconds, the count would increment. Left to its own devices, this count would overflow after 256 counts, or 1.024 microseconds. To obtain a clean (to us humans) number, we start the count at 6 (BLINK_INITIAL_VALUE) such that it only has to count 250 times per overflow, giving a clean 1 millisecond timer. With some frills, that’s basically the millis() function re-implemented. I could have included this in the main loop as a call to millis() and it probably would have worked just fine, but I wanted it on a separate interrupt to not hog main program loop time.

Next up is that horrific line of bit manipulation that somehow worked the first time. What this line does is turn PB5 – a.k.a Arduino pin 13, the LED, on and off according to the state of a byte that is being used purely as an 8-bit array, where a 1 means “LED on” and 0 means off. current_blink_pattern is this byte, and it’s assigned whenever the mode changes so the blinking pattern changes.

The line first takes PORTB (the output status of the pins) and masks off PB5. Next, it grabs a copy of current_blink_pattern and shifts it right by some number of bits – basically an array counter that is reset at the bottom every time it exceeds 7. It logical ANDs this with 0x01 to isolate the least sigificant bit (rightmost bit). Finally, it moves this bit leftwards 5 positions to line up with PB5, and jams the two together.

The result is that PB5 is always turned off every cycle but the result of (current_blink_pattern >> blink_index) & 0x01 turns it back on (or leaves it off for this cycle).

With BLINK_INTERVAL set to 100 and the interrupt happening every 1 ms, the result is a 0.1 second blink duration where the LED can on or off. Now, strictly speaking, with 8 bits I can only make 0.8 second-long blink patterns. That’s fine, I don’t care.

Yes, I get all the way to the end of this timing problem and don’t even care that I get clean 1-second long patterns.

One thing that all the scoping to get to the bottom of the interrupt issue was discovering that the input filter capacitance I put on the input pins, which are shared by both analog and digital signalling, was too great.

Ouch, that’s a 10us rise time there. The fall time is about twice as fast, but still bad. I put 4.7nf input caps on the pins, which I guess is too much for another little microcontroller’s pins to drive. I might have to compromise analog signal stability (or implement software filtering at some point) in favor of making the edges sharper.

Once the bizarre library behavior was accounted for, and the automagic mode selector finished, the rest of the code was actually quite easy. In concept, it was just like RageBridge 1, but better implemented.

First, the inputs are sampled and cleaned, with erroneous signals replaced with the “last known good” one and a signal-bad flag set. Next the signal is mapped to an output variable. The output variable is bounded by a maximum increment per loop (ramped), and the result deciphered into PWM + direction and output to the drivers.

Whereas in RageBridge 1 all of this took place messily within 1 loop, I organized it all into procedures so the different modes can be better isolated, even thought hey still acted on global variables:

Of course, right now, I only have the R/C code written.

I did away with the incredible machine that was the mapWithRampingAndDeadband() function of RB1. That was basically broken up to its constituents – the deadband was taken in the input processing stage, and the ramping output mapping just a compare and += or -=.

Soon, it was time to test. Without having made compatible heat sinks yet, I, uhh, created an innovative board clamping system to secure it to the old style Ragebridge 1 heat sinks.

Innovative. That’s the word.

It’s totally not “two binder clips and some electrical tape”.

The test subject was Clocker. By this point, it was Wednesday afternoon, so this was going to be a determinator as to whether or not I try running the new boards at Motorama or not.

During a few on-the-bench tests of pegging the throttle back and forth, I was able to get the board to reset several times. This is not a good sign, as it shows the design has noise coupling into it in some place that is making it all the way to the logic. I have a few suspects, namely the long analog power and ground traces feeding the current sensors and the less than optimal placement of the logic power supply taps from the main board power planes.

My first battle tactic is always to insert capacitance where it doesn’t belong to see where the noise was coming from. For starters, all the 0.1uF logic circuit buffering capacitors were changed to 1uf. Now, strictly speaking, I suppose it was capacitance that was there in RageBridge v1 but was removed, since all of those on version 1 were 1uf to begin with. I also changed the primary input bypass capacitor (on the Vcc pins of the micro) from 1uFto a 10uF.

For the most part, as far as I could tell, this resolved the issue. But capacitors are band-aids to the real problem, which is layout. I’m going to have to take a closer look at how the logic power is feeding in and out of the big patches of battery voltage and ground planes, all being switched hard tens of thousands of times a second.

There was also one particular pin connection on the A3941 gate drivers which I was unclear about, which may also contribute to noise coupling via ground fluctuation, but I will address that once I put together some more boards. In the mean time, I taped the board back into Clocker for some hard driving.

For the most part, the test went quite well…

This test revealed a very important hidden flaw in the drivetrain that I’m glad was caught. Namely, when I last took apart the DeWuts on Clocker to change the motors, I neglected to recheck the torque-limiting clutch screws. The clicking, clutch-slipping noise in the video is exactly that. A little bit of hex key wiggling – no sprocket removal even needed – and things were tightened up again.

During this and subsequent bench tests, I couldn’t get it to lock up or reset no matter how much I gunned the motors around. In fact, I did it so hard that…

What you see is a thin pall of DeWalt smoke from some rapid input reversal testing gone wrong. It seems that one of the motors had a borderline commutator short, which quickly became non borderline when rapidly smashed with +/- 26 volts.

The resulting quick short also took out one gate drive chip and two FETs on the half of the controller driving that motor. I replaced them both in 5 minutes, along with sending this motor to the pile of sad motors.

I ended up deciding not to run RageBridge v2 (board revision 1) in Clocker for this event, since I didn’t want to have to do ESC debugging in the field while my match is 2 minutes away. What I did do in the remaining day was add in the much-requested combine mode, which hard-parallels the two channels together at the hardware level. This enables Rage to function as a single large 1 channel ESC.

That part was easy. In combine mode, only channel #1’s current sensor is read and the assumed current is just twice that. The current control loop output calculated for channel 1 is applied directly to channel 2, making the assumption that the two halves, driven off the same PWM timer with the same gate driver, will switch on (within a small fraction of the total switching time) with eachother. This is not the most robust method, as it totally slaves channel 2 to channel 1’s mercy, and a failure on channel B will probably cause the whole thing to grenade. Maybe it’ll get revisited shortly.

Why did I put Combine mode together? Because another bot this time needed it…. and for that, we’ll need to wait for Part 2.

The Motorama 2015 All-Bots Update: The Revival of Candy Paint & Gold Teeth, Überclocker Advance Inspection

With Boston getting mashed by blizzard after blizzard literally once every weekend for the past month, there’s not much to do save for hunting baby seals for their meat and blubber working on robots! Especially as wave after wave of cancellations hit MIT to the point where I’ve had to reschedule several shop orientations as well as cram 2 days of lecture content into one for a new black project class I’m helping with… but more about that later. And suddenly, Motorama 2015 is but a week away! And Dragon Con 2015 is next Tuesday, clearly.

Contrary to previous years, I have a temporary moratorium on new bot construction, choosing instead to try and make my current fleet a bit less fail before moving on. This was spurred on mostly by Überclocker being basically perfect by placing at the past 3 events: Motorama 2014 and Dragon Con 2013, and finally winning at Dragon Con 2014, for which I redeemed my karma points on the return trip. I thought it only fair to give Candy Paint & Gold Teeth the same treatment this time around. Last year, due to a whole stack of beginning-of-semester shop issues, I only had days to work on it and the whole bot was extremely rushed on the last mechanical details and the entire electrical system. In large part, the internals were held in by hot glue. This year, as I act as mentor to a host of new MIT-area based builders (who I’ll definitely introduce on this site in the event report!), I’m going to integrate the lessons learned (read: all of them) from last Motorama and finish the bot like I intended.

The following work was from maybe Mid-January to about 2 weeks ago…

Step 1? Actually look at the damn thing! I knew it was all hot glue and zip tied by Adam and company last year, but not how badly. And I will just say… my god.

Now, in reality, I think those lipoly packs are more secure in there with their 10 square inches of Velcro, half-dozen zip ties, and generous fillets of hot glue per each, than anything else I can come up with – including the original sheet metal battery cages. But this also makes them utterly irreplaceable, and Candy Paint ended the event with a dead cell, so these had to definitely go.

The placement of the motor controller was also not optimal, and… well, should I really waste time listing everything that’s wrong with an on-the-fly wiring job?

The next course of action, much like pre-NYMF Chibi-Mikuvan, was to rip everything out and start over. This actually took much more effort than it sounded. Recall that both lithium packs were held in by no less than 10 square inches of Velcro. Real 3M-branded Velcro. We might as well have welded them in.

I got as far as heartstoppingly buckling one of the packs in half by a few degrees before trying other solutions.

It’s actually very, very hard to remove sticky-back Velcro of reputable source, such as if real 3M adhesive is behind it. I ended up pouring acetone into the cavity that surrounds the battery and waiting several minutes while slowly applying upward pressure on the battery wires. The acetone slowly damages the adhesive along the peel front, so the whole thing very slowly lurched upwards and eventually gave up.

Extracting the smoked controller to inspect the depth of destruction. Two of the phase wires desoldered themselves, and the 3rd leg was also a total loss. Ouch…

One of the higher priorities for me was rewinding the weapon motor. The original winding had a short-to-core to begin with, which might have contributed to the controller’s untimely death. I couldn’t identify the location exactly, but there are at least 2 spots per phase where I pulled the wire bundle over bare metal, so the chances were good that I would have shorted something a little.

The issue is that I ran out of the specific size of 70mm stator used in the motor. I have a handful of 70mm stators spread across two types – one with a 32mm center bore, and another with a 26mm one. I designed the motor around the 32mm type, and the only ones I had left were damaged salvage cores from copier motors. Due to how much epoxy I poured over the first stator, I decided it was still better to repair the ones with damaged coatings.

Pouring epoxy over the exposed metal is actually a very unreliable fix, because of the way the original coating wraps around and smooths the edges of the steel. Instead, I had something better:

I had these sheets of “electrical grade hard fiber” from McMaster from past projects. It’s also called “fishpaper”, contains no fish nor shellfish, is gluten-free, and is a resin-impregnated heavy cardstock-like material. Laser cuts beautifully into stator-shaped pieces. I used the model of the stator that I measured up to design the motor for the 2D profile, with the arms and tooth ends purposefully thickened a few percent to not leave any metal exposed. This whole sheet was then applied to the cleaned steel surface with epoxy.

Next up was rewinding. My goal was not only to make a clean winding, but also slow the weapon down. Wait, even more?

The two fights Candy Paint got in at Motorama 2014 showed that the weapon already had enough impact power for my liking, and I try to favor reliability over the so-called “brushless penis contest” in the combat robot world of ever-larger motors and spinning weapons, often to impractical proportions. Trust me, I used to be one of the young boisterous men responsible.

Candy Paint’s bar was designed to spin at 180mph. I would be perfectly content with 120 or even 100, with super rapid spin-up time and excellent “upside-down flailing” torque. To get to this point with the same gear ratio meant increasing the turns on the weapon motor’s stator poles by 50%, which entailed going to… oh, six turns per tooth instead of four. Still easy compared to my 36+ turn hub motors! Either way, a new piece of string to measure the wire length needed was test wound around the four teeth of a phase.

The “hobbykinging rig” was, like last time, wrapped 3 times around a set of 10ft-apart table legs to generate 3 parallel bundles of 9 parallel wires. This gave the motor the equivalent of 14 gauge windings, except far, far easier to wind than a single solid 14 gauge bar.

A half hour or so later… a motor appears! See, low turn-count motors are super easy to wind! A custom hub motor often takes me like 2 or more hours each.

The aluminum bearing cap was thoroughly covered in thickened epoxy before I started pulling wires over it. I left roughly 10″ on each winding end and put heat shrink tubing over them to use directly as output wires.

But the next issue was, once again, how to solder bullet connectors to them. Enamel-coated magnet wire is difficult to solder without resorting to disgusting measures, such as dunking in molten sodium hydroxide or highly acidic fluxes. Or torches and mechanical removal (sanding, scraping). Doing that on a 27-strand bundle was out of the question. I did that last time…

I started haunting the Internet for anecdotes of the “Well, my mama told me to use yak milk and that’s never failed me!” nature. Could I get yak milk around here? Probably, if I look hard enough. But one curious substance showed up repeatedly: average automotive brake fluid. Hey, I don’t have a yak, but I have something about yak-sized that needs brake fluid, so I have some bottles of brake fluid!

When I thought about it a little more, it made sense. DOT 3 and 4 brake fluid is made of glycol esters, which are also found in paint strippers. In fact, brake fluid itself often has “do NOT get on your paint, like seriously” written all over it. So when you heat it up, of course it’s going to attack and damage the enamel coating too.

I was fairly certain from MSDS-haunting that burning brake fluid was not acutely toxic, but also sure that it isn’t good for me in any way, so this step was done with plenty of ventilation.

Well I’ll be damned. Dip the end of your magnet wire bundle in a tiny little bit of brake fluid, and using a large iron, solder as normal. I would estimate the solder flowed 1/3rd as fast as it would on a bare wire, but each of these joints was made in under 15 seconds. None of the inconsistent flowing, burning, blobbing up of flux, etc. I’ve experienced in the past.

This has been your “Well, I’d say don’t try this at home, but that defeats the purpose of putting it on the Internet” moment of this post.

Now, it’s important to point out that DOT 5 brake fluid is made of silicone and probably won’t work in this application.

Installing the motor for a quick spin and fit test!

Finally, I folded the sheet aluminum battery retainers. Each battery will still have a few square inches of more reasonably-placed Velcro padding underneath it which should handle the majority of loads, and this cage is just to prevent them from being sucked into the spinning cheese-grating pulley below them!

Before putting the batteries permanently in, I wanted to try and fit the motor controller in the same region as the motor. This is so the wiring was less chaotic up front, and the controller at least had a modicum of convective cooling available.

Keeping the wires down was more of a challenge than packing the ESC in. I made these polycarbonate retaining strips that have their ends heat-bent up into a hook shape, and are quite difficult to remove. I’ll probably back this area up with a cable tie or two to more guarantee the plastic not flying away.

The ESC has been switched to the 150A K-Force since I’m only running 6S in this bot now. There’s no need to specify a high-voltage 12S capable ESC! Architecutrally, it’s identical to the “Sentilon” HV version.

Final installation of the wiring. There’s a sad empty spot to the right that needs filling with some gaudy mood lighting or something…

This isn’t it, however. All of these wires are sort of too tall and interfering with the volume that the drive pulley needs:

For basic flight testing, I stuffed everything in using massive amounts of gaffer’s tape, but this isn’t a permanent solution.

In this configuration, I found out that the bearing block was either milled 1/16″ too deep, or the bearings are collectively 1/16″ shorter than their nominal dimensions. I had to insert 0.06″ of shims into the spindle in order to have it not wobble.

I took the opportunity to swap in one of the spare pulleys I had made, since the first one was showing “bowtieing” on the D-bore due to how loosely it had been mounted before.

To resolve the wire height issue, I finally finished the bottom plate that was supposed to go on originally. To the underside of this plate are glued a succession of rigid foam rubber blocks which keep pressure on the wires, especially near the cheese-grater pulley. Notice the “0.06 of shims” that I wrote to remind myself how many shims to stuff back in…

I need to find a good hiding spot in order to get a good spinup video of this thing, or even better, some actual testing. MIT is in general so space-constrained though it’s difficult to find a location to do this in. The loading dock is all concrete, but too tight. I’d preferably want to be on a different elevation from the blade, and behind a solid concrete object…

Candy Paint on full drive power is fast. Faster than any spinner has any right to be, with a design speed of just under 16mph. I’m hoping that this balance of drivetrain and high-torque and reliable weapon will be a favorable one. It’s also very squirrelly when turning due to how short the wheelbase is, so I’ll be keeping the dual-rates switched on for this one.

One of the details that completely derailed any plans of Candy Paint domination last year was the unmodified blade. I bought this from a builder who made this blade for an invertible bot, which didn’t care which orientation it was in. Candy Paint is non-invertible by design, and the double bevel caused it to “coin” into the air on any non-perpendicular impact (read: like all 3 of them).

Solution? Just grind the bevel off. This step took a while, since the steel is hardened and my angle grinder is small (the Civilization Destroyer is only equipped with a skinny cutting, not grinding blade).

I only ground 1 bevel off on each side, so the blade can currently only “spin” one way – I made sure that this time it was in the tighten direction, instead of last time where the blade slowly worked itself off since the motor torque was trying to un-spin the nut…

Almost armed up fully. Notice how I also stripped all the paint off? This is because…


Can’t test it? Might as well paint it. Candy Paint and Gold Teeth is finally getting some of its namesake. The candy paint: A can of fluorescent safety orange applied like 10 layers thick and glossy-clear coated. The gold teeth: Some Rust-Oleum “gold metallic” spraypaint that, to my utter surprise, actually worked okay.

And here it is, all pretty and shiny-like. I was definitely surprised at how well the paint job turned out. Maybe my many minutes of van bodywork, being forced to spraypaint something other people are forced to look at, helped.

Like I said, I’m still searching for an opportunity to whip this thing up to full speed and run into something. It’s probably going to have to be in some deserted basement, at night, on a weekend, peering from around a corner. I’ve driven the bot around plenty, and have whipped it up to maybe 33% speed, but haven’t planted the blade into anything yet.

That’s all for the Candy Paint reboot. Time to move it off the work mat so I can take a look at …

Überclocker Advance

As mentioned originally, Clocker has been steadily growing out of its awkward engineering bug stage, from suffering several issues at Motorama 2013 to almost winning Dragon Con 2013 to almost winning Motorama 2014, to finally winning Dragon Con 2014. Now, with my #1 nemesis for 2 past Motoramas not going to this tournament, and with the Banebots wheel swap being extremely successful at Dragon Con 2014, leads me to believe that Clocker has a fair shot at the 2015 championship.

IF something stupid doesn’t happen.

That’s a well known failure mode with stuff I make. So, as long as I have plenty of time, let’s take the bot apart as much as possible and check for possible impending stupid things. A wire about to become unsoldered, one of the RageBridge FETs about to pop off, the DeWalt gearboxes falling out of gear, etc. Anything at all.

So apart Clocker goes! On deck for a look-over include…

  • All of the lifter drive clutch parts, which involve shaft collars being tightened the right about to slip. Replace the most likely very fatigued screws holding the lift gear to the collar.
  • The clamp actuator has been “underconstrained” for some time – rebuild and take care of it.
  • Inspect ALL of the DeWalt gearboxes for signs of falling out of gear – the current style has an issue with the plastic shift-retaining ring not retaining. A zip tie takes care of it.
  • Inspect the drive motors’ electrical connections
  • Look over all the RageBridge v1s and reinforce large components with some epoxy or rubbery Goop.

Pretty close to maximum entropy here… I also added cleaning and inspecting the chains to the list here, because if these chains cause me one more problem, I’m firing them on the spot and replacing them with… I dunno, kite string.

Breaking down the actuator for a rebuild. The motor was jiggly (the mounting face having been bent), the whole actuator was falling apart, and the shoulder screw holes were beginning to strip.

I cut new side plates according to the current version of the design. However, instead of using the T-nut holes, I just went ahead and drilled and tapped their bottoms (using slightly longer screws to reach). That end of the actuator being reliant on only T-nut clamping pressure was a build oversight.

Other things I did to the actuator include “correcting for” the bent motor faceplate, then integrating a large amount of JB-weld into its remounting. I consider these motors pretty disposable, and I have a spare ready to swap in, so I’m not concerned about never being able to (cleanly, reversibly) remove this motor again.

The motors in question are these IG32 27:1 motors, which I modified to have metal first stages by, uhh, gutting a 3rd motor and transferring its metal gears to the other 2. This means I have a motor which entirely plastic. It’s labeled “TRAP!” in my bin of motors.

Performing the “zip tie insurance” on all of the motors. There have been some reports from DeWut users that the white shifting barrel likes to jump over the small shifting pins, leaving the gearbox halfway between 2 speeds.

Aaaaaaaand mostly back together. Notice how shiny the inter-fork standoffs are? I remade those too, because some of them had gotten unacceptably buckled. The tie rods were also bent, making disassembling the fork quite entertaining.

I’m stopping short of the electronics. Why? To put pressure on myself to finish RageBridge v2, of course!

Maybe this is the stupid thing in question, but I totally want Clocker (and Candy Paint) to run some pre-prod RageBridge v2s, since Motorama is inevitably the best stress test for them. The current electronics stack works fine, so there’s really no reason to shoot myself in the foot. I suppose I will make it a goal to test RB2 by Wednesday, and if there are any hardware bugs, to forego running them at Motorama.

That ends bot work as of like 2 or 3 nights ago. I’ve been working on RageBridge ever since! That adventure is another post.