Vipin MI believe that the thought of building a self-balancing robot crosses every maker's mind at some point. And who can blame them. Its fun to watch and appears simple enough to at least attempt once. I was also bitten by the bug but wanted to give the self balancing robot a fresh look. So, decided to build its chassis to resemble the Thor's hammer, Mjölnir.
Now, to be honest, I am probably the least qualified person to talk about Thor or his hammer. I haven't even watched the movie yet :) But I had heard of it and imagined it to be a good candidate since it is top-heavy with high moment of inertia. So, decided to give it a shot.
I got the STEP file from grabcad and altered it in Fusion 360 to suit my requirements. The body consists of a hammer head at the top. It is connected to the grip through a handle. The grip and the head were split in two halves, top and bottom. The head was hollowed out from inside to make space for the electronics. The hammer uses the inverted pendulum concept to balance itself on the two wheels. The wheels are powered by a DC motor situated inside the top half of the hammer grip. The bottom half of the grip is just for aesthetics and gives a nice finishing touch to the grip.
Below is the list of parts to be 3D printed and the required electronic components:
- the hammer head to house all the electronics. Other than the DC motor, all the electronics are housed in the hammer head. The bottom portion of the hammer head acts as a lid to close the hammer head and also connects it to the handle.
- an accelerometer to measure the deviation angle used as an input for the control algorithm. MPU6050 is a good choice with its low cost and reasonable accuracy. Digital Motion Processor (DMP) was used since it minimizes the errors inherent in its gyroscope and accelerometer sensors.
- a bluetooth (HC-05) module slave to control its motion remotely. It can also be used to get the stats for PID tuning.
- A microcontroller to process the information from the sensor, perform computations and generate output for the motor. Arduino nano was used due to its small footprint.
- an L298N motor driver which provides speed control through Pulse Width Modulation (PWM) and direction control through its H-bridge configuration.
- a battery holder with 6 AA batteries to provide juice to this whole contraption.
- a switch to give this thing a break.
- The DC motor is nicely concealed in the grip with the power to it carried through the handle.
All parts were printed in PLA with 0.28 mm layer height and a 0.4 mm nozzle on an Ender 3. The STL files can be found on Thingiverse and the source code can be found on github.
Design notes
- Adding more mass to the hammer head results in higher moment of inertia. With the given gravitational torque, it means less angular acceleration which means it will take longer for the hammer to fall over and therefore gives a better chance for the control algorithm to calculate and apply corrections timely.
- Designed a shaft coupler to extend the DC motor shaft length and a sleeve for the axle to reduce wobble from the DC motor.
- The control algorithm used is a simple PID loop with the 'setpoint' as the angle deviation from vertical. It tries to minimize this error by adjusting the 'output' mapped to the motor speed. The tuning was done by adjusting the value of Kp first followed by Kd and Ki.Forward or backward motion can be achieved by changing the setpoint for the hammer to gradually incline and then get back to upright position. I was unable to test the last part due to limited motor torque.
- Used a soft serial port for interfacing the Bluetooth module. Arduino nano has just 1 hardware serial port and I wanted to avoid multiplexing it between firmware upload and BT.
- The MPU6050 breakout board I used was marked as GY-521. It has an onboard 3.3V voltage regulator (4A2D). So, it should be fine to hook it up directly to a 5V supply.
Limitations
- Since there is only one motor, the hammer can only go back and forth i.e. no turns.
- The el-cheapo DC motor I used has limited torque. The hammer is heavy and such creates a lot more friction. The DC motor struggles to keep up when a more drastic correction is required.
- The balance is fragile and even a minor external force will cause it to dash in that direction. May be I will experiment with an optical encoder to get some sense of speed and apply a PID to manage speed.