Archive for the 'Land-Bear-Shark' Category

 

LandBearShark 2 is finished, but it isn’t snowing anymore.

Dec 05, 2012 in Land-Bear-Shark, Project Build Reports

Well, I can’t say that I didn’t already finish LBS2 like 2 weeks ago. I did, in fact, and it’s been around the block a few times already. But sadly, since then, there’s been no snow in the weather forecast. Meaningful amounts, anyway – a few flurries fell here and there last week, but what good is that? Do I really need to take this thing to New Hampshire!?

I was counting on some snowfall to let me combine a little testing video with the rest of the build, but given that seems unlikely to happen, here’s the build in its entirety.

The first step in rebuilding is to retire the old design. Here is LBS pulled out of under-table storage. A little dusty, but it still looks kind of glorious.

The big ATV style crashbar is not returning in the new design, because really, it was just too over the top. It was funny and contributed to the very unique look of the thing, but it also weighed about 10 pounds (made of surplus 1/8″ wall steel tubing…) and the mounting design was very much optimized for the old frame and I couldn’t quite make the design work with the new aluminum one.

Otherwise, electronics aside, many component parts of LBS are being reused. I don’t think I’m quite at the level of the Ship of Theseus yet…

LBS has been reduced to components. I took the opportunity to perform a mass cleaning of all the track parts because they had been subject to substantial dirt and grime buildup. The chains, especially, took a distressing amount of soaking in brake and carb cleaner and like an entire roll of shop towels. Chains are terrible things.

Its former frame was used as a collection bin for most of my other retired aluminum-bodied projects. I was intending on pitching it in a shop’s aluminum recycling dumpster, but ended up putting it up on Reuse (the free stuff mailing list) for people’s amusement. I figured that had I been a happy froshy bunny during this time, I would be so extremely excited, jumpy, and otherwise bunny-like if somebody posted a pile of waterjet-cut aluminum parts to Reuse that I might start building project of my own spurred by the simple fact of possessing these items. That was the plan, anyway. Paying it forward for the next happy bunny that bounces into MITERS.

(Some of it was used immediately in a productive fashion).

One of the first build exercises was spacer and standoff-making. Most of these short ones shown are parts that will go into the motor mount, suspension, and new bogies.

I’ve been gradually liberalizing from my usual hardline t-nutting policies in favor of using material more effectively when the design calls for it. In fact, LBS was one of my last major giant t-nutted plate assemblies (the other being Make-a-Bot). I actually can’t think of anything I built from scratch in 2011 and 2012 which made gratuitous use of plates where they weren’t effective.

I’m thinking it’s about time to update the How to Build your Robot Really Really Fast document I wrote some time in 2010 to be a more thorough treatment of various design for assembly manufacturing methods, rather than a cursory overview of standoffs and t-nuts.

With a few of the necessary spacers done, I turned my attention to assembling my Fake Andymark Gearboxen. I’m a fan of their very inexpensive (compared to industrial suppliers, anyway) hubless spur gears because for most robotics-related purposes, hubbed spur gears add unnecessary bulk and weight if you are just making cluster gears anyway, or using another method of power transmission like splines or direct coupling to the driven member. In fact I’m such a fan that I’ll plug them some more: SPUR GEARS!

(Some mixing and matching may be involved.)

The way my intermediate gear shaft goes together is simple. Take a hex shaft chunk, stuff a bushing into it (drilled and bored on tinylathe), then start piling hex-bore spacers and hex-bore gears onto it. A hex bore custom sprocket is in the middle somewhere. On each end is a bronze thrust washer to keep everything in check axially.

The whole assembly was purposefully made a few thousandths of an inch shorter than the length of the center standoff – involving shaving a bit of material from one of the hex bore spacers – that it could spin freely once lubed up a little, and kept itself in place. Bam, fast-build gearbox without machining complex shafts and retaining features.

I’ll also admit I am a slow convert to the hazardous, addictive, and self-destructive world of hexagonal shafts. They’re just so easy.

