Yahboom Balancebot Build Log

Blog
1

main
main1161×1486 213 KB

In this build log, I am documenting a reference build of a ArduRover balancebot (Balance Bots — Rover documentation), using a Yahboom chassis kit. It’s intended as a improvement on the ArduRoller (ArduRoller Balance Bot — Rover documentation) reference build, which required a 3D printed chassis.

Required parts:

Hardware build

I did originally buy a ready-made 3S battery (ZOHD Lionpack 18650 3S1P 3500mAh 11.1V Li-ion Battery [DG] – Phaser FPV), but it didn’t fit well in the chassis. I instead bought a 3x 18650 battery holder and soldered the appropriate connectors. The holder fits well in the bottom box:

battery
battery2016×1512 486 KB

The flight controller was placed in the middle section. A Cube + Standard Carrier Board just fits between the vertical spacers.

The GPS and radio modules required some careful placement, as it was little cramped on the top layer. I also needed to drill a few extra holes in the top plate to allow access to the cables between them and the flight controller.

The Roboclaw motor controller (and standard power module) were mounted at the side.

build_complete_all
build_complete_all1920×1204 368 KB

For the electrical connections, I followed the diagram at ArduRoller Balance Bot — Rover documentation, except the power for the encoders came from the flight controller’s servo rail instead of the motor controller.

Motor Controller settings

