Skip to content
Self-balancing robot using hoverboard hub motors
Branch: master
Clone or download
Latest commit fc69710 Jun 18, 2019

README.md

HoverBot

Rugged radio-controlled self-balancing robot using hoverboard hub motors.

HoverBot_Slide

Table of contents

  1. Key Components
  2. External Dependencies
  3. Videos
  4. Control Scheme
  5. Schematic
  6. Wiring
    1. ODrive
    2. IMU
    3. RC Receiver
    4. Arduino
  7. Press
  8. Additional Documentation

Key Components

External Dependencies

Videos

YouTube Video YouTube Video

Control Scheme

The ODrive is operated in current control mode. The current is computed by the Arduino from the pitch and pitching velocity to control balancing, from the throttle command to control the forward and backward velocity, and from the steering command and the yaw velocity to control the steering. The controller is tuned with five parameters listed in the config.h file.

HoverBot_control

A problem of this control scheme is that the onboard controller does not get velocity feedback. If the vehicle goes too fast, the balance controller cannot compensate a forward fall anymore, and it will fall over eventually. The human at the sticks therefore needs to make sure that the velocity is kept sufficiently slow.

Schematic

The following diagram roughly explains the data flow and types of electrical connections. HoverBot_wiring

Wiring

Note that the wiring is Highly Experimental and just a Proof-of-Concept. A more rugged implementation is currently under way.

wiring_overview Wiring

The wiring connects the wheel motors and their hall sensors with the ODrive, the ODrive to the Arduino and the Arduino to the IMU (sitting on a breadboard) and to the RC receiver.

ODrive

ODrive_wiring

The wiring of the ODrive is explained on the ODrive website (that has very nice docs overall!): https://docs.odriverobotics.com/#wiring-up-the-odrive

Power and motors

The ODrive is powered from the battery via its DC clamps (thick black and red cables on the left), and each motor's three phases (A, B, C, blue, yellow and green) are connected to one of its motor output clamps (M0 and M1). The order in which the motor wires are connected does not matter, the ODrive figures this out by itself during calibration.

Auxiliary resistor

Since the HoverBot is running on batteries, no auxiliary breaking resistor is required (the ODrive dumps recuperated energy into the battery).

Hall sensors

Each hoverboard motor comes with hall sensors that tell the ODrive when to power which of the three phases. Each hall sensor has five wires: Two for power (5V, usually red and GND, usually black) and three for signal (often blue, yellow and green). A motor's hall sensors are connected using extension cables to the corresponding sensor inputs (M0 and M1) on the ODrive's J4 connector. The three signal lines are connected to inputs A, B and Z where the order again does not matter. Note that it might be necessary (depending on the version of the ODrive) to add some a 22nF capacitor between each of the three signals and ground for signal integrity (insulated with hot glue), as is mentioned here: https://discourse.odriverobotics.com/t/encoder-error-error-illegal-hall-state/1047/6

5V power

The ODrive powers the 5V power supply of all other components, so its GND (black cable on the J3 connector) and 5V (red cable on the J2 connector) are connected to a breadboard that acts as power distribution.

UART

The ODrive communicates with the Arduino via the serial port, or UART. The UART pins are GPIO 1 (yellow) and GPIO 2 (white), as explained here (GPIO 1 connects to the Arduino's RX, GPIO 2 to the Arduino's TX): https://docs.odriverobotics.com/interfaces#ports

IMU

IMU_wiring The IMU only requires two wires for 5V power (red) and GND (black) from the breadboard and two wires for the I2C connection to the Arduino, connecting the IMU's and the Arduino's SDA (white) and SCL (left green). https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/pinouts

RC Receiver

receiver_wiring

The receiver is powered by 5V (blue) and GND (green) from the breadboard and each of the PWM signal outputs (three for the HoverBot) are connected to one of the Arduino's inputs that are capable of hardware interrupts. The fact that three hardware interrupt pins are needed is the reason why HoverBot uses an Arduino Mega rather than a smaller and cheaper Uno or Nano (see https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/). The pins used are 2 (orange), 3 (yellow) and 18 (green), and their channel assignment is set in the first lines of the config.h file: https://github.com/LuSeKa/HoverBot/blob/master/config.h

Arduino

The Arduino is powered from 5V (red) and GND (black) from the breadbaord. Apart from the connections already mentioned, the Arduino's USB port should be accessible for programming.

Press

Additional Docs

You can’t perform that action at this time.