The two Fake Andymark Gearboxen completed. These have no mounting bolt pattern – they are hung from the center Big Shaft of the vehicle, and kept from moving by chain tension on one side and the chain tensioner on the other, upon which they brace against.

Onto frame assembly. Did I say I wasn’t going to make T-nutted things any more?

Nah, no way. I’ve not become that unprincipled. There are still a few holding the frame together, but they are no longer the majority contributor to frame rigidity. In this case, it’s pretty much just for making the right angle joint that will be backed up by long threaded rod-and-spacer preloaded columns (see Carly Rae Jepsen’s build style), which can add much more rigidity than an equivalent floppy plate span.

The bogie frames this time are much lighter in section, and maybe a little too flowy looking. The reason is that these never took subtantial structural loads anyway – recall that even in LBS version 1, they were hinged in the center at the Big Shaft. The load path goes from the rider weight into the Big Shaft, where it is met by reaction force coming from the ground, going through the track sprockets and into the track axles. But that load is expressed primarily in torsion (out of plane twisting) of the bogie frame sides, because the suspension is so damn stiff that it’s basically a truss member. LBS has always ‘sagged’ a little as a result of this torsion (think overloaded car), so there was no reason to keep using the huge heavy side plates.

The much lighter cross section of the new bogies saves about 3 pounds and cuts the design down to basically the bare amount needed to connect the dots in terms of mounting points.

Now it’s starting to look like some kind of cracked out Mars rover, or a kinetic sculpture. Everything gets slid onto the Big Shaft at once, secured by shaft collars. I switched to a 3/4″ diameter axle this time – LBS1 had a 20mm one, which is a dimension I have no clue why I picked initially, but 20mm shaft collars are espensive and I needed a few more of them anyway. 3/4″ was the closest size to 20mm that still allowed me some space to clear the CIM motors, and wouldn’t be bendy under rider weight.

After a brief game of Which One-off Spacer Is This?! I began to put the track wheels back on, and also slipped the motors onto the Big Shaft.

Without the outside bogie frames keeping the axles on center, slipping on the track itself was easy – the whole assembly just kind of bent in enough. I did have to spreader-clamp the axles to make all the screws go in, though. Overall, the track tension has increased over version 1, since it was known to be somewhat loose.

After the track pods were slipped back on, the project reached criticality. At this point, with the chains not hooked up yet, I was supermanning it and coasting down the hall – not very far, of course.

Moving onto electronics, I’ve punched together the electronics box and mounted the switch and cooling fan. Little rubber grommets have been installed in the bottom where the motor wires will enter. I also drilled, tapped the eventual RageBridge mounting holes and installed standoffs.

The box mounts to the frame using these little hanger hooks which interface with bolt heads sticking out of the electronics box. The arrangement is self-securing (the force vector of the box being loaded downwards tends to pull the hooks tighter together), or at least theoretically so – if not, zip ties will rescue it. The rear hooks were swung out, the entire box slid into position and rested on the front hooks, then the rear ones tightened down again.

Much of the wiring was recovered from the old LBS, and I made the RageBridge wiring harness to match it. Here’s one of them mounted to test for fit and wire clearance.

I took some time to finally repair LBS’s somewhat decrepit batteries. These were made 2 years ago and suffered a balancer cable short & fire some time afterwards. Since then, they have been wrapped in bubble wrap and duct tape, charged and discharged without regard to inter-cell balance.

To my surprise the cell banks were at most 50 or so millivolts out from eachother. While still alot, it’s quite a testment to the durability of A123 cells. Too bad the company itself… isn’t very.

I remade the balance harness, this time carefully routing the cables out the side of the pack, then wrapped the entire thing in some foam rubber with Kapton and fiber-reinforced strapping tape. After a night of balance charging, they were all leveled out and ready again.

The two RageBridges were stacked together with some 3/4″ tall standoffs, and linked via a small custom Y-cable going to the receiver. The bottom one powers the cooling fan through the 15V rail (which, incidentally, is going to be missing from RB version 3 to be replaced by a 5v fan output).

