Every post about Landbearshark ends with the motor controllers exploding

Sunday, January 22nd, 2012 @ 17:18 | Land-Bear-Shark, Project Build Reports

This one is no different. In fact, it will happen twice in this one post. Isn’t that amazing? One of them is due to Sudden Hobbyking Death Syndrome, and the other was most likely caused by laziness-induced idiocy. No, I haven’t fixed Tinytroller yet.

First, I would like to announce that my meterological precognition skills are infallible. On the day after I took apart LBS to install the load cells and wire them in, it snowed!

I swear this has nothing to do with the fact that it was going to snow anyway….seriously. Granted, it was only about 2 inches, but for one reason or another it’s the first two inches of snow this Winter. No, the October one didn’t count. 2 inches is better than asphalt, so I immediately restored LBS to its Last Good Hardware Configuration and we rolled it outside for some successful parking lot rompage. However, it still had its tilty board in this state, which caused the handling to be very unstable especially after water got into the friction washer stack and unfrictioned it.

After rolling back in, I decided to lock the board and revert LBS to full R/C once again in preparation for the next round of snow; in other words, the same state as it was for Maker Faire, but slightly more brushless and less reliable. The big rubber bushing was replaced by a chunk of very conveniently sized aluminum round, standoffs from a large chem lab shaker table that was parted out and scrapped. So while the tilty-hinge still technically exists, there’s no way I will physically bend that 1.5″ diameter round.

 

There was another important reason for the reversion to hand control. I wanted to take advantage of the built-in Xbee radio interface on the Nano Carrier to log the load cell readings on my computer as I was riding LBS around. I had suspected that the load cells would pick up any force transmitted through them, including the high frequency rumble of the tracks. The choice of datalogging program was the Arduino UI’s built in Serial monitor, and the number crunching was done in Matlab. After trying a few runs, I found that the board looseness made a clean straight line run nearly impossible. I was aiming to look at only one variable at a time, and the board steering kind of ruined that.

So, back to R/C it was. I elected to try a completely unfiltered (raw readings) run, a run with a 1 second first-order low pass filter on the two load cell readings (done in software), another run with a 0.5 second filter, 0.25s filter, 0.125s filter, etc. The numbers were arbitrary to start with, but geometrically spaced to cover a wide range of values. The tests were done in a straight hallway with a smooth linoleum floor with me standing upright and minimally compensating for vehicle acceleration – i.e. not leaning hard in one direction or the other.

And now, pretty graphs.

AAAAAAAAAAAAHHHHHHHHHHHHHHH

What is that garbage?

During tracks-up testing, I noticed a strange propensity for the op-amp outputs to suddenly go to zero whenever any throttle was applied. The tracks didn’t even have to be moving – if the controllers were trying to power the motor past the stiction of the drivetrain, without actually producing movement, the op amps would rail and then jitter erratically. Keeping in mind these were instrumentation amplifiers with gains of about 300, any millivolts of induced noise could be amplified and picked up by the Arduino. I kept the sensor wiring as far from big power cables as I could, but that made little difference. I’m also fairly confident that I have no strange ungrounded components or missing connections, as the load cell readings are great as long as the motor controllers weren’t powering.

Seems like movement helps the situation a little, but there are still plenty of instances where the readings are just trash, and plenty of places where they’re just zero.  The peak to peak noise during the movement portion of the test is on the order of 25+ kilograms.

Okay, let’s try a really slow filter:

This is a 1 second time constant low pass filter on the data. Hey, that’s starting to look like something now. There’s still spikes and jitter during the movement phase, and it’s very clear that the sensors take a long time to settle. The middle portion of the graph, while a bit spiky, clearly shows me standing mostly level (the readings are similar) That huge spike at the end is me leaning back to compensate for vehicle braking, then jumping off. The fall time of the filter shows a very clear 1 second exponential decay.

Perhaps this is a little too slow to be practical. Let’s try 0.5 seconds:

Oh dear, some of the ground rail strikes and noise is coming back now. The beginning and end show clear signs of me jumping on and jumping back off, and the middle (movement) portion is probably filled with a high percentage of zeros.

And now for the 0.25 second filter:

Unfortunately, the test had to be suspended because one of the 80A HKcartrollers detonated on powerup. I am really not sure what went on here – it was working great literally 5 minutes beforehand and I made no other hardware changes to the system.

My suspicions fall on the left side motor being found to be way out of proper sensor timing range – while I’m not sure on how it happened, it was clear from test running the motor that the sensor ring shifted significantly. This would have caused very high and excessive current draw any time the left track was being run, consequently current-stressing the controller and possibly causing one phase leg to fail short. The next time the power was turned on? Instant pop. Unfortunately, it doesn’t speak very well to the reliability of the cartroller if they can be “plastically deformed” by excessive current. Then again, it’s also risky using a motor which can potentially draw over 400 amps shorted at 18 volts (Those SK motors with an internal resistance of like 30 milliohms) with a controller that has no sense of self-preservation.

Sadness.

Ultimately what I’m seeking isn’t really a clean total weight, but a reliable delta or difference between the front and rear sensors. To that end, I think the measurements are reasonably useful. What I can observe based on the unfiltered readings, though, is that a simple low pass filter is not enough to accurately obtain an estimate of where the rider center of gravity is with the amplifiers in their current noisy and rail-prone states. If I can’t get to the bottom of the amplifier issue, then I will have to implement methods of throwing out data points which are obviously bogus, like the sudden zeroes, or throwing out any data point which is out of some defined bound from the current estimate. Dear god, I might actually need a Kalman filter.

round 2

It was going to snow again yesterday, so I begged a replacement HK Cartroller from jume just to have the thing running again. This time, the goal was to get out there before they started plowing and salting. LBS was kept in load cell, full hand control mode, but I wasn’t really out to take data so much as just diddle in the snow as it was designed to do more than a year ago.

This mission was very successful, as long as I wasn’t on it.

Driving LBS in the snow like that in dumb robot mode totally made me miss building and driving…. robots. I had a small moment there.

Anyways, actual riding performance in the snow was fairly good. It was MUCH better with the board locked – while I was previously not very keen on the idea of using four corner load sensing (so the board is essentially fixed but I can still estimate which way I’m leaning), I’m starting to get the feeling that taking out one degree of freedom in the system will make it easier to ride. Unfortunately, I didn’t get to film the first outside ride run, which went without problems until the left side chain broke.

After compressed-airing off all the snow that had gotten into the frame from doing the riderless snow-donuts (OH GOD MY ARDUINOS) and repairing the left side chain, I took it out for a second run, upon which the other chain promptly jumped off the sprockets, but this time jamming between the rear drive sprocket and the frame. That locked up the motor for a brief instant, but it was enough to toast the other cartroller. Again, the symptom was instantaneous failure on next power cycle.

Very mysterious and a little irritating.

The reason for these chain hops? I neglected to install my tensioners. You know, those little 3d printed donut sprockets that I’ve had on LBS since forever, but removed for this drivetrain version because the tension was “just right”. All chains loosen slightly once they wear in the rough forged and machined surfaces on their pins and rollers, a fact that I actively neglected.  Also, my main drive sprocket is not chamfered like all normal sprockets should be. This makes them extra-vulnerable to very slightly axial movement of the chain. I don’t want to take the drivetrain apart again, so I might do an in-place chamfer grind with a Dremel or something.

I did remount the chain tensioners after bringing LBS back inside, but now i’m out of cartrollers. I am also not sure if I want to keep replacing them – like most hobby parts, they seem to work great if not run near their maximum capacity on a system which cannot damage them through current spikes… which a 63mm aircraft motor definitely will do very easily.

While I hate to think about it, going back to Kelly KBS controllers is very tempting. They have torque control, current limiting, variable braking, and reverse… and have been running Tinykart quite well once the motor sensor timing was dialed in – something the original C80/85 “short melons” were not treated with. As I discovered when trying them with Tinytroller, the sensors as-installed were practically useless.

Going back to Kellys would mean I can run at 36+ volts again, and I can rewind the SK motors to optimize their torque production for that range, and… Hey, isn’t doing that just going full circle? Maybe I should just use some short magmotors and a Vantec RDFR36E just like an old school Battlebot. Or, go back to the CIM motors and use Victors, like a FIRST robot. I should just keep this thing as a robot and pile 200 pounds of steel on top of it to give it more traction.

Oh yeah, here’s what an exploded HK cartroller board looks like:

For the record, they emit pink smoke!

 

Recently

  • Silly Go-Kart Design: The 2014 Summer Season
  • Chibi-Mikuvan: Detroit Recap and The Conclusion
  • Chibi-Mikuvan: The Penultimate Update!
  • Chibi-Mikuvan: Getting “Tired” of All This; Making the HCL Actually Function; Plus Other Work
  • Chibi-Mikuvan: Experimenting with the Trackstar 200A and the Hysterical Current Limiter
  • Beyond Unboxing: The Great Cambridge Chainsaw Massacre; Ryobi RY40511 Cordless Chainsaw
  • Chibi-Mikuvan The Extended Universe Edition: Water Cooling Loop and Digital Dash
  • Chibi-Mikuvan: More Stickers is More Power, Right?
  • Miscellaneous Van Adventures: Fuel and Coolant
  • 2.00gokart: The 2014 Season!
  •  

    3 Responses to “Every post about Landbearshark ends with the motor controllers exploding”

    1. Jamo_G Says:

      Relays.

    2. Jed Says:

      BOOM

    3. Steven Martin Says:

      Considered reprogramming the HK controller? You could potentially do “virtual” current limiting. Which might help to some extent and you can also get rid of that pesky reverse delay. This is on my TODO list for some other projects I have the pinout mapped but completely untested if you want me to send it to you.

      I mapped the pinout flashed it with firmware to pulse the 2 LEDs and haven’t touched it since. I will get back to it sometime.