Archive for the 'Project Build Reports' Category

 

The Semi-Official Launch of RageBridge

Feb 05, 2013 in dewut?, Motor Controllers

After months of design, iteration, and testing (most of which has ended up on this very website), I’m proud to introduce RageBridge for general sale to the robot-inclined public.

Get yours today!

Now, this isn’t a launch announcement per se – I’m waiting for the DeWut CNC mounts to arrive, then a more official announcement will be done once those are ready. But, given that some events like Motorama are coming up, I figured this pre-grand-opening-grand-opening will be helpful.

Here’s roughly what the DeWuts will look like in component form; this preview was sent to me by the CNC ship a few weeks ago when the order was not yet complete.

And thusly, Big Chuck’s Robot Warehouse begins humbly. 2013 is shaping up to be a great year so far…

The Forthcoming RageBridge: Stick Calibration

Feb 02, 2013 in Bots, Motor Controllers, Project Build Reports, Reference Posts

They’re here!

All of the RageBridges! All of them ever!

Or rather, 100 of them, in neatly packaged panels of two. Here’s what one of the manufactured panels looks like.

Pretty cool.

Okay, so these actually got in last week, but I’ve been doing some background and infrastructural work since then. I’m planning on gathering a few friends and flashing, populating headers, and testing all of these this coming weekend. I decided to leave the chips unflashed because I was not yet satisfied with the firmware (and the flashing was a few hundred extra dollars), and the headers are purposefully left unpopulated because many people prefer soldered-on pigtails or their own wiring configuration. It’s definitely a little more legwork on our end, but for such a small run (100, maybe with a few duds) I think it’s still manageable, and will allow the fine settling into best practices that inevitably accompany any parts business. Time to be a little adventurous.

From a firmware perspective, the only thing RageBridge has been missing since the last board revision is a way to calibrate the servo PWM range. This is generally preferred because not all radios are created equally, and some may have more stick travel & adjustable PWM endpoints than others. For instance, my (nice for 2006) Spektrum radio can hit the full 1000-2000uS servo range if I navigate through the menus and tell it to stretch its range a bit. But my cheesy Hobbyking 6 channel radios can’t do the same unless connected to a computer to program them – the stock range is more like 1200 to 1800us. So, any fixed input range will inevitably be a compromise – for some people, the stock settings will be too twitchy (i.e. stick travel range is greater than the board’s accepted input range), or you might not ever hit full throttle (because the radio stick travel doesn’t go far enough to match the controller input range).

Calibration has always been one of those things that I accepted as working, but never thought about implementing. Depending on how it’s done, it can be relatively simple, or a mess of state machine code.

One of the most common modern calibration paradigms is the “stick-high” method, used by most R/C model controllers, whether air, sea, or ground. This involves powering on the controller with a receiver attached (and generally, already powered and outputting valid pulsewidths) and you commanding full positive travel. If the first thing that the ESC sees, or sees within 1-2 seconds, is a full positive signal, then it waits for a few seconds and checks again. If you are still holding full positive, then it beeps or blinks (accepting the full positive position), and then you back off to full negative and hold for a few seconds, then back to neutral. For single channel ESCs without many other features, it’s pretty much the way to go.

I decided to implement stick-high calibration for RB, except modifying it for both channels at once. This entailed adding a timed loop in the middle where normally you would just check for full positive and full negative signals. The idea is that during the timed loop, the user just swirls the sticks around all at once and the controller will capture both ranges simultaneously. At any point, if the signal returns to neutral for more than 2 seconds, the calibration routine exits and writes the results to EEPROM so it is persistent.

Of course, there’s other little touches to make the system more robust like checking for pulse validity (rejecting malformed or misread pulses) and fail-safe performance if the user bails out in the middle. In all, it took me a few hours of planning and a few hours of beasting Arduino code, and I’m quite pleased with the final result.

So, in a completely out of context brain bump, here’s RageBridge’s stick calibration code. When I ship it through e0designs.com, the full source code will be released along with board files, but I’m putting this early because I’m particularly proud of it.

I subscribe to the Expository Essay school of code commenting – I literally write what every line and every procedure does, in detail, and in natural english. To hardcore and experienced coders this might seem like a waste of characters, but I find it particularly easy to read my way back through old code and decipher what the hell I thought I was doing when I wrote it. So there’s actually plenty of paragraphs in the comments.