Each RB controls only 1 motor per side – the system is set up in mechanical parallel. Hypothetically, if one controller fails, the other can still move the vehicle at 50% power, but it of course depends on the mechanism of failure. If the failed controller becomes a short, then it would be very hard to power against the shorted motor, for instance. There was no intent of providing redundancy, just a convenient means of controlling more current than one Ragebridge can effectively put out.

With no custom software needed, it was drop the batteries in and go. LBS is basically a dumb ROV at this point, no different from one of the battlebots. The RageBridges were put into “mix” mode because the simple 2 channel Hobbyking radio does’t handle any of that fancy stuff.

After putting the other battery in, things started getting…. crowded. Batteries are retained on the bottom with a healthy dose of Velcro, and the virtue of being confined keeps them from jiggling around otherwise.

The wiring harness is admittedly a rat’s nest, but hey, salvaged wiring. It’s also be a good chance to test RB’s robustness under non-ideal wiring conditions.

Closing the top up… I designed this version to be way easier to service in case something goes wrong inside because the electrical box lid is removable through the top, after the board itself is removed.

And here’s the 98% complete shot. At this point, I didn’t yet receive my threaded rod to finish the two standoffs in the front and rear. Without those, the frame bowed a little when I stood on it. But it was functional enough for some superman-style hallway blasting.

There was one problem I discovered during this testing. The motors could exert so much tension on the chain that they were physically bending the rear bogie frame inwards, collapsing the hollow cutout and making the chain jump off the sprocket.

Well, that was dumb. The placement of the chain tensioner was pretty much in the middle of a totally unsupported span. I could, in fact, unbend it with some big channel-lock pliers. I definitely hit copy and paste a few too many times…

To address this issue, the rear bogie frame side was recut to be solid and the tensioner mount itself was made a little fatter and angled.

Here’s a picture of the bottom of the beast, showing the drive chain setup and the batteries. Still, missing standoffs (which have since been added).

I don’t have any testing video yet, since there hasn’t been exciting enough weather to do so. The new arrangement, however, has demonstrably increased torque and better steering response too. The Ragebridges are synchronous rectification drivers, meaning the motors exert a torque against any external changes in speed unless commanded to that speed, so the tracks have increased dragging ability on either side. It can alsofinally turn in place, even with rider weight on it. The top speed is right around 8 or 9 miles per hour.

Once the weather gets more interesting, expect some updates with videos!

The Second Great Awakening of the LandBearShark

Nov 11, 2012 in Land-Bear-Shark, Project Build Reports

Oh, this thing.

LBS is another great example of something I built without much forethought that never quite worked, similar to a certain basket-case go-kart. It has been plagued with reliability problems for its entire life, generally stemming from my inexplicable refusal to use real motor controllers (it’s always the motor controllers) and my insistence on keeping it brushless with R/C type motors. While its initial goals were… somewhat noble, they were pretty much antithesis to what it needed to do in real life, which was to have very high low end torque and fine speed control for scrubbing the tracks during steering, and to push through dirt and snow. To no surprise, the completely open-air electronics deck was not very enthusiastic about doing either of the latter, and the fact that it had always been geared for 20-25mph meant it really didn’t have enough torque to do anything save for drive in a straight line.

Scheduled Plug! I’m still trying to unload stuff. Have a look and see if anything interests you.

The first drivetrain version used rewound C8085-class “melon” motors, hence giving its internal moniker “melon-tank”. Unfortunately as I found out later, the motors were both wound incorrectly and Hall-sensor-appended incorrectly. Hence, this version pretty much never worked at all.  In fact, the most successful rendition of LBS had been its brief DC motor form that I put together afterwards, but even that didn’t resolve the turning issue because of the lack of braking/reversing that the “Beast-it-trollers” featured. So it still couldn’t turn, and one somewhat undergeared CIM motor per side ultimately meant they just overheated and baked. When last winter rolled around, I switched LBS back to a chain-reduced brushless form using (proper) sensored motors. This version has been around the longest and has been consistently working….with the exception that it keeps eating the Hobbyking Car ESCs for reasons unknown. Given that these were never meant to drive something with so much inertia and friction, and don’t have any form of current limiting or control, I am not at all surprised. The motors are also still geared too fast – a top speed of about 18 miles per hour, and I don’t think I have ever stayed on this thing past about 10. After the very mild winter snows melted, I took some parts out of it to let other people borrow for their own projects, and LBS has been living under a table.

