• Mk I

    A.M. Smith12/03/2019 at 01:48 2 comments

    Overview

    Mark I was cobbled together in the sum of a weekend. Having improper materials at hand, and having forgone any calculation whatsoever, I had healthy reason to doubt this initial incarnation. Shortcomings known, it left my mind free to build something with no expectation whatsoever.

    The prototype employs some PLA mounts, a wooden dowel, some spare rotary pillow bearings, an Arduino Nano, an MPU9250, and a L298N motor driver. Excepting the PLA mounts, all components were rescued from a box of deceased projects.


    Motors

    Through the course of experimentation, I went through three different motors.

    The first was geared, high RPM, low torque. During a brake or direction change, the inner metal teeth of the motor were shredded smooth over time as they resisted the inertia of the heavy spinning wheel. I needed a motor that could rapidly stop and change direction without damage. I decided to leave behind geared motors and try brushless DC.

    The second motor was a BLDC with a built-in IC, hall sensor, and braking mechanism. Unfortunately, I too brusquely reviewed the specifications and missed an all-too-important line: "CW only, do not attempt to reverse polarity!"

    The third motor was BLDC, high torque, low RPM. Torque is exerted by the motor transitioning from a standstill to full RPM (accelerating) while overcoming the inertia of the pendulum itself. The effectiveness of this torque is felt most strongly when the pendulum is nearly balanced. However, at angles of 15 degrees or more, the weight of the combined motor and wheel masses at the end of the pendulum lever arm becomes too much to overcome.

    It also seems that, to hop up, I would see more success reaching a high RPM and slamming the brakes (high angular deceleration yielding high torque), the way the balancing reaction wheel cubes work.


    PID Control

    Additionally, the PID control software running on the Arduino appeared sluggish. Potentially the Arduino is not a high enough clockrate controller for this application.

    Some more hardware-level calculations for this might be in order.


    Plans for Mk II

    • Do math.
    • Mount the pendulum out away from the table so that it can perform 360 degree swings, and swing-up maneuvers, without hitting the desk from which it is mounted (swinging parallel to the desk edge).
    • PID software currently does a running average to remove noise. Possible to program the noise floor on the MPU9250: MPU-9250 Datasheet
    • Wheel will be larger in radius but lower in mass. 
      • Note equation of inertia for a disk:  
      • Increases to the wheel radius will increase a spinning wheel's inertia (and torque) exponentially.
      • The masses of the wheel, motor, and pendulum collectively have inertia, which we are attempting to overcome by spinning the wheel. A lower wheel mass will decrease the inertia of the inert motor/wheel assembly on the end of the pendulum, making it easier to overcome with high spinning torque of the wheel. 
      • Steel wheel cut with OSHCUT services.
    • The P, I, and D constants will be communicated remotely to the on-board controller (and stored periodically in EEPROM) using NRF24L01 breakouts (one of which is already on Mk I in the video).
    • Possible switch to a multi-threaded, higher clockrate device to process wireless communications and PID control simultaneously.