As a bit of backstory since I didn’t post all the variable definitions, anything with a _1 or _2 is referring to the channel of RB it is relevant to. The code is written with Arduino 1.0.1 using the PinChangeInt and EEPROM libraries (PCI is not used in this section as the interrupt procedures that capture servo pulsewidths are not shown).

  • RCMAX, et. al. are all declared as signed integers at the beginning of the code (not shown).
  • CALIBRATION_CONSTANT is a fraction of the total stick travel, right now 0.66. In other words, anything ABOVE 66% of the current maximum travel is grounds for entering calibration mode. This is one of the tricks I added to prevent calibrating yourself out of your own radio travel bounds. So, basically what it entails is each time you calibrate you could reduce the range by 1/3rd if you had to.
  • neutral_counter and NEUTRAL_CYCLES_MAX refer to how many iterations of the neutral signal checking routine can run before the calibration procedure is declared to be done.
  • NEUTRAL_DELTA is the pulse width deviation around the current neutral point that can be recognized as a new valid neutral point. For instance, the default neutral pulsewidth for servo PWM is 1500us. If NEUTRAL_DELTA is defined as 100, which it is, then anything from 1400 to 1600 may be set as a new neutral point. This is to make sure you cannot drift the center stick zero throttle point too far, even on purpose. You can, of course, do so by running multiple calibration cycles. But why!?
  //Collect the user calibration endpoints from EEPROM. If the EEPROM values return 255
  //then calibration has never occurred, so use defaults.
  RCMAX_1 = (signed int)EEPROM.read(100);
  RCMAX_1 += (signed int)(EEPROM.read(101) << 8);
  RCMIN_1 = (signed int)EEPROM.read(102);
  RCMIN_1 += (signed int)(EEPROM.read(103) << 8);
  RCCENTER_1 = (signed int)EEPROM.read(104);
  RCCENTER_1 += (signed int)(EEPROM.read(105) << 8);
  RCMAX_2 = (signed int)EEPROM.read(106);
  RCMAX_2 += (signed int)(EEPROM.read(107) << 8);
  RCMIN_2 = (signed int)EEPROM.read(108);
  RCMIN_2 += (signed int)(EEPROM.read(109) << 8);
  RCCENTER_2 = (signed int)EEPROM.read(110);
  RCCENTER_2 += (signed int)(EEPROM.read(111) << 8);

  //Bytes will return 255 if they were never read; full 16 bit result is 65535
  if(RCMAX_1 == 0xffff ) {
    RCMAX_1 = RCMAX_DEFAULT;
  }
  if(RCMIN_1 == 0xffff) {
    RCMIN_1 = RCMIN_DEFAULT;
  } 
  if(RCCENTER_1 == 0xffff) {
    RCCENTER_1 = RCCENTER_DEFAULT;
  }
  if(RCMAX_2 == 0xffff) {
    RCMAX_2 = RCMAX_DEFAULT;
  }
  if(RCMIN_2 == 0xffff ) {
    RCMIN_2 = RCMIN_DEFAULT;
  } 
  if(RCCENTER_2 == 0xffff) {
    RCCENTER_2 = RCCENTER_DEFAULT;
  }  

  delay(1000); //Just chill for a bit to make sure radios have bound and begun sending out good signal.

  //Calibration mode procedure.
  //After initialization, check for good signal on channels 1 and 2
  //If the signal is above the calibration threshold on both channels, keep waiting. If not, enter main program loop.
  //If at the end of 5 seconds the stick has been held, enter calibration mode. If it has not, enter main program loop.
  //Even if there is no good signal, proceed to main loop anyway - the main loop begins in failsafe mode. 
  if(is_pulse_good(vol_ch1_pw,RC_ABS_MAX,RC_ABS_MIN) && is_pulse_good(vol_ch2_pw,RC_ABS_MAX,RC_ABS_MIN)) {
    signed int init_calib_threshold_1 = (signed int)(CALIBRATION_CONSTANT*(RCMAX_1-RCCENTER_1))+RCCENTER_1;
    signed int init_calib_threshold_2 = (signed int)(CALIBRATION_CONSTANT*(RCMAX_2-RCCENTER_2))+RCCENTER_2;

    if(vol_ch1_pw > init_calib_threshold_1 && vol_ch2_pw > init_calib_threshold_2) {

      //To check for stick hold, begin the timer and set a flag that will be cleared if the stick is released
      unsigned long calibration_timer = millis();
      boolean entered_calibration = true;

      //Enter 5 second wait loop, constantly checking for stick release. Invalid signal also constitutes "stick release".
      while(millis() - calibration_timer < 5000) {
        if(is_pulse_good(vol_ch1_pw,RC_ABS_MAX,RC_ABS_MIN) && is_pulse_good(vol_ch2_pw,RC_ABS_MAX,RC_ABS_MIN)) {
          if(vol_ch1_pw < init_calib_threshold_1 || vol_ch2_pw < init_calib_threshold_2) {
            entered_calibration = false;
            break;
          } //End stick release check
        } else {
          entered_calibration = false;
        } //End pulse good check

      } //End wait for 5 seconds to check for stick hold

      //If the flag is still true, then the user has held the stick for > 5 seconds above the threshold
      //Calibration mode description:
      //Resetting the old max and min bounds to a lower threshold (CALIBRATION_CONSTANT * RCMAX_n)
      //If a newly captured value exceeds the thresholds, save it. 
      //If a newly captured value is within a certain % of neutral (NEUTRAL_CONSTANT * RCCENTER_n above or below RCCENTER), start a timer
      //After 3 seconds of this, assume the user has returned stick to desired neutral and take several samples for neutral position
      //If any pulse is invalid, bail out of calibration and retain old values.
      if(entered_calibration) { 

        digitalWrite(BLINK_FURIOUSLY,HIGH); //Set the LED on solid to let the user know that calibration has begun

        //Set initial thresholds to exceed. The thresholds are a certain % of the current set of maxes and mins
        //such that the controller can never be "calibrated out". By only exceeding the threshold very slightly
        //subsequent iterations of calibration can narrow the range of signals too, if it is necessary.
        signed int rcmax_1_temp = (signed int)(CALIBRATION_CONSTANT*(RCMAX_1-RCCENTER_1)) + RCCENTER_1;
        signed int rcmin_1_temp = RCCENTER_1 - (signed int)(CALIBRATION_CONSTANT*(RCCENTER_1-RCMIN_1));
        signed int rcmax_2_temp = (signed int)(CALIBRATION_CONSTANT*(RCMAX_2-RCCENTER_2)) + RCCENTER_2;
        signed int rcmin_2_temp = RCCENTER_2 - (signed int)(CALIBRATION_CONSTANT*(RCCENTER_2-RCMIN_2));
        signed int rccenter_1_temp = RCCENTER_1;
        signed int rccenter_2_temp = RCCENTER_2;

        boolean am_calibrating = true;
        boolean commit_calibration = false;

        byte neutral_counter = 0;

        //Set the main calibration loop going. 
        //First, check for good pulses. If any are bad, the routine is immediately ended and changes are NOT saved.
        //Next, check for pulses near neutral. If any are, increment a counter. If the counter is over a threshold,
        //then the user has returned the stick to netural and calibratoin can exit/changes be saved.
        //If any subsequent pulses are outside of the neutral bound, zero the counter. 
        //Next, expand the pulse range if the new set of pulsewidths are greater in magnitude deviation
        while(am_calibrating) {

          //Sanity check - if any pulses are out of range or invalid, exit.
          if(is_pulse_good(vol_ch1_pw,RC_ABS_MAX,RC_ABS_MIN) && is_pulse_good(vol_ch2_pw,RC_ABS_MAX,RC_ABS_MIN)) {

            //Save a copy of the current "volatile" pulsewidths (which can change randomly due to the interrupt)
            ch1_pw = vol_ch1_pw;
            ch2_pw = vol_ch2_pw;

            //Neutral check. If the signal is within the box of valid neutrals for enough cycles, exit and save changes.
            if(ch1_pw < (RCCENTER_1 + NEUTRAL_DELTA) && ch2_pw < (RCCENTER_2 + NEUTRAL_DELTA)) {
              if(ch1_pw > (RCCENTER_1 - NEUTRAL_DELTA) && ch2_pw > (RCCENTER_2 - NEUTRAL_DELTA)) {
                if(neutral_counter > NEUTRAL_CYCLES_MAX) {
                  am_calibrating = false;
                  commit_calibration = true;

                } else {
                  neutral_counter++; //Within bounds, but not exceeding number of allowed cycles, so increment and move on.
                  rccenter_1_temp = ch1_pw;
                  rccenter_2_temp = ch2_pw;
                }
              } else {
                neutral_counter = 0; //If any of the within-bounds checks fails, reset the counter since the stick has moved.
              }
            } //End neutral check

            //Bounds check; If the new pulses exceeds the current set of temporary calibration bounds in either direction
            //set them as the new bounds.
            if(ch1_pw > rcmax_1_temp) rcmax_1_temp = ch1_pw; else if(ch1_pw < rcmin_1_temp) rcmin_1_temp = ch1_pw;
            if(ch2_pw > rcmax_2_temp) rcmax_2_temp = ch2_pw; else if(ch2_pw < rcmin_2_temp) rcmin_2_temp = ch2_pw;
          } else {
            am_calibrating = false;
            commit_calibration = false; //Something has gone wrong and caused the calibration loop to terminate early...
          } //End sanity check
          delay(20);
        } //End main calibration loop

        //Save changes?
        if(commit_calibration) {

          //First, reassign the constants for this power cycle...
          RCMAX_1 = rcmax_1_temp;
          RCMIN_1 = rcmin_1_temp;
          RCCENTER_1 = rccenter_1_temp;
          RCMAX_2 = rcmax_2_temp;
          RCMIN_2 = rcmin_2_temp;
          RCCENTER_2 = rccenter_2_temp;

          //Next, write these new values to EEPROM!
          byte rcmax_1_lowbyte = (RCMAX_1 & 0x00ff);
          byte rcmax_1_highbyte = ((RCMAX_1 >> 8) & 0x00ff);
          EEPROM.write(100,rcmax_1_lowbyte);
          EEPROM.write(101,rcmax_1_highbyte);

          byte rcmin_1_lowbyte = (RCMIN_1 & 0x00ff);
          byte rcmin_1_highbyte = ((RCMIN_1 >> 8) & 0x00ff);
          EEPROM.write(102,rcmin_1_lowbyte);
          EEPROM.write(103,rcmin_1_highbyte);

          byte rccenter_1_lowbyte = (RCCENTER_1 & 0x00ff);
          byte rccenter_1_highbyte = ((RCCENTER_1 >> 8) & 0x00ff);
          EEPROM.write(104,rccenter_1_lowbyte);
          EEPROM.write(105,rccenter_1_highbyte);

          byte rcmax_2_lowbyte = (RCMAX_2 & 0x00ff);
          byte rcmax_2_highbyte = ((RCMAX_2 >> 8) & 0x00ff);
          EEPROM.write(106,rcmax_2_lowbyte);
          EEPROM.write(107,rcmax_2_highbyte);

          byte rcmin_2_lowbyte = (RCMIN_2 & 0x00ff);
          byte rcmin_2_highbyte = ((RCMIN_2 >> 8) & 0x00ff);
          EEPROM.write(108,rcmin_2_lowbyte);
          EEPROM.write(109,rcmin_2_highbyte);

          byte rccenter_2_lowbyte = (RCCENTER_2 & 0x00ff);
          byte rccenter_2_highbyte = ((RCCENTER_2 >> 8) & 0x00ff);
          EEPROM.write(110,rccenter_2_lowbyte);
          EEPROM.write(111,rccenter_2_highbyte);
        }

        //We're done with calibration! Flash the LED a few times to indicate success.
        for(byte caliblink = 0; caliblink < 10; caliblink++) {
          PORTB |= (1 << 5);
          delay(BLINK_DURATION);
          PORTB &= ~(1 << 5);
          delay(BLINK_DURATION);
        } 
      } //End of master calibration routine

    } //End of check signal over calibration threshold

  } //End of check signal good

