How to Build a Mini Electric Go-Kart in a Day

During the middle of some Friday night MITERSing, Mike, one of this year's crop of MITERS-frosh (also one of the people responsible for the recent revival of LOLriokart), decided to build a tiny electric kart or other small silly vehicle.  That night.  I joined in on the project, and within 10 hours we had a rideable go kart.  

At around 12:00 am Saturday we had a pile of kart-parts.  There's a pair of large scooter wheels, some 1.25" square aluminum tubing, some 1" x 4" rectangular aluminum extrusion, a Kelly KBS24121 controller, an EMP 63-200 motor (essentially identical in construction but a bit smaller than the trike motor), a big Colson Performa wheel, and a very old Brooks saddle.

All the parts were scavenged from around MITERS.  The motor, controller and saddle were mine, one scooter wheel came from an abandoned kick scooter, one came from Jaguar, the Colson came from the carcass of Straight Razer, and all the metal stock was scrap.

For batteries, we finished off a box of A123 18650 cells.  Five of them fit side by side in the inside of the rectangular aluminum extrusion.  We had enough cells for a 6S5P pack, which also happens to be the the most cells that could physically fit in the length of the extrusion.

Unfortunately, the incredibly short timespan over which this was built means my documentation is pretty poor, so there are not many intermediate construction pictures.

The back wheel and motor were both bolted to some U-channel, which was in turn bolted to the rectangular extrusion.  Don't worry, the wingnuts were eventually replaced with locking nuts.

I did most of the machining of the steering assembly.  I made the steering as simple as possible for quick construction, so doesn't have Ackerman steering or anything fancy like that.  The steering is actually completely non-adjustable, since the tie rod is a solid square aluminum bar with holes drilled through it at the pivots.  The steering column is supported by a big chunk of round Delrin which is pressed into the aluminum frame, and the column itself is 1/2" polished steel shaft.  I first tried cutting it with a hacksaw, but after trashing one blade I realized it was hardened, so I milled through it with a little carbide endmill I picked up for a dollar at Swapfest.

To test the handling, we pushed it around with some clamps attached as temporary handlebars:

The steering knuckles were machined from some 1" square aluminum.  At one end, they have a 1/2" hole through them, through which pass the bolts the wheels pivot around.  A little thrust bearing is sandwiched between the knuckle and it's supporting plate.  These bearings were found in a drawer of random bearings, and were labeled "Precision components, handle with care!".  So much for that...

For a seat, we used an old Brooks saddle.  It was clamped to a segment of 3" square tubing, which was fastened to the frame through the same holes as the motor and wheel bracket.  

Mike quickly threw together an electronics system with some parts from his electric longboard, so we could ride it.  These were a Hobbyking 120A car controller, a 4S hardcase LiPo (same as the ones in my scooter), and a really sketchy RC car remote with a broken trigger:  All duct taped to the frame.  As of around 9 am on Saturday morning, the kart looked like this:

We searched long and hard for something silly to use as a steering wheel, but eventually just bolted on a length of 80-20 extrusion, as a nod to all the 80-20 go karts out there.

At this point, the kart was driveable:



The electrical system was far from ideal, so it was replaced Saturday night and Sunday morning.  I worked on assembling the new battery pack, while Mike got the Kelly controller ready and set up one of Charles's hall sensor boards.

I started off by gluing together sets of 5 cells in parallel.  These were soldered together with a strip of copper braid across each end.

These six modules were then connected in series with more braid.

Balance connectors, power leads, and insulation and padding at the terminals was added.  The big red power lead shown was actually replaced with some insulated copper braid, because the round wire took up just barely too much space for the pack to fit into the aluminum tube.

Here is the battery pack next to the frame.  More insulation was added before sliding it down the tube.  Actually shoving the battery in was a hair-raising procedure.  To install the battery, I had to lightly lubricate the outside of the pack's insulation to prevent it from getting stuck part way down.  On the first attempt, the little bulge where I spliced together balance wires got caught on the inside edge of a bolt hole, which removed a tiny speck of insulation from the balance lead of the second to last cell.  There were a couple little sparks, and the frame was floating at 17V relative to the negative end of the battery.  We disassembled the front end of the kart, and pushed the battery back out a few inches.  The trouble spot was reinsulated, and then protected from any sharp edges with some thin plastic sheeting.

Once the kart was reassembled, we rigged up the Kelly and began playing with hall sensors and motor phases to get the motor commutating properly.  First time around two of the hall sensors we used turned out to be dead, so I had to replace them.  After that, everything worked great, and it only took a few minutes to get the motor spinning the right direction.  Adjusting the sensor timing took a bit longer, since I had to extend the slots in the sensor board to get it positioned at the optimal spot.