Now, with LBS approaching its third Brutal Arctic Winter, it’s time I do something about all of that or close this chapter of my project book forever.

And because I was told that it will actually snow this winter, and with the allure of having a functional offroad/snow vehicle still too strong, it should be clear what path I’m taking!

I’m going to rebuild LBS the way it was meant to be the first time around – bone simple, no frills. It’s going to just be about as smart as one of the Battlebots. Full R/C throttle controls and no more weird sleep-mode contactor closing and opening. One of the causes of my reliability concerns stemmed from the fact that this thing just had too many subsystems being thrown together haphazardly at once.

Here’s the summary of what’s changing:

  • Going back to DC motor drive, using now proven Ragebridges as the drivers. Hopefully, this will be the first test of the version 2 boards.
  • Two CIM motors per side, like the intermediate DC version, geared way down to max out at about 8 miles per hour with much higher torque. My rough calculations show that in perfect traction it will have about 400 pounds of ‘drawbar’ pull. This means it might actually be able to turn in place (skid turn) now!
  • No more weight shift detection, rider switch contactors, tilt steering. Or anything.
  • Actually enclosed electronics and batteries, so going outside in the snow and dirt like it was meant to do doesn’t bury my controllers in grime.
  • Significantly less weight. There was so much wasted metal on LBS that did not need to be there and didn’t contribute to any structural load bearing.

The design has been in on-and-off development for a few weeks now, so most of it’s done already, but I was waiting to make sure I actually started on it before making a vaporware post. Here’s the rundown:

This is what the design looks like as a whole. Notice the much, much lighter aluminum sections and my more extensive use of trussing and triangles instead of big square plates. The aluminum weight on this frame has gone down by about 60% – because previous, every piece was solid aluminum plates!

The new track bogies are also much lighter in weight. Fact is, these things never took any structural loading, so they were entirely for show. There’s no suspension element or frame mounting that is rigidly coupled to the bogie swingarms. As a result, they were made much thinner and simpler. The side which couples to the ‘shocks’ are thicker in section because the loads are transmitted into the shocks and into the main body.

Admittedly, the suspension does absolutely nothing. The mountain bike suspension shock absorbers I got are rated at 700 pounds per inch – in other words, there’s basically no travel or movement at all with 4 of them on there, even if I jump up and down. Hence, I really just think of them as rigid control links in the bogies and not actual suspension elements. They are there to anchor the track axles, closing the structural triangle between themselves, the bogie swingarm, and the central frame.

 

The track pods were totally designed from scratch to be lighter and more elegant, and to minimize the use of 1/4″ aluminum. There’s no more ring of 7 3/8 bolts around the outside of each axle mount, because they were completely useless.

I spent much time trying to play “arrange the motors”, since I wanted to fit 2 motors per side. The track pods were originally designed for an ‘inboard’ drive, or motors mounted away from them driving via a shaft.  Stuffing them into the center cavity between the very short wheelbase tracks along with a method of connecting them to the main body was a bit of a pain, and part of the reason I’m glad this thing doesn’t actually have suspension travel is because if it did, the motors would be bottomed out against the tracks.

I went through several configurations and motor-vs-center-shaft arrangements before setting on this one which kept both motors on one side, hanging off the center shaft in an independent gearbox. The high center shaft meant I didn’t have to use so much metal to join the shaft to the frame since the whole thing can be kept low profile. And, the one-pivot-point mounting meant that keeping tension on the chain would be much easier. The little snail cam thing is designed to keep pressure on that swinging assembly once the chain is installed.

Check out the new drive motor setup – dual CIM motors geared to a common shaft, then chain speed-reduced to the track sprockets.