The State of the Überclocker Address

Jan 27, 2013 in Bots, Überclocker ADVANCE

It’s the end of January. Where’s my damned robot!?

After about a month of dormancy and on-and-off work, it’s time to get serious… lest I pigeonhole myself, again, in the position of working on the damn thing a day before setting out for Motorama 2013. I’m generally confident that Clocker was designed with the best and latest of my design-for-assembly methods in mind, and the progress (mostly in the past week or so for actual work) should demonstrate that here.

RageBridge and DeWut?

No matter how much I get done, though, the availability of the RageBridge assembled boards and the DeWut?!s will be critical in the robot’s completion. As of even right now, I don’t have a concrete bail plan for the DeWuts in particular if the parts do not arrive in time. Fortunately, I received notification that RB shipped this past Friday, and the DeWut order has been completed and may go out on Monday. Here’s hoping the magic of modern express logistics gets them in my hand by the end of this week. Both will probably need a little legwork on my end before I can offer them up to you all, but that’s all part of the battle plan. On a related note, the Hall sensor boards and mounts are ready for your experimentation!

We begin the build of Überclocker with my favorite production machine, the abrasive waterjet.

These parts were made from one of three plates of 7075 aluminum I caught a great deal for on eBay. 7075 may actually be my most favorite material because it’s one of the strongest aluminum alloys, yet you really can’t tell by machining the stuff. I probably could have made some of the material areas smaller to take advantage of the 50% increased yield strength of 7075 over 6061, but elected to not make design changes at the last minutes to save an ounce or two.

The plates were all machined without incident, save for two of them, where the insides are shifted relative to the border. This is a classic failure mode of constant-height waterjet cutters before motorized Z-axes were fashionable – if any part of the previous cut interferes with the head, the machine generally bumps the part into a new coordinate system.

While the damage was minor enough on one of them (the top X part) that I could have milled out the slots, it would have weakened the joint significantly due to the loss of material-on-material interference in the joint. The other one pretty much needed replacement, since the error occurred (seemingly) right before the final profile runaround.  I elected to redo both parts at the earliest opportunity.

Also lined up for the first batch was the main lift gear. It’s the same pitch as Überclocker’s previous lifter gear, at 12DP, but the reduction ratio is higher (5:1) instead of about 3:1. This is to make up for the loss of the 216:1 integrated dual frankenboxen for speed reduction purposes. While the difference between a DeWalt gearbox in low gear (52:1) and another 5:1 is still outmatched by the reduction ratio of the IDFB, I think it’s less likely to destroy itself. The DeWalt motors are innately more powerful and torque-balanced than the 550 motors, so perhaps a 260:1 reduction is enough. In fact, it’s more than enough, but the maximum top speed of the lift would be an unnecessary ~15 in/s at the periphery. I’ll deal with the increased current draw, though, because hopefully RageBridge’s low speed exponential response and dynamic braking will make up for it. Maybe it’s time for a closed loop speed feedback…

The small gear is a steel pinion I purchased from McMaster whose hub will be removed and bore broached for a 1/8″ keyway.

Round two of parts. The top and bottom plates are made of my most recent favorite top and bottom material, 1/8″ G10/FR4 garolite in black. There’s some of the usual delamination from high pressure piercing. In the past, I’ve taken care of this by injecting copious amounts of CA glue into the bubble and then slamming it in a vise. A perhaps imperfect repair, but it at least brings some of the strength back in the bubble area.

The tensioner and drive sprockets were also cut at this time. These used the profile shifted sprockets I designed for Chibikart to account for waterjet taper. The tensioners are basically sprocket rings glued to a ball bearing as shown in the topmost example.

A little bit of stuffing with Loctite 609 retaining compound later, and I had the tensioner sprockets. The bore was designed such that they were a near perfect tapered press-fit as cut on one of the MIT waterjets I frequent the most. Different machines would necessitate familiarization before I am able to do such a thing.

Continuing the steps of small, easily pressables, I installed the fork shaft bushings and the outboard support bearing for the lifter motor. The bushings needed finish-reaming after installation since this bore wasn’t that perfect – luckily, I was able to borrow a 1″ adjustable reamer from one of the campus shops. A ring of 609 ensures their retention. After the finish-reaming, I decided to increase the diameter a little further to allow for some alignment slop when it came time to assemble the frame, since otherwise bushings will lock up with any small amount of misalignment.

Round 3 of cutting sees the front “reactive outrigger” parts finished and the replacement frame rails also finished. Now I can really get onto assembling the robot’s structure.

The legs, now that I actually hold them in my hand, are massive. If the bot ends up a little overweight, these are the first parts getting selectively lightened!

The order of assembly of Clocker this time mandates the fork mounting structure be assembled first. This then slides, with the frame’s back member, into the sides. In previous Clocker iterations, this would of course have guaranteed the need to disassemble the entire bot before any work can be done on it, but I hope I correctly allotted space this time around to swap motors and repair drive components without needing to do so.

A first look at the assembled frame of the bot. These pieces are just shoved together for now – there are more parts to make and assemble before I can install all of the t-nuts.

Another item of minor fabrication is attaching the clamp hub shaft collars to the components they will be driving. The two fork tine collars will be tightened securely, while the one on the gear will function as the slip clutch for the system.  #10-32 screws were used for this effort since they fit flush into the counterbored holes in the shaft collar, and plenty of high-strength Loctite 262 were dumped into the threads to make sure I can never, ever take these things apart again. Ideally, I would never need to…

With most of the minor assembly complete, I turned my attention to solving an issue that had been on my mind since the first time Clocker was in a tournament. The clamp actuator has always been really slow, in part because I’ve been using highly geared motors on the Acme thread. Many matches in Clocker’s history have had missed grabs because the clamp just didn’t come down fast enough. Other clampbots in the past have used pnuematics and R/C servos for the clamp arm, so they’re quicker (but each has its own downsides).

One way to solve the problem would have been with a fast-travel leadscrew such as the one I used on Make-a-Bot with 8 threads per inch and 2 starts (so basically a 4 thread per inch). that would net me a 2.5x speed increase. Problem is, that would also entail remaking the Acme threaded sprocket – and I didn’t have either nut or sprocket one on hand. I decided that the force loss was acceptable enough to just take out one stage of the Harbor Freight drill innards which made up the gearbox for the clamp motor. This was a 36:1 gearbox, so taking one stage out is a 6:1 increase in speed.  Because Clocker’s clamp is hypothetically not backdrivable (unless something truly terrible has happened), I don’t actually need that much clamping force to hang onto someone, especially with the big squishy rubber bumper on there.

So, onto the lathe the ring gear goes, and one pass with a parting tool was enough.

The actuator, reclosed with 1″ long #6 screws. I forgot about the fact that my little tension roller standoffs existed, though, and had to go back and trim down two of the 1.5″ long screws that were in this duty so they would fit those.

With that matter taken care of, I embarked on Epic Standoff Evening where I popped out many little round threaded things from tinylathe. With the exception of the tubular spacers (for the fork) at the top, These parts are actually all 7075 too – due to the magic of eBay, once again, I caught a great deal on 3/8″ and 1/2″ rods of 7075. Because some of these parts, namely the axle standoffs, were modeled as steel, I ought to be creeping slowly further down from the initial weight estimate, which is good.

Threading the ends of the standoffs led me to come up with quite possibly the worst tapping fixture known to mankind. No taps were harmed (I think…) in the production of this image. I only used the other drill to hold the piece steady – it was not counter-rotated. Really the way this came about was trying to figure out how to hold the round piece still to thread it without damaging the precision-ground surface, like what would happen if I threw it in a vise like I usually do.

One of the other simple operations was to trim off the hub from the spur gear. At this point, my 1/8″ keyway broach had not yet arrived, so I couldn’t broach the thing, but at the very least it can be prepared.

We conclude this address with pretend-o-bot #1. Still to go in this picture are making the drive wheels, machining the fork’s main axle from the giant aluminum shaft, machining the front leg parts, and finish machining the top and bottom plates. I’ve hopefully ordered the last round of random hardware needed to get the build done. Past that, it’s just waiting for the hired out parts, and possibly formulating a ditch plan…

SensorChibi: Adding Hall Sensors to Chibikart with Hall Sensor Boards

Jan 13, 2013 in D.P.R. Chibikart, Project Build Reports

They’ve made some appearances here and there on my website and others already, but if you haven’t seen them yet, now is the time that I’ll make them public. For a while, I’ve been sproadically making Hall Effect sensor “adapter boards” that can be mounted to R/C outrunners for sensored commutation uses, needed for most ground / vehicular applications. It’s about to get way less sporadic:

Yep, that’s a big cake of them to the left. I’ve also added sizes to the collection. Now, 80mm (“melon”) motors and 50mm outrunners are supported, also. I’m still a bit peeved that Hobbyking had to make their new SK3 “63″ motors actually 59mm in diameter, necessitating a fourth board design. These boards were sent to my usual slow-and-easy PCB house, MyroPCB, and done up in black.

Why 50mm? My general belief is that 50mm outrunners are about the smallest you can really use for a vehicle before they start getting too fast (Kv rating too high) to easily gear down. I foresee the 50mm motors being useful  more in scooters than anything else, where a low profile helps compared to the chubbier 63mm motors, unless your scooter is the size of a small bus.

But the other reason is that the Democratic People’s Republic of Chibikart (Hereafter known as just “chibikart” because why did I pick such a name?) uses them, and on a go-kart where pushing off with your leg is just ruining the point, sensors are pretty critical. I’ve been at a loss to explain how to add sensors to the motors because there is so much customization involved, so Chibikart was published without sensors, but with the sensor boards and attendant plastic ring things and automagically calibrating controllers, I think I’m getting pretty close to an “official solution”.

I’m confident enough in these little widgets to pitch them up on my eventual web store, Big Chuck’s Robot Emporium (d.b.a e0designs.com). Check out these pretty product pictures:

This stuff is getting too legit. I should still make you place orders in the comment thread.

Anyways, here’s what a 50mm SK3 rig looks like installed on Chibikart:

The rings are held in place by pressure from the motor mounting surface – it has to be flat bulkhead mounted, or mounted using the X-shaped plate that comes with these motors generally, to work. So, a setup like Straight RazEr which directly uses standoffs on the motor would not work with this design.

I used a chunk of ribbon cable that conveniently had blue, yellow, and green wires next to each other to make the connection to the board. Because everyone’s going to have different wiring arrangements, I’ll leave it as an exercise to the user to make their own cable harness.

Chibikart has actually been experiencing some technical difficulties recently, and I took this installation as a chance to tear the whole electrical system down and check everything. The symptom was severe battery voltage drop (seen on the motor controller side, after the switch and fuse), usually leading to the controllers dropping out during acceleration. Some times, it just wouldn’t even accelerate. I noticed this getting worse and worse recently.

I started the teardown by injecting a wattmeter between every load point – at the battery (checked out great), behind the fuse (terrible), and in front of the fuse but behind the main switch (also terrible). So the problem was clearly related to the big key switch. When I took apart the joint, the switch was fine, but the wire had corroded in its somewhat poorly crimped terminal!

With the problem found, I restripped and securely soldered that joint. I don’t really trust regular crimp type terminals, and this episode just reinforced my disdain, but they are popular enough that I can’t just get away from them.

Especially not on the batteries. I noticed one of the K2 bricks had a terminal which was clearly darkened from heat. But only one, and not even the one I cracked open. The heating signs may have indicated a bad connection, but I could find no corresponding contact blemishes on any of my connectors. It may have been there for a long time, like since before I adopted them.

Out of some caution, I replaced the K2 bricks with matching A123 bricks (which, despite A123′s slightly indeterminate state at the moment, will be restocked again, I’m told. Also, the lead image of the linked article is Chibikart 1′s battery. I am an amused hamster.)

 

Well, there was a problem. I’d given the Jasontrollers a ‘haircut’ to minimize the wiring mess, but that also entailed cutting off the Hall sensor inputs on them. Oops!

I was able to pull them out just far enough to solder to the wires, so I spliced on a new connector:

Protip: A 4S (4 cell) Lithium battery balance connector is basically a keyed 5 pin connector with wire pigtails attached.  It’s much easier to splice wires than to try and crimp and install these tiny connectors, or solder pin headers, in my opinion, so they might be the Recommended Solution for these sensor boards as a product. It took under 10 minutes to splice both sides, ribbon cable and Jasontroller stubs.

The final setup. Chibikart now has a little fluffy bunny tail made of unused Jasontroller wiring connectors, but in case I ever find that they are useful for something else, I won’t cut them off for now.

The process of tuning the controllers was extremely easy:

  1. Line up one of the sensors with the dead center of a stator winding slot – this guarantees that the 120 electrical degree spacing square waves generated by the Halls have at least one edge that is the zero-radial-flux region  between 2 magnets.
  2. Run the Magical Autotune routine of the Jasontrollers for each side. I decided to do it explicitly using the “self train” wire, but it was clear to me that one side had already picked it up when I was done “training” the other.