The final kart:  I haven't weighed it, but it probably tips the scales at 20-25 pounds.  Top speed is only 15 mph, so it will be a good indoor and demo vehicle.

Now it's time to recover a weekend's worth of sleep.

Robot Arm, Now With The Drawing Ability Of A 5-Year-Old

Last update I was bad at serial and the robot arm almost exploded itself.  I quickly made my serial communication less stupid, and added some features like a checksum, which stopped the robot from behaving so spastically.  However, no matter what I did I was unable to get smooth motion while streaming serial commands.  The robot would follow the path smoothly for a few seconds at a time, but would be interrupted by jerky motions I could not diagnose.  One strategy for fixing this might be buffering the serial commands rather than executing them as they arrive.  For now though, my Python script simply generates a text file with all the commands, rather than streaming them over serial.  I can then copy the text file to the mbed for it to execute.  While more time consuming to change paths, this method has been much more (read: completely) reliable.

So here's the robot drawing some things:

Fast squares:



Writing "MITERS":



Here are some mediocre squares.  I've gotten it to draw better ones (without weird corners) since this since, but it's actually roughly the size it's supposed to be:

This is what happens when I try to draw 10 cm squares at a few Hz..... the "circles" were also drawn at the same frequency.  There are a couple reasons why it looks to terrible.  First the robot was shaking the table it was on.  Second, the paper was held below the pen by my hands.  These two problems were responsible for probably at least 2/3 of the waviness.  The remainder was caused (I think) by flexing in the linkage between the second link of the arm and its motor.  It might not be reasonable to expect the arm to be able to draw three perfect squares per second, but I can definitely get them a lot better than this.

Here's what the "MITERS" text looks like.  Once again, I was just holding the paper below the arm with my hands.

I've started simplifying my method of path generation.  Right now, I feed my python script some setpoints.  It interpolates between these points at whatever step size I choose, converts these X-Y positions to arm joint angles through the robot's inverse kinematics function, and then turns those angles into encoder counts which are loaded onto the robot.  Eventually I want to write a G-code interpreter to make path generation easy.

On to some hardware.  I made a quick pen holder out of a botched elbow joint I machined a while ago:

I also made a quick demo-frame out of 80-20 for Techfair.

Action shot:

I am working on replacing the carbon fiber linkage assembly with something that can't twist where it connects to the pins at the pulley and arm:

Back to some robot control stuff.  In the above videos, you may notice the tones the robot generates while moving.  This tone corresponds to the frequency at which I have the robot arm read points.  Right now, the arm only has position control, so when it gets a new goal point, it attempts to travel to and stop on that point as fast as possible.  So my servos are kind of trying to be stepper motors.  To smooth out motion, I plan on implementing some velocity control on top of the position control.

At the high level, velocity control is pretty simple to explain.  When reading through the list of points to move to, the robot will look ahead a step.  By looking at the position change required between the current step and the next step, it can figure out how fast it needs to be moving when it arrives at its current step.  For example, if one of the motors has a current goal position of 100 (arbitrary units), a next goal position of 101, and the time between steps is one second, when the motor reaches position 100 it should be moving at a speed of around 1 per second.  If the current goal is 100, and the next goal is also 100, the motor should be completely stopped when it reaches position 100.  The actual velocity control will be done by a PI velocity loop running within the position control loop.

So that sounds great, but it makes a big assumption:  that you actually have a good idea how fast your motors are moving.  For my position control loop, I determine the motor velocity for the D term of the PID loop by taking the difference between consecutive position readings.  The issue with this is that encoders are digital.  When you try to sample the velocity really fast by subtracting position readings over very short time intervals, you lose resolution in your velocity measurement.  So this method is no good for running a very fast velocity control loop.  Also, I have been feeding my robot new points faster than I am able to sample for velocity, meaning that a velocity loop would be too slow to do anything.

Skimming through a bunch of papers on servo control loops, I found that my problem was not at all unique to my system.  Turns out the solution is to estimate the velocity at a high rate, and then update your estimate at a lower rate with encoder feedback.  Estimating the motor velocity will work pretty similarly to my python script to simulate the arm back at the beginning of this project.  A guess at the change in velocity over a cycle will be made by calculating the predicted acceleration of the arm given the arm's inertia, the motor's torque-speed curve, the previous command to the motors, and the loop time.  As actual measurements from the encoders are collected, the estimated velocity will be updated.  This will involve figuring out more precise values for inertia and frictional torque in the system than I've used before.  Also, the inertia of the arm's first link will be some function of the angle of the second link, which will make things a little trickier.

So there's a lot more work to be done.  At some point I need to add a third axis too....