The Roboclaw needed a few settings changed via the BasicMicro Motion Studio software (https://downloads.basicmicro.com/software/IonStudio/setup.exe). Note there is a (mandatory) Roboclaw firmware upgrade on initially connecting the controller. Annoyingly, this firmware upgrade requires a Windows PC/Laptop and will not work inside a VM.

Once the firmware upgrade is complete, the Motion Studio software can be used within a Windows VM for changing or viewing Roboclaw settings.

The settings to be changed are the RC limits, autocalibration, deadzone and default accel/decel:

Roboclaw settings
Roboclaw settings1149×781 80 KB

Note RC Timeout and Safe Start need to be disabled, as I found the Roboclaw would occasionally not come out of failsafe after arming the vehicle.

ArduPilot parameters

The following parameters the support the above hardware are mostly for configuring the motor controller and wheel encoders:

Enable balancebot support:

FRAME_CLASS      3
FRAME_TYPE       0

Motor settings, assuming left motor on Servo1 and left motor on Servo2

MOT_SLEWRATE     0
SERVO1_FUNCTION  74
SERVO1_MAX       1920
SERVO1_MIN       1120
SERVO1_REVERSED  0
SERVO1_TRIM      1520
SERVO3_FUNCTION  73
SERVO3_MAX       1920
SERVO3_MIN       1120
SERVO3_REVERSED  0
SERVO3_TRIM      1520

Wheel encoder parameters, assuming left wheel encoder (WENC_) on AUX Out 5/6 and right wheel encoder (WENC2_) on AUX Out 3/4. The EKF is also configured to use the wheel encoders as a velocity source:

WENC2_CPR        1320
WENC2_PINA       53
WENC2_PINB       52
WENC2_POS_X      0.000000
WENC2_POS_Y      0.080000
WENC2_POS_Z      0.000000
WENC2_RADIUS     0.034000
WENC2_TYPE       1
WENC_CPR         1320
WENC_PINA        54
WENC_PINB        55
WENC_POS_X       0.000000
WENC_POS_Y       -0.080000
WENC_POS_Z       0.000000
WENC_RADIUS      0.034000
WENC_TYPE        1
SERVO11_FUNCTION -1
SERVO12_FUNCTION -1
SERVO13_FUNCTION -1
SERVO14_FUNCTION -1
EK3_SRC1_VELXY   7

Balancebot manual tuning (pitch to throttle controller)

For manual mode, a stable pitch-to-throttle (ATC_BAL_) tune is required. This translates a desired pitch to a throttle output. It is best to think of the it as the input throttle as an input pitch, so the vehicle is trying to achieve a specific pitch angle, in order to move forward/back.

I found the tuning to be quite tricky, but the following tips helped immensely:

  • MOT_THST_EXPO needs to be around -0.5, to give a stable pitch angle at both small and large pitch angles
  • MOT_THR_MIN was higher than expected. Despite the ~8% I observed during testing, I had to increase it up to 12% to reduce wobbling
  • The ATC_BAL_ PID’s needed to be far higher than the suggested range. I suspect this is due to the vehicle being quite small and very maneuverable. The PID tuning was also bit finicky, in trying to find the right values that allowed snappy movement, whilst ensuring the vehicle didn’t overcorrect and topple or have oscillations.

In doing the tuning, I found I needed to increase P and I in turn. So I increased P to reduce wobbling, until I got oscillations. I then increased I until the oscillations stopped. Once I had then reasonably dialled in, I started adding a little bit of D (in increments of 0.02) to make the robot more responsive. I sometimes needed to decrease P or increase I to remove any oscillations caused by the increased D.

In the end, the following PID’s worked well:

ATC_BAL_D        0.120000
ATC_BAL_D_FF     0.000000
ATC_BAL_FF       0.000000
ATC_BAL_I        10.000000
ATC_BAL_IMAX     1.000000
ATC_BAL_LIM_TC   0.500000
ATC_BAL_LIM_THR  1.000000
ATC_BAL_P        3.200000
ATC_BAL_PDMX     0.000000

Looking at the logged PID’s, there it still some overshoot when slowing down, but that seems to be expected for balancebots as they need to tilt opposite to their current direction to reduce their velocity. I had a persistent 2.5 degree wobble, as shown in the below graph:

ATC_BAL
ATC_BAL1148×511 92.3 KB

Whilst the above graph may indicate a non-optimal tune, a video showing it’s movement is far less severe than one might expect.

https://youtu.be/KRBPE0iexJE

So, that this point I have a balancebot that works fairly well in manual mode. In my next post, I’ll go through the speed and throttle tuning.

6 Likes
2

Glad to see interest in this fascinating rover (the next fascinating one could be rotating balance 90º (RC bike capable of standing still with flywheel)).

Supposedly, center of gravity is to be over axle, so that left alone the Balance Bot falls.

In ArduRover software control is through DIR/PMW’s or RC pulse, which saves pins. Positioning is done with direct/quadrature signals, which makes possible indoors missions fixing EKF origin.

I’ve built a few of these rovers, using 3/4 channels RC car transmitters (sticks or pistol type), changing ESC electronics (most not programmable) or motors (DC, steppers, brushless), but not using expensive controllers like this Roboclaw (which otherwise I suppose provides maximum flexibility for your tests):

  • Based on this chinese board, the most simple controller (DIR/PWM’s, just some gating and the power drivers, no signalling, pulldown’s recommended soldered on PWM’s). The Balance Bot was stable, but I changed this board to LM298+TTL glue, since it occupied a lot of space.
  • Stepper motors with encoders and Pololu TIC T500’s (direct coupling without gearing). The encoders provided speed and direction signals, which I converted to direct/quadrature with an Arduino. The implementation was slow and not very stable.
  • Low KV brushless motors with encoders (also direct coupling without gears). Positioning signals at 120º (irrelevant). Implementation also not very stable.
  • Based on hoverboards, with their electronics (well documented) or other. Very stable, since center of gravity is initially below axle, requiring a doll (here up to almost 1/1 scale).
  • Based on MC33926, which provided very stable implementations (I don’t know why), very critical on this one , with lidar and cat on top. Also, best with planetary DC motors.

On the opposite, I tried a dual bidirectional brushed ESC and, although wheel movements were correct, I couldn’t stabilize it (pending trying again).

Also, in general, these implementations have low torque, and suffer even in moderated ramps. Have you tried in a ramp?

BTW, I would like that some day the encoder signals interrupt code be improved, removing the floating point division at interrupt time, executed many times per second for all encoders and wheels, even the STM32’s are so fast that lost time isn’t noted.

3

Really great to see this and thanks for the detailed build and parameter information!

4

With the Yahboom robot, it’s not great after 6 degrees and basically impossible after 10 degrees. This is more likely due to the (default) 10 degree pitch limit in ArduPilot though.

The manufacturer’s page mentions that it can do up to 15 degrees pitch, which I want to try out after I’ve got a basic tune done.

1 Like
5

Part II - Acro mode tuning (speed and throttle)

In starting the speed and throttle tuning for the Balancebot, I started with the “quicktune” Lua script (QuikTune — Rover documentation). I gave it some suitable value for the circle speed and radius used in the tune:

CIRC_RADIUS      0.6
CIRC_SPEED       0.5

I also needed to give it some initial throttle and turn values, as the balancebot had some really bad oscillations during the tune:

CRUISE_SPEED 0.5
CRUISE_THROTTLE 50
ATC_STR_RAT_P    0.100000
ATC_SPEED_P      0.400000

The quicktune gave decent values for steering, but I did increase the steering limits to make it more snappy:

ATC_STR_RAT_MAX  360.0
ATC_STR_ACC_MAX  360.0
ACRO_TURN_RATE 360

The speed tuning wasn’t very good (too much I value), so I did a manual tune. This gave the following tuning values:

ATC_SPEED_I      0.700000
ATC_SPEED_P      2.000000
CRUISE_SPEED     0.600000
CRUISE_THROTTLE  55

This gave a good tune for speeds up to 0.6 m/s.

Going Faster

The Yahboom documentation gives a maximum pitch angle of 15 degrees, so I was curious if I could get the Balancebot running faster than 0.6m/s.

The short answer is that a maximum pitch angle (BAL_PITCH_MAX) of 12 degrees did work nicely, any speed more than 0.6m/s very very unstable. The increased maximum pitch angle did allow the Balancebot to travel on greater slopes (up to 10 degrees).

I did also need to relax the balance limits a bit:

ATC_BAL_LIM_TC   0.500000
ATC_BAL_LIM_THR  0.800000

The barrier to faster speeds was the aforementioned overshoot (in my first post) in the pitch angle controller. The overshoot appeared to be proportional to the rate of change of throttle. A fast throttle movement would create large overshoots (and thus topple the Balancebot), whereas a gradual throttle movement would have smaller overshoot. I did play around with various parameters to try and limit this, but could not find a solution.

In my next post I’ll finish off with the navigation tuning, for waypoint navigation.

2 Likes