I’ll have to write this up officially for the product pages, but if the controller did not have Magical Autotune, the process is much more involved and painful, and for a known working set of 3 sensors it might go:

  1. Line up one sensor with the dead center of a stator winding slot
  2. Fix the Hall Sensor cable combination (for instance, Hall sensor signals [A,B,C] get connected to controller inputs, [A,B,C] for the resulting connection [AA,BB,CC]).
  3. Label the controller phase wires (e.g. [u,v,w]) and the motor phase wires (e.g. [x,y,z])
  4. Start with connecting the motor and controller phases in any combination (e.g. [ux,vy,wz]) and see if the motor turns. If it does not continously rotate (e.g. just wobbles, or moves a small amount and locks up), swap two wires. For instance, the example hookup might become [uy,vx,wz].
  5. If the motor still does not turn, swap the two wires you didn’t swap before.  For instance, the example hookup might become [uy,vz,wx] after this point.
  6. Repeat step 5, continuing to swap the 2 wires you didn’t swap before. There are 6 total ways to arrange 3 unique things with 3 other unique things (3 nPr 3). The example connections list might be
    1. [ux,wy,vz]
    2. [uy,wx,vz]
    3. [uy,wz,vx]
    4. [ux,wz,vy]
    5. [uz,wx,vy]
    6. [uz,wy,vx]
  7. If none of the 6 combinations result in motor rotation, then you have to pick 2 Hall sensor wires to swap. For example. [AB,BA,CC]. Repeat step 5 through 6.
  8. If the motor spins with a combination, but in the wrong directions, then cyclically shift the entire connection. For example, [ux,vy,wz] becomes [uz,vx,wy].
  9. If the motor does not turn any more, cyclically shift one more time. At least one of the shifts will be rotation in the reverse direction. One more cyclic shift and you would arrive back at the first again.
  10. Once rotation has been established, you must time the sensors correctly. This involves an AC or DC ammeter, and the goal is to move the sensor board along its slotted mounts in very small amounts while monitoring the current draw at a reasonable motor speed. Move the sensor board to the point where the current draw is the lowest, for that speed.

In other words, Hall sensors actually suck. Incredibly so – which is why I am so glad the Jasontrollers get the hell out of sensored mode as soon as they can! The timing you establish using that procedure is only the minimum for that speed. For instance, if you time the sensors while the motor is spinning very slowly, then the timing will be too retarded for high speed operation, resulting in high current draw. If you time the sensors at wide open throttle, the timing will be too advanced for low speed running and the motor could have trouble starting since the phases will “fire” too early.

Maybe I’m opening a huge can of magnet wire shaped worms by introducing these things, but hey.

test video

Check out this sweet video of Chibikart totally not needing a punt to start from standstill, even on carpet, while turning! Still no reverse, though.

These sensor rigs will be available on e0designs.com as soon as I hammer out the shopping cart and payment details. If you’re really aching, feel free to email me, though!

 

Introducing Überclocker Advance!

Dec 21, 2012 in Bots, In Progress, Project Build Reports, Überclocker ADVANCE

I’ve been in hiding for the past few days out of fear for my life EVERYBODY IS IN FINAL PROJECT DOOMSDAY MODE!!!! PANIC!!! since I’m a TA/lab instructor for the Media Lab’s famed MAS.863 How to Make (a Huge Mess) out of (Almost) Anything class as well as 16.842, a systems design class based on the DARPA Model Based Amphibious Racing competition (MBARC). I have rants prepared summarizing my experiences in both of those, but that’s for another day.

What’s on deck right now is a brand new version of Überclocker, my ‘flagship’ combat robot (flagbot?), which has been out for retirement since at least 2010 or something. It’s what I have been slowly hammering away at for said past few days, stretching sporadically into the last two weeks or so. I’ve realized that it’s rare to see a explain-the-CAD-image on this site any more, which makes me a little disappointed since so much of the idea synthesis that ultimately determines the fate of a build is contained in the design period, and perhaps my thought processes can help in the design work of others. So in an attempt to go Back to My Roots, I’m going to have an explain-the-CAD picture post summarizing the status of this Überclocker build, now entitled Überclocker ADVANCE! for reasons that are difficult to explain using words.

Let’s face it – Clocker has been a little slow-moving compared to most of my past robots and current vehicle-like things. In 2008, it was completely terrible because I basically square-wave stepped into infinite machining and fabrication resources from almost none, without the attendant knowledge and theoretical foundations to use them. In 2009, I rebuilt it using “every trick in the engineering textbook”, and t-nuts, to wholly unsurprising consequences. 2010 and 2011 were marked by dismal failures brought on mostly from a lack of true concern, since at the time I was well-distracted by the aforementioned vehicle projects, and didn’t really take upgrading and repairing the bot seriously. Finally, in 2012, I stepped back and really upgraded the robot, and it did well consider how terribly I ended up operating the damn thing.

The design of this bot actually has a year and a half of history, at least. My first inklings of a desire to totally start from scratch basically started after Dragon*Con 2011 with this concept solid model, made in a few hours.

It got the basic point across – I was tired of having low ground clearance and tiny wheels with their traction limitations (hence the big wheels). Clocker’s broadside attack weakness (since it’s so damned long, at 27″) was fresh in my mind, so I wanted to make the sides rounded in order to give me some complementary leverage in a pushing match. The legs, while they worked reasonably well, were bulky and some times caught on the stage edges and elements, so I wanted to replace the rollers with a ball shape. All of these things were on track for  addressing in version three. But, that model lasted about as long as I spent designing it.

The next burst of inspiration built off this sketch-model in later 2011. It was on the flight back from my most recent Singapore trip that I went through like all 3 of my spare laptop batteries on the plane and followed up on the sketch-model’s selling points. The end result was this.

My god, it’s round. It’s so round. And it was even mostly circular! Did I mention round? Curvilinear?

This was a very strong candidate for the design at the time. It would still involve a fair bit of waterjetting magic, but the frame was out to become much simpler than Überclocker Remix’s original 2009 frame. I actually spent some serious time making the circular edges as … well, circular as I could.

Sadly, I just straight up forgot about this for a long time after landing. Some part of me still said that the shape was impractical, that I wouldn’t have far to tilt before I lost traction, or that the waterjet puzzle was too complicated to be robust. But damn does it look good.

Fast forward another year, and I’ve basically had enough of this thing. Yeah, it was round. But my reservations were correct in every way I cared about. Überclocker original (2008) and Überclocker Remix (2009) both had very distinct and unique shapes – very flat and sleek, with angular elements everywhere that were neither positively contributory nor very easy to make. My recent Great Awakening with Null Hypothesis, a desire to return to the ugly square drivetrain-dominant bot that just worked more than anything else, pushed me strongly towards ditching the desire to be circular. In the modern Battlebot match, the giant brushless spinning weapon staying alive and driving is, in my opinion, something like 75% of the game. So long as you keep rushing at the other guy, strategically or haphazardly, you’re more likely to curry favor from the judges if you last. In the recent past, Clocker has had… well known issues… with that.

The new idea floating in my head was to make the thing bone simple, at least a simple as a 4-actuator 4-wheel drive bot can get. The frame needed to be just big straight rails. The dual-motor setup for the lifter had to go (because ultimately, one motor jamming or stopping will cause the whole thing to quit functioning), the whole thing needed to get smaller or at least get no bigger, and I really needed more ground clearance.

Images in my mind began forming of basically shoving the fork and clamp assembly onto Null Hypothesis. That bot was fast, had infinite traction from it’s 40A durometer 2″ wide “McMasterBots” wheels, and almost unlimited traction-positive angles because of the big overhung wheels. What it translated into in real life was a bunch of bad whiteboard sketches, including…

Yeah, what?

That looks like a combination of Omegaforce, the Wubba-wubba-Bot that never was, and some agricultural implement. It lasted as long as it took for me to sketch it out.

With the final project blitz happening to every lab class on campus including the two I was involved with, I hunkered down in my stuffnest and began creating geometry in Autodesk Inventor, for realsies (but interrupted roughly every 5 minutes with a different variant of “Do you think using a ____ on my _____ is a good idea? Is there one in the shop?”).

Yup, that it’s. That’s the whole robot.

I’ll admit that my reasons for creating DeWut!? were mostly self-serving. I needed to get away from two things:

  1. Using sketchy-ass 18 volt Chinese cordless drills in anything. Null Hypothesis basically ditches a motor every match. While these drills may have been better in the past, modern product design committees have cut so many corners out of them that they’re pretty well rounded off … literally. The cases have gotten curvier and prettier, but the material quality has really been shat out and redigested. I think they’re still fine for 12lbers, and 30s if they are not overdriven at all, but NH clearly pushed them too far.
  2. Repacking the guts of non-sketchy 18 volt American cordless drills (the DeWalts, which are made in China anyway) into my very sketchily-made aluminum gearcases. You can buy this for $200 already, it’s better than my version, but they’re never in stock.

Hence, if I could get the DeWuts made as a stock solution, then I can design everything around them. And soon, everybody can!

With that model in mind, I quickly started jotting down the geometric outline:

It’s still round.

I just can’t let that go. Cold Arbor was kind of round, and it looked great (but that saw is something I will be ashamed of forever), so I threw it in. The base form is that of Clocker as it exists now – two “pods” on the sides and a simple box frame in the middle, and the fork out front. In this picture, I was trying out Null Hypothesis’ 2″ wide giant caster wheels for looks. While I liked it, it would have caused the bot to be almost 2 feet wide, so they were not the final choice.

The hardest part about starting a new build is usually anchoring the design. Where the hell do you start, and what part do you start with? I found that making the outline made the choice much easier since it was then easy to see right in front of you what is holding the bot together.

After Clocker’s 2012 adventures, I tacked on some more items onto my list of grand design intents. The full rundown was now:

  1. More practical and easy to build, as previously described
  2. Higher ground clearance and increased maneuverability, as previously described
  3. The ability to resist or defend against broadside attacks, because round
  4. Making the legs actually useful.
  5. Making the clamping action much quicker

Here’s what I mean by all that.

Making the legs actually useful

Clocker’s “reactive outriggers’ are probably its best feature. The idea is when a 30lb opponent is lifted, the weight shifts forward and the robot gets up on two wheels and the rollers at the end of the outriggers. Hence, the robot still maintains traction and can move while carrying an opponent without hoisting it up all the way. Many historical clamp type weapons like Darkangel and Complete Control (both Clocker inspirations!) have static outriggers that function only to prevent tipping.

Here’s a picture all the way back from clocker 1 in 2008 that shows the principle.

That’s where the fun begins. The idea is basically to spin the opponent in a circle and then let go – not causing damage per se, but it looks intense. Some times it backfires. Other times it’s a big hit at the event.

The problem is that it really only works for a limited range of opponents because of how short the legs on the original Clocker and Remix (2009-current version) were. A little too chunky and Clocker would just faceplant. If they were too small or compact, then I don’t really get enough displacement to break rear traction. If the ratio of leg length to wheelbase were higher, then the range of spinnable opponents would also increase because it would both let me tilt forward with less weight and be more stable in that configuration.

Next, the “doubly supported” legs of the original bot, and Remix as a consequence, were a severe pain to remove if the drivetrain needed servicing (and my goodness did it need servicing…). It used a different hex wrench diameter than the rest of the stuff on the side, and there were 2 screws and 2 washers to line up correctly to remount them.

Some times, a single big chunk of metal is warranted over a creatively sculpted series of smaller chunks. I wanted this build to use a single, thicker ‘leg’ per side that could easily be removed and swapped if needed, from one side of the bot.

Making the clamping action quicker

Unlike many clampbots of smaller weight classes that use R/C servos or larger weight classes that use pneumatics, Clocker has an electric linear actuator to reduce complexity while still offering good grip strength – an R/C servo of this size class exists, but all I know about it is that it’sreally expensive. So, the clamping action is admittedly a little slow. This has resulted in a quite a few missed grip chances in the past.

This particular grievance isn’t a major design element, since Clocker’s clamp actuator was pulled from Cold Arbor and can be customized in several ways. I’m thinking of either switching up the leadscrew from a 10 TPI to an 8tpi fast-travel screw (with 2 starts, so effectively 4 TPI), which would make for a 2.5x increase in tip speed. Else, I can remove a whole stage of gearing from the chopped 36:1 drill gearbox that runs the actuator in order to effect a 6x increase in speed.

It’s a little hard to decide, since I’d have to weight the costs and benefits – namely, how much clamping pressure do I really need? If I could get 6x more speed and not really sacrifice how hard I can hang onto the opponent, then it’s worthwhile. Alternatively, I’ve used the clamp as an emergency lifting arm in the past, so maybe I don’t want to sacrifice so much torque.

Oh, wait, I forgot one thing…

Not needing 3 different sizes of hex wrench, 2 of which must be ball ended, and 20 minutes in order to fix anything.

Probably the worst thing about Clocker is how hard it was to pull anything. At D*C2012, I had to take out the lifter gearbox in order to remove one gear stage from it that had stripped out and binded up the whole thing. It took pretty much exactly 20 minutes to take the robot apart and put it back together, just as I had experienced in the shop. This design goal kind of goes with the simpler and more practical frame design.

Now, where was I? Onto the actual evolution of the design.

I very rarely use an outline of the bot as a design guide, but this time I founded it immensely helpful to visualize how all the parts will interact, roughly, before committing a part file to it. Above is shown an arrangement of the parts as conceived fairly early on, including the Third DeWut that will run the big fork. That’s right – no more weird dual-motor gearbox.

I was fighting back and forth about whether to do direct-drive to one wheel and chain/belt to the other (per side) or an indirect drive to both wheels with the motor in the middle somewhere. It was primarily finding a balance between 3 variables – whether or not the bot needed more ground clearance, the kind of speeds I could get with either method, and where I had to stuff everything else.

If the rear drive wheel were mounted in-line with the motors, then I would be limited to a maximum theoretical ground clearance (i.e. without any type of bottom armor) of 0.75″ with 4″ wheels. If I designed Clocker solely for smooth-arena combat, the ground clearance would be only 0.25″ at most using 3″ wheels, but this is not the case, so 4″ is pretty much required. 0.75″ clearance is what Null Hypothesis and the latest Überclocker all run with, and it seems to be fine for the stage combat scenario of Robot Battles. It would limit me to three speed ranges dictated by which gear I put the DeWalt geaboxes in – they have a 450, 1450, and 2000 RPM ranges (at stock voltage, rated by the company).

Now, I’m dead set on overvolting 18v motors to 24v at least (or rather, 25.6v for 8S A123 cells), because it’s a glaring sign of n00b to run motors at their rated voltage. At the very least, 7S must be used to be comparable in drive power to the current version of Clocker. This depended on how creative I could get with placing the battery itself. At 8S, I would see a (theoretical) top speed of 24mph in the middle gear. Yikes… that’s pretty high. But the alternative, 8mph, in low gear, is really really slow. At 18 volts or 6S A123 cells, the top speed would be a more tame 17mph, more to my liking but a little on the high side. So, wheel-on-motor would be a good choice if I was satisfied with 18 volt electrical systems and 0.75″ ground clearance.

However, if the wheels were not directly in line, I have more options. I could run 3″ wheels at below motor center line to retain the same level of ground clearance , but more manageable speeds. The motor location would be significantly more flexible. It’s wholly possible to run a 1:1 using chain or belts and with the motor not directly connected to either wheel – in this arrangement, my speed at 24v would be still 18mph, which is excellent.

The next variable to consider is how much tractive authority I wanted. By this, I mean how far can the robot be tilted or rolled without losing tractive authority? This would dictate my ability to escape from bad situations – the speed might be enough to avoid them, but if I ever got in one with a low clearance bot with little stubby wheels, it could be worse. Bigger wheels will always help with this problem.

I decided it was worth trying a 1″ ground clearance experiment using 4″ wheels. It would be a new design direction for me, since I have classically favored flat robots. Ideally this would make Clocker virtually impossible to wedge under because it would take incredible effort to break its traction fully. I wanted to leave space for the option of 8S packs, even though it meant a mid-20s top speed, because I could always back down from there and save some weight if that was warranted. A greater tractive authority combined with high speeds makes a bot much harder to catch.

The culmination of all this reasoning and pulling tradeoffs back and forth is many hours of positioning components and thinking of what parts go with the configuration, and roughly how fast it would go. Some times, a good arrangement existed for battery and motor placement, but there was not really space left for the Ragebridges. I made configurations with one Ragebridge per side (instead of 2 stacked on top), the battery in the front (not optimal for center of gravity), and even offset motors.

Ultimately, here’s what it came down to:

I had to release one constraint to settle upon this, and that’s the bot’s width. Clocker is already huge for a 30lber, covering a 18 x 27″ footprint. That’s bigger than some former 60lb Battlebots lightweights. Part of it’s unavoidable with this kind of design, where I have to contain a majority of another opponent.

Only by letting myself build a 19″ wide bot could I fit an up-to-8S pack in the rear along with the ragebridges. The motors and battery pack were now all rear-biased, which was favorable for CG reasons.

The observant would notice that I went back to the 1″ wide wheels after the previous shot. There were 2 primary reasons for that move. First, I really wanted doubly-supported wheels with static (standoff-like) axles. This increases the rigidity of the frame over a single supported wheel, and also lets the outer frame rails act as wheel armor. And second, those 2″ wide wheels would have pushed the bot width dangerously close to 2 feet.

After this part of the design was roughed out, everything else began falling in place. There’s really only one place to put the clamp and fork, really.

The next big challenge was how to mount the fork assembly. Clocker’s current configuration is a little “torsionally unsound” in that the force of a 30lb opponent capture in the fork is reacted entirely by the front frame cross-members twisting. Said front cross-members are also just flat plates, which are known to be very poor in torsional loads. Without the top and bottom plating to support them, the whole thing just lurches back and forth if any load is applied to the fork. While the latter configuration is acceptable (loaded top and bottom armor), I don’t like it as much because it depends on a material much less stiff than the aluminum (i.e. sketchy McMaster FR4 garolite plates) to handle the loads – I’d rather have a more “atomic” structure.

In the above image I’ve whipped up a pretty simple first-pass attempt at the clamp motor and pivot mounting structure. At this point, I was still relatively unsure about how to attach the whole thing to the frame.  The two big top-level choices were a CRJW style standoff tower (preloaded like mad) or just two crossing trussed-out 2.5″ tall aluminum flat plate members, separated a few inches. CRJW’s build style worked out very well with respect to overall stiffness, so I initially favored it.

I was also split between chains or gears for the main lifting drive. The first Clocker used #25 chain, the second used giant custom spur gears. At first, I figured chain would be easier to make an assembly with  because it was narrower yet more flexible (in terms of positioning the components). Hence, at this point, I still had a narrow assembly set up for a #35 chain (for more durability over #25) assuming I’d drop a sprocket in there.

However, what I eventually realized is that chains need space to exist, and I’d need to cut huge gaps out of the frame to pass the chain through. A sprocket combination that got me the needed external reduction in other to not make the fork a fucking hammer meant the large sprocket was almost approaching 6″ across!

I could more easily get 5 or 6:1 in a set of spur gears, whereas the same ratio in a chain necessitated a 9 or 10 tooth sprocket, known to be extremely weak and highly stressing on the chain. So with my brief excursion into the dreamland of chain drive complete, I returned to modeling the assembly to favor a set of big custom 12 pitch spur gears. The assembly would have to get much wider, of course, but this was a minor adjustment.

Here’s a random picture of a gear.

Needing a bit of mental break, I decided to get really creative with a spur gear and embedded the “overclocked” Doomsday Clock motif that appears in every Überclocker. About 3 people will ever get it, and it doesn’t actually make sense to put on the bot. But hey, it’ll look pretty in the model!

I went through an entire round of parts arrangement with the standoffs-style structure that involved lots of shifting the motor and gear around. I wanted the ability to use all 4 corner holes for fastening, else the continuous structural loop would be sacrificed, reducing stiffness. But this generally involved crossing a spur gear (or a chain sprocket), so the gear had to be moved or the fastening hole had to be moved. Keeping the standoffs spaced as far apart as possible maximizes the stiffness of the assembly, but that was of course in direct conflict with whether or not I could stuff a motor and gearing into the same projected space.

After a while, I began realizing that the conflicting goals were pretty much irreconcilable given my choice of constraints and the desired size and aesthetics of the bot. Taking apart a bunch of standoffs would also be a serious maintenance problem (I’d need a clear, straight-shot space across the bot to pull a threaded rod out of). Maybe some crossing spans weren’t so bad after all?

They weren’t. Making the pivot axis of the fork directly over the motor (as opposed to offset in front of it) meant that I didn’t have to make as large of a cutout in the frame rails as I had expected. This allowed the condensation of the assembly to only 3.5″ wide – basically, just enough to contain the motor itself.

In this arrangement if I torqued the pivot axis hard (like hanging a 30lb opponent a foot away) the twisting load is taken up by shearing 4 2.5″ wide bars across their width, basically. Much better than twisting the same bars about their own center axes. This is incredibly difficult to explain in more detail without a thousand more words dedicated to it, or a cute drawing/diagram.

I’ve closed off the structural loop around the fork motor now, and am pretty satisfied with how this turned out.

I try to not optimize anything too hard until the whole system has materialized to some degree, so I moved on immediately towards filling out the less critical parts of the bot, like the fork tines. These were laid out using the outline as a guide, but not for dimensional accuracy. Check out the fish hooks on the end – I’m gonna keep them in “production” just because they look pretty cool (uh oh…), and I also foresee them aiding in sliding under someone’s side armor and catching them. Worst case, I’ll sand them off, so who cares?!

I added the top clamp from Clocker’s 2012 incarnation, which was a newly built assembly, to see how it looks. I’m going to keep this clamp because it’s already built to work with the geometry of taller robots. The pretend-o-bot is starting to form. At this point, I’ve gone back and diddled with the geometry of the motor mount some more in order to get a more favorable “angle of decent” of the fork. As it turned out, a totally centerline pivot point forced the descending part of the fork to be very shallow, which made the ‘active’ part shorter but also let the fork swing down lower (before it hit the motor mount). Here, there was a tradeoff of “do I really want Clocker to lift it self off the ground?” – while it seemed advantageous for making sure I win the wedge war, it would be a disaster for expedient driving and maneuvering since the bot would be effectively high centering itself.

So, in the end, a steeper angle won out since I could hard-stop the fork just barely above the ground. I’ll deal with wedges as they come.

I’ll be reusing the clamp actuator too. Some time was spent playing the Geometry Game (midway down in this post) trying to maximize the range of travel without having the motor impact anything. This time, the components played out in my favor and made a little corner that the motor could stick into without running into the pivot shaft, as well as being protected on most sides by the bot structure!

A geometric example of a new leg has been added, too. The new design calls for this to be machined from solid 3/4″ aluminum. Chunky? Yeah, definitely. But, I need the stiffness if it’s going to be single-supported and stick out that far.

Here’s a bit of SCIENCE!! which I used to sanity check myself when designing the leg. I basically took a reasonable guess at how much instantaneous force the leg will see if Clocker just ran into a wall for no reason – say 1500 lb-force, applied directly to the big roller screw. Then I assumed the bot was infinitely stiff and could hold the leg still at the rear where it is attached. Then I told Inventor to pull some magic and tell me how much it deforms. Result: Probably about .25″ in compression and bending, and I’m more likely than not going to bend the roller screw.

That’s okay, I’ll make spares. A 0.5″ wide leg made Inventor yell at me for large displacements – that indicated some degree of hopelessness.

Realistically, a static FEA calculation isn’t going to capture the whole picture. The bot is not infinitely stiff – if it dives into a wall, the frame will most likely bend significantly at the mounting point, too, absorbing some of the hit energy. The suspension spring could also take up some of that force. The only question, really, is if the whole thing will just stay bent after it, which could be found out with More Analysis I’m not currently in the mood for. Just ship it.

At this point, I was starting to look at just making small refinements. I’ve taken the liberty of shortening the bot a little closer to original dimensions. This was accomplished by swapping spaces with one of the chain tensioners – before, I was limited in how far back I could move the fork pivot axis by how close I could move the tensioner to the main drive sprocket.

Well why not just swap them then?

I threw the current version of clocker in just for a size comparison. As can be observed, the ratio of robot to fork has decreased somewhat, and the ratio of leg length to wheelbase has increased. The frame itself is a tad shorter, but wider. And much taller. Overall,  Clocker ADVANCE occupies a bigger bounding box, but most of it is pretty spindly and empty.

When I was happy with the placement of parts, I began the t-nutting.

Now, I promised to not t-nut so prolifically any more, but this situation warrants it, I swear! The little gussets and brackets will double both as frame binding elements as well as top and bottom plate mounting points. The difference in this case being the top and bottom plates are made no longer structural – just to hold the guts in, not to take loading (short of direct impacts, which will be guarded from with piles of ablative material). These are far less egregious than Clocker Remix’s frame.

Additionally, the presence of the U-shaped gussets in the motor mount strengths that region from twisting even more.

The best part? The lifter motor pops out after undoing 4 screws accessible from the front. It drops out the bottom and can be immediately replaced. The drive motors will take a little more thought.

One issue I ran into was how to retain the gussets from moving in the Z-axis. The last picture showed pretty well an underconstrained joint – i.e. in the absence of friction, it could still slide out the top or bottom. Only friction retains it in real life.

By insetting the fingers fully into slots, I capture them in the Z direction, too. The downside is making the left and right chassis rails 0.125″ taller per side. I found this inconsequential because INFINITE GROUND CLEARANCE. Now, with these captured slots, there is also a clear assembly order for the bot – everything in the middle first, side plates go on last.

I turned my attention to the legs now, and devising a real mounting solution for them. They pivot directly on the front drive wheel’s axis, on a shoulder screw (which also anchors down the front drive axle standoff itself. I devised entirely new shock absorber things for this build, because I need to go up in spring stiffness to counteract the longer lever arm. The basic principle is still the same, however. Waterjetted from the same chunk of metal I will presumably make the legs from, then secondary machined.

I’m considering making a little extension to the frame to put these parts in “double shear” mode which will once again increase their stiffness. I decided to leave this until after the rest of the bot was modeled, since by this point I was getting close on weight.

Notice the blue string running around the model sprockets? I decided to try out Inventor’s chain drive designer for realsies this time. Prior to this, I’d only used it to generate sprocket profiles for machining. But as it turns out, it will tell you exactly how many links you need and whether or not you have enough tensioner travel to last the life of the chain, because chains stretch a few % with age (The answer for me was no, not for 10,000 hours anyway). You select existing cylindrical axes and tell it how big each sprocket is. You can even say a certain axis has an allowable amount of wobble (to make cam style tensioners) or can move in the XY plane a certain amount (for linear sliding tensioners). Then it will update whenever the sprockets are moved, and yell at you if you move them to an impossible position or you need to adjust your tensioners.

Wow. Computers are pretty damn cool.

In seeking more structure for the outer side plate, I decided to extend said tensioners to become standoffs in their own right. These have off-center holes so I can rotate them and then tighten down the long screw that binds the two plates together.

I added simulated top and bottom plates for the final almost-finished look.

At this point, the bot “weighed” 31.0 pounds. Uh oh… All that solid metal has to go. I want it to weigh 28 pounds or so in order to include overhead from wiring and screws I did not yet model (most of the big bolts were put in already).

Clocker Remix is very much “gothic cathedral’d out”, my term for making structures sparse and spindly to reduce weight, like… gothic cathedrals. I’m sure those guys did it less for weight and more because they were badasses, but whatever. However, it was done rather haphazardly – I have truss elements that really don’t do much and could have been totally absent (Did you know that trusses triangles are ideally all equilateral?)

And that’s it.

After selectively trussing out most of the plates and adjusting the height of others, the bot is now at 28.6 pounds as-modeled (with more big screws added, too). The side plates have gotten much lower (and name-emblazoned), which saved a ton of weight. I added one more standoff to raise the stiffness of that outer rail some more. The lowered sides also makes the motor mounting screws that much more easier to access. The only plate not hollowed out right now is the very back, which I’ve decided to keep solid because the bot otherwise has no rear armoring.

And the back shot.

in conclusion,

this is the longest post ever on my website at about 5500 words! I keep upping this number for some reason. It’s been a long time since a pure CAD-based brain-dump post, and I must say it was rather refreshing. Airing out decisions that you have made, makes you think about them more and critique them a little more impartially.

Construction on Clocker will commence as soon as everything opens up again after the Christmas-New-Years-What-Have-You holiday season. The target is Motorama 2013 (more strictly Robot Conflict @ Motorama 2013), an event I haven’t been to since Clocker and Arbor’s collective dismal losses in 2010!