This thing will need a little explanation. The featureless gray circles are spur gears – for simplicity’s sake, I usually don’t bother modeling the teeth unless I was going to cut those gears out myself. The main spur gear is a hex bore, riding on a 1/2″ hex shaft with bushings inside so it spins on a structural standoff that helps hold the gear case together. A bunch of other hex bore objects are stacked onto the same hex shaft, and the assembly doesn’t have any axial constraining features (snap rings, set screws, shaft collars) save for the 2 end plates and thrust washers. The assembly is hence pretty easy to take apart and put together, and the hex bore transmits torque without the need for a keyway or something.

The spur gears are sourced from AndyMark. In fact, this whole damn thing is pretty much an AndyMark-powered FIRST robot. As much as I some times disagree with the philosophy of providing commercial solutions for a high school competition that allegedly encourages students to engineer and design their own robots, AndyMark really does make some neat little shortcut items. AM products are also usually built for the task at hand – which is to say, not things that you need to run for 10,000 hours with absolutely reliability. Robotics competitions are generally fast and brutal, not necessitating long part life, and I do agree with saving a ton of money making gearbox cases from aluminum sheet metal stampings, for instance, over die-case/billet machined stuff.

This means stuff costs less. Seriously, AM is about the cheapest place you can possibly get steel and aluminum spur gears if you don’t mind the limited tooth options. McMaster would have charged me about $30-40 per gear for the set I’m using, and they come with things like hubs that I don’t need. I’m pirating the popular AM method of using hex shafts for everything because it really is convenient. It’s like a real spline shaft, except improv.

In this gearbox, I’m using their 12 tooth pinion for the CIMple Box and a 48 tooth output gear.

The output is a 7 tooth hex-bore sprocket which I will custom-cut from profile.

The electronics box this time is no longer an open-top bucket. Made of 1/8″ and 1/4″ polycarb, it’s fully enclosed on all 6 sides, save for ports for switches and wiring. A fan will blow straight into the two Ragebridges in the back to keep them nice and chilled. The fan will have a foam filter stage in front of it so it doesn’t try to pull in water, and the RB boards will be conformal-coated too for splash protection. The fan will also help keep the electrical box positively pressurized -exhaust vents out the front, so if there is any place gunk could get in it would be through the slits if there was no airflow.

The Big Switch makes a return in the back side, so if this thing does try to get away from me, I wouldn’t have to full-frontal tackle it. At the breakneck speed of 8mph, too, it should be easy to catch.

The main chassis this time is pretty much just a cage with mounting holes that mount the track pods and hang onto the electronics deck, which can be slid into place and locked by the side mounting screws. Exceedingly simple compared to the first time around. I’ve ditched the big crash bar because there’s no more load cells involved, and that thing alone weighs like 10 pounds. The board itself has some little side rails on the bottom so it won’t sit truly flush as shown – I’ll make a little spacing plate if it’s needed.

Overall, the thing loses about 15 pounds compared to what it has been. While I never weighed it with the crashbar assembly on, the bare vehicle weight before was 65 pounds, so it must have been up to 75. What I lost in metal weight and complexities, I gained back some in those damn CIM motors and gearboxes. Steel and DC is heavy!

I do like the new look better, though. The space frame makes it look even more monster truck-y. Here’s to hoping it can actually live up to the hype this time.

And here’s the pile of parts!

Every post about Landbearshark ends with the motor controllers exploding

Jan 22, 2012 in 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!

Most Elaborate Bathroom Scale Ever

Jan 16, 2012 in Land-Bear-Shark, Project Build Reports

In another episode of “Charles digs out old and semi-abandoned projects to work on them because he currently can’t afford to work on new ones“, I spent a day fitting the Landbearshark with front and rear load cells in the interest of converting it to fully hands-free operation. I’ve gotten it to the point where I have created a noisy and metrologically unsound bathroom scale, finding out just how fat I am.

A few months ago, I redesigned the pivot mount for the skateboard to include provisions for mounting a cantilever load cell on either end. I actually received the load cells a few days after finishing the new hinge and trying the hands-free steering, but just stuffed them away for the time being to focus on other things, such as Tinytroller and…. what the hell else did I do this fall? I also didn’t want to take LBS apart again and have it in a non-working state as the winter approached, since I figured any snow day romping was better than none, hands-free or otherwise.

The problem is, it seems that by virtue of being fully functional, LBS has delayed or neutralized the winter snowfall. For the past few weeks, it’s been either

  • Mid 40s and 50s, like spring or late fall, and raining really heavily, or
  • Single digits temperatures, clear and windy. Really, really windy.

If it’s going to be this cold and depressing, I’m going to move back South, where they have nicer 3d printers.

Either way, I’m making it official that LBS is not in a working state right now due to the load cell experimentations. There. It should start snowing tomorrow, right?

The load cells are 500lb capacity bricks of steel that I selected through extensive eBay research (read: “Price + Shipping: Lowest First”)  made by Keli Electric. I decided to royally overspec them because the flexure sections of these beams were to be the only mechanical link between the board and the rest of the frame, with no hard stop to take up overloads past the maximum load deformation. In a better constrained application, they’d be really overkill for sure.

They came with little certification sheets that seem to be standard to all load cells, including specifications such as sensitivity in millivolts of output per volt of excitation (at full scale measurement), input and output impedances, linearity tolerances, etc.

They also have quality control stamps on them, presumably meaning “Yeah, it’s shaped correctly and has the right number of wires coming out of it”. There’s still something about Chinese QC stickers that makes my inner Chinese migrant worker tingle a little.

Because my pretend-o-cells were made to the same dimensions as the real thing (or vice versa), they dropped in place quickly. The only difference is that they were 1″ thick instead of 1.25″, which warranted shaving 1/4″ off the bolt lengths on the lathe.

I whipped up a quick dual amplifier circuit using some AD627 instrumentation op amps from Anabork Devices. These things are expensive. Not the most expensive op-amp I’ve had the joy of playing with, but I had to buy them myself this time. I chose to do that instead of trying to put together multiple discrete op amps into a differential-input, instrumentation amplifier config because of the limited space on this breadboard and the fact that prepackaged amps allowed me to change the gain with only a single resistor. Breadboard on a vehicle. Bad idea? Yes. Convenient? Hell yes.

With 5 volts of excitation and 3 (+/- a bit) millivolts per volt, I was looking at only 15mV at 500 pounds full scale. I wanted to bring that to a full 5 volts of swing for mathematical convenience, necessitating a gain of 333 or so. Using the only 1% precision resistors I could locate at the time, which was 2 301 ohm resistors in series, I can get a gain of about 337. That’s like 333, right?

All the math in the world doesn’t prevent physical systems from behaving nonideally or me from being lazy and taking shortcuts. Therefore, I wanted each load cell calibrated with a known mass. I selected this 11.6 kilogram truck disc brake found in a corner of MITERS (placing pretty high in the “Weird shit found in MITERS” contest, actually) as the calibration mass. To find the actual mass of the thing, I used a cheap hanging digital scale.

Calibrating one shady Chinese scale with another shady Chinese scale. This is the pinnacle of Instrumentation and Measurement achievement.

The actual gains found were slightly higher at 334 and 352, +/- a MIT Mechanical Engineering degree or two. Each load cell also had a “zero reading” that was subtracted beforehand.

After calibration, I determined my internal ADC-LSB-to-kilograms-mass conversion was about 4.5. This is not going to be a very precise scale, but I’m not trying to measure weight down to the millinewton anyway. The shifting of weight is what will be controlling the vehicle in the end.

When I started writing the load cell reading-averaging code, I decided to include a “zero” function which pauses the entire vehicle operation, takes several measurements (namely 32, spaced 10 milliseconds apart) of the load cells, averages them, then saves the result to EEPROM to use as a new zero on the next power cycle. This was done because I did not, and could not assume, the final weight of the skateboard in order to hard code in a zero. The idea is that this would only be done once or twice after everything’s mounted, and not on every power cycle.

I had to figure out how to split a 16 bit integer (the output of the ADC from reading the load cell) into two bytes in order to stuff it into the atmega328′s EEPROM sector. I crosschecked my result with the Internets, and… hey, I diditrite.

Reading:

  //eeprom 10: low byte, front zero
  //eeprom 11: high byte, front zero
  //etc
  front_lc_zero = EEPROM.read(10);
  front_lc_zero += 255 * EEPROM.read(11);
  rear_lc_zero = EEPROM.read(12);
  rear_lc_zero += 255 * EEPROM.read(13);

(The 255 multiplication is equivalent to left shifting by 8 bits anyway – I was lazy).

front_lc_zero et. al. are unsigned integers. Essentially the “high byte” of a 16 bit long number is the low byte but multiplied by 255, or left-shifted by 8 bits. Hence, first populate the variable with the directly-read low byte, then add the future high byte, but shift it leftward past the existing 8 low bits.

And writing:

    fznew_lowbyte = ( front_zero_new & 0xff);
    fznew_highbyte = ( (front_zero_new >> 8) & 0xff);
    EEPROM.write(10,fznew_lowbyte);
    EEPROM.write(11,fznew_highbyte);

    rznew_lowbyte = ( rear_zero_new & 0xff);
    rznew_highbyte = ( (rear_zero_new >> 8) & 0xFF);
    EEPROM.write(12,rznew_lowbyte);
    EEPROM.write(13,rznew_highbyte);

where fznew and rznew were the zeroing averages, 16 bit numbers.

This took me much longer to figure out. The first operation (front_zero_new & 0xff) performs a bitwise AND between front_zero_new and the hex number 0xff, which when expanded to 16 bits is the binary sequence 0000000011111111 (or 0x00ff). It has the effect of cutting off the high byte of front_zero_new, leaving just one byte (the lower 8 bits). This byte is written to memory.

The second operation saves the high byte by just shifting right 8 bits (or dividing by 255, integer). The existing lower 8 bits are right shifted out of existence. The upper byte becomes the new lower byte, and this temporary representation is saved to memory. I didn’t have the second “& 0xff” at first, and it seemed to work just fine, but apparently it is good practice to apply the ‘bit mask’ anyway just to make sure nothing remains in the former high byte.

I used Arduino’s built-in EEPROM library to do this, so it probably did many horrible things to my carefully crafted inputs, but the results are legit. The happy zero point of my load cells, with the skateboard installed, seems to be about 623/1023 (Front) and 628/1023 (rear), in ADC least significant bits.

ui design

At this point, with the ability to read and save two load cell readings and roughly determine where my weight is concentrated, the problem has progressed to user interface design. I anticipate first trying a naive, absolute weight shift (difference between front and rear readings) kind of throttle control, but ultimately I want to create on that is adaptative to user weight and normalizes the throttle response with respect to it.

So, ideally it would be ratiometric. For instance, having 75% of your weight on the front half of the board (75/25) would be full forward throttle, and vice versa – example numbers only. I’d have to be able to keep track of total weight and filter out any gravitational effects – even bending my knees while standing on the load sensors affected the reading significantly. The total weight reading would probably be heavily filtered with a time constant of several seconds (if not longer, like a minute) such that it adapts over time but is immune to rattling and brief gravitational transients. An accelerometer might be useful in cancelling the effect.

Otherwise, the usual problem of making the command a speed/throttle % setting or a ramp (throttle % increment per second) will also need resolving. I seem to prefer the former, but quite a few people who ride LBS seem to like it slowly ramping up and down. Under the latter system, to keep increasing speed, you’d keep leaning forward, and vice versa.

Oh – speaking of rattling, the track rumble along the ground epicly destroys the clean static readings. I’m going to have to come up with some clever software hack around that – possibly as simple as a long time constant filter (1 second or so) for each load cell, but it may progress to more elaborate solutions like adaptive bandstop filters that center directly on the track rumble frequency as a function of motor speed and…

I just opened a refrigerated trailer full of boxes of cans of software worms, didn’t I? Let’s do something mechanical:

I decided that LBS would look much better with a huge crash bar on the front.

It’s not entirely decorative, however: these assemblies protect the load cells from taking direct impacts if I run into something, fall off, or wheelie/stoppie. There is a complementary but smaller assembly that goes on the back, which I have yet to gorilla weld up.

But doesn’t that look badass?

 

Land-bear-shark: Now With More Tilty-sense Board (than it should have)

Nov 01, 2011 in Land-Bear-Shark, Project Build Reports

It hasn’t blown up yet!

(cue controller fire in 3…2…1…)

I spent most of today finishing the driving code that I half-started on Sunday night. Because the new board mounts do not have the microswitch to detect the rider, I was left with only the radio failsafe as a way to kill power. Before, an invalid radio command (or the total absence thereof) did not open the contactor, but that was changed to buffer that line of defense against runaway miniature tracked vehicles. Next, in a fit of i-hate-software-induced rage, I coded an asymmetric ramping function which took a master throttle command from 2000us to 1000us, with 1500us as ‘neutral’, and ramped it at adjustable rates to adjustable endpoints. The ramping was set up such that increasing throttle and increasing braking (both on the trigger channel of the transmitter) was ramped, but decreasing throttle or braking force was passed straight through.

LBS is practically impossible to ride without some kind of ramping or other controls damping, so I decided having this more complicated but tunable code would come in handy during ride testing. As an added bonus, the code is very modular – I could splice in the master radio command with the average displacement of the rider’s center of gravity after the load sensors are installed.

So this is what the whole thing looks like after finalizing the wiring with zip ties.

And with the board remounted. It doesn’t really look that different from the previous version, but it has more stickers!

Ride testing revealed that even upgrading to the 70A rubber bushings was not enough: the board is still too soft. They seemed to “loosen up” with repeated bending, too. Even worse, it’s very underdamped: Because there is no friction element in the joint (only the bouncy rubber bushing), it’s easy to trap yourself into an oscillation of full left and right tilt, resulting in a very quick destabilization as the tracks pulled left or right. This behavior was termed “latching” after the unstable behavior exhibited by malfunctioning amplifiers. Part of the fix is adding some rubber washers or other friction-adding element to the joint, but I do need stiffer bushings. Space is the most constraining issue here, since the mount was designed around the 2″ long, 2″ diameter rubber bushing mounts. I’ve thought about casting my own ~80A polyurethane ones, or making an extension of the joint which actuates gas springs.

I also discovered that ramping the braking force contributed to alot of “laggy” control feel – after turning up the gain repeatedly, the best results were obtained once I just pegged the ramp to full – that is, following the braking command both in and out as quickly as possible.

Otherwise, the optimized behavior of the HK cartrollers to R/C car racing (and not, say, rideable vehicle propulsion) showed through – starting in a sharp turn wouldn’t result in one side’s track braking, since by default the controller is designed to coast after it has detected zero motor speed. Only a small amount of forward throttle coupled with the turn would actually result in stopping one side. This is not something which is addressable in the controller’s calibration settings. Turning on smooth surfaces is still a little unstable, since these controllers are not actually “speed controllers” so much as just open loop voltage drivers. True speed control (even synchronous rectification) would guarantee a yaw rate because the tracks will be forced to travel a certain speed, and the faster cannot drag the slower to a higher speed. This is something which will be addressed in the near future.

At least they haven’t exploded yet – after all the testing, the cartrollers were reasonably warm, and the SK motors burning hot. It was all on flat ground, however – going up the wheelchair ramps here would probably make the cartrollers unhappy. The first burnout was most likely due to very high current spikes because the sensors were totally off. I would trust the 150A version of the cartrollers much more in this application.

What’s more important is that I get this thing on a more slippery surface and run it around before determining that all of these are shortcomings. After all, real ATVs and tanks aren’t tested in parking lots; they’re tested in rough terrain. The brushed drive worked just fine in the grass at Maker Faire, but was almost impossible to handle on-road.

Enough rambling. I know what the Intertubes wants to see: