Round-a-Bot: Holonomic Inverted Pendulum Robot

Jeff Fletcher, Sung-Tu Ho, Jason Kloess, Ranjit Raj, Steve Vozar

ME 552 Final Report - 20 December 2010

Introduction
The original intent of this project was to design a robot system to balance on a single spherical
ball and translate in two directions (forward/backward and left/right). The platform was to be
able to support the weight of a person (<200 lbs) at a comfortable sitting height (2.5-3ft).

Since drafting the initial project proposal, our design objectives have been scaled back in order
to try to complete the project within the time frame of the semester. Our goal for the end of the
semester was to get the robot chassis (without a human payload) balanced on the ball without
any external support.

The current status of the project is as follows:

● All machining has been completed
● The robot is completely assembled (both in mechanical and electronic components)
● All power and signal wiring has been completed
● All actuators and sensors are functioning properly
● The system can run in open loop (human can control motor speed and direction).
● The system responds as expected in closed loop (motors respond to tilt magnitude and
direction measured by the IMU). Although this qualitative performance in closed loop
works, full balancing control still has yet to be finalized.

Unfortunately, because our motor drivers do not provide a current control mechanism, our
previously developed mathematical system model is incomplete. Thus, we do not have an
accurate plant model for our controller, and we did not have time to run a system identification
algorithm to determine the plant. We attempted to create a hand-tuned PD controller with
sinusoidal gain scheduling (small gain near equilibrium, large gain at larger angles), with limited
success. A plan has been developed to get the system running a full state feedback control
algorithm by the middle of next semester.

Design Changes Since DR3

As stated from DR3, the table-top operation (without a rider) and wireless joystick control were
omitted. During assembly, preliminary testing, and group meetings we additionally dropped the
riding component and just focused balancing the robot under it’s own weight. Below is a list of
additional changes to specific components since DR3.

Actuators (Motors + Gearboxes)

One minor change in this sub-assembly was to the bearing supports that supported the motor
shaft and fastened to the face of the gearbox. It was noted during assembly of the motors shaft
stack, the dimensioned drawing of the supplied gearbox did not have dimensions noting the
mounting holes spacing. A dimension that appeared to be this (actually measuring the outside
nominal sizing) was used mistakenly during CAD modeling of these supports. To compensate,
new holes were milled so the gearbox could be properly fastened. Although this was not ideal
nor planned for in advance, the solution was adequate due to proper alignment along the motor
shaft for the rest of the components.
Motor Controller
The previous DR3 design of using 4 full H-bridge controllers (one for each direction and for each
motor) was substituted for using 2 discrete MOSFET H-bridge controllers (one for each motor).
This was done for three reasons:
1. Using four motor controllers was not cost effective and added difficulties in assembly
and wiring.
2. Using one controller for each direction for each motor could lead to controllers fighting
each other and sending conflicting signals to the motor if the control software was not
configured carefully.
3. Programming a switching logic that would work with our sensor output to command a
direction was an unnecessary complication.

The new discrete H-bridge motor controllers had adequate current limits (25A max continuous
w/o heat sink) compared to the full H-bridge (35A max continuous w/ heat sink + fan). Since we
dropped the rider operation (250lb weight concern), the 25A max continuous current was an
acceptable limit for each motor controller (validated in prior simulations of just the robot weight).

The motor controllers were also moved from the top electronics plate to the bottom motor and
battery mount plate, so that the noise associated with the high-current motor drivers did not
affect the sensitive electronics of our IMU.

Battery Selection
Originally we intended to purchase two 12 V 3.5 A-h battery and one 12 V 15 Ah battery.
However, since the 12 V 15 Ah Powerstar battery was not in stock, we opted for a 12V 12 Ah
Universal Battery. This battery did not hinder the performance of the robot in anyway but only
reduced the operation time to 0.75 - 1 hour instead of the 1-1.5 hour operation initially specified.

Machining and Fabrication

The largest change in component dimensions came from the adjustments in the bar stool
dimensions. The dimensions of the actual ‘Chicago bar stool’ were a bit smaller than the
dimensions we assumed to make our CAD model (taken from the nominal height and width
dimensions only). Although the actual dimensions were smaller than we expected, no major
changes were needed.

Miscellaneous Changes
We also had some minor changes. For example, the size of the motor controller wires had to be
changed to 14 AWG due to the smaller size of wire connector terminals in the motor controller.
Due to the significantly lower continuous current draw requirements, this was acceptable.

The emergency stop was replaced by the combination of 12V electronic switch and electro-
mechanical starter relay (for a car starter) due to the lower current limit. Originally we planned
for a solid state relay which performs better under continuous duty, but this was switched to an
electro-mechanical starter relay since the original supplier never shipped our order (even after 1
week from order and numerous follow-ups) and to save on cost.

New additions
These are some components on our robot which we did not mention in our final design. Most of
these components improve the overall safety of the robot and we felt it was important to make
these inclusions.
A new ABS motor controller mount plate was made to insulate the motor controllers from the
aluminum base plate. A cooling fan and an aluminum plate covering the motor controllers added
as well. The fan improved cooling of the motor controllers and the aluminum covering acted
partially as a Faraday cage to shield noise but also to physically protect the small sensitive
motor controllers.

Additional safety features included were: a plastic shield covering the entire robot to protect
from external disturbances, fuses at important junctions (175A on the 12V motor driver circuit
and 8A on the 24V cRIO circuit) were included so as to protect important electronic components
and four caster wheels to protect the robot from too large of a tilt angle.

Hardware Performance Comparison

It’s difficult to directly compare the performance of our system to the expected performance,
since we were unable to get the robot fully balanced in closed loop. However, we can compare
the performance of certain elements of the system to their expected performance.

Wheels and Ball

The omniwheels worked as expected - we were able to transmit power in one direction while
allowing slip in the other direction without any problem. The ball had a slight texture and a
few ridges on it, which at first seemed like it may cause problems, but the ride on the ball was
relatively smooth, and rubberized surface on the ball allowed the wheels to transmit torque to
the ball without much slip, up to chassis angles of about 15-20 degrees from vertical.

We did notice an asymmetry in the torque transmitted to the ball however. Since the wheels
were located on one side of the ball they could more easily spin the ball in one direction than
the other (forwards/backwards). In this case, it was easier to “climb” over the ball (think climb
milling) than to pull it in the opposite direction. This asymmetry could cause some problems with
the control algorithm, but can be compensated for if known based on the which direction the the
robot is tilting.

Motors and Motor Drivers

The motors worked as expected - one of the motors has a slight wobble due to some bearing
axial asymmetry induced during motor stack assembly. However, because we are working at
low speeds, this is not a serious issue. The gearboxes work as expected and provide adequate
torque to the ball. They also do not bind or seize under significant load (i.e. dead weight of
robot).

The motor drivers transmitted a PWM voltage signal to the motors, which is different from
the current control method we had originally planned, so our plant model for the system was
incorrect. Instead of a current command to the motor controller, we needed to send a duty cycle,
which corresponded to different currents depending on the load on the motor.

IMU and Encoders

The encoders worked as expected, there were no issues getting them to function properly.

According to the specifications of the IMU, we should have been able to power it with the
cRIO, however there was an issue with a charge pump associated with the circuitry of the
Gyro that meant that the cRIO could not properly power the IMU. We solved this problem by
adding another voltage regulator to draw 3.3V from the 24V battery source. The IMU functioned
properly after this change.

cRIO
The cRIO was a bit difficult to work with. It would sometimes have trouble connecting with the
computer, and it occasionally had inexplicable errors. On the other hand, it was almost certainly
easier to work with than a more bare-bones micro controller. By the end of the project, we were
able to include all features we had originally planned to include on the cRIO.

Small Electronics Circuits

The circuit layout on the PCB worked as expected. The sensors of battery capacity will alert us
when the battery voltage below 20.6V and 10.4V (for the 24V and 12V circuits respectively).
Furthermore, the 3.3V and 5V voltage regulators on the board can successfully drive the IMU,
encoders and current sensors.

Lessons Learned (Changes to Design Process)

If we were to do a similar project in the future, there are a few things we would do differently for
the second iteration.

Component Testing
If possible, we would have acquired all the components with the most uncertainty (such as the
motor drivers and the cRIO), and test them out before the rest of the components arrived, so
that we would have more experience with them before trying to implement them on the final
system. For example, testing the motor driver PWM signals with some motors under different
loads would have been very helpful to do before we assembled everything. To do this, we would
need to finalize the design early and order the components which need additional testing /
configuration well before we did.

Motor Selection
In choosing motors, we found that our current motor has a much higher top speed than we
need, so we could have reduced this significantly. For future designs, we would consider using
a higher gear ratio, or using a slower direct drive motor.

Weight considerations
At first, the goal of the project was to have a robot that a person could ride, so we weren’t
very strict with our weight requirements for the robot - since it would be much lower than the
weight of the person. However, if we were to limit ourselves to a payload-free system, we
could have designed a much lighter system, using more plastic components than metal, and
we could have severely reduced our chassis weight. Additionally, this would affect our motor
torque requirements and a wider selection of motors and drivers may have become available.
It became a question of which goal is more important: the ability to ride the robot, or the simpler
but more achievable goal of a light-payload system. We decided to maintain a focus on using
the Round-A-Bot for personal transportation, and fell short of that goal.

Assembly and wiring planning

While we made concrete plans and engineering drawings for the mechanical assembly of the
robot, we did neglect a few details that in the end would have made our project a lot easier to
assemble. We did not have an assembly plan for how the robot would go together, and when
we started to put it together, we found that some bolts were very awkward to access, and we
had to resort to some creative assembly methods. Similarly, while we made an overall circuit
diagram for powering the robot, we did not set a plan for how the final wire routing on the robot
would be accomplished, so the result was a robot with messy wiring. In the future, designing
explicitly for assembly and thinking through our wiring diagrams would be very helpful.

Motor Drivers
Selecting a proper motor driver proved to be a challenging task. Our initial specifications placed
us in an area where few motor drivers could meet the requirements at a reasonable cost.
Having gone through the project we now realize that we may have been able to select a motor
driver with lower specs. We also had trouble identifying a current controller that could meet our
requirements. As a result, our initial controller could not be used on our final product. In the end,
the best option may have been to spend time very early on in the project developing our own
current controller. While this option may have resulted in headaches early on, in the end we
most likely would have had a more successful product.

Future Work
All sensors and actuators for the Round-a-Bot are functioning properly, and the system is able
to run in open loop without any problems. However, we were unable to design and implement a
proper controller to get the system to behave as an inverted pendulum. The project timeline for
next semester is as follows:

● January 2011 - Perform system identification on the robot to get an accurate plant model
for controller design. (Lead: Jason, Steve)
● February 2011 - Design an implement a full state-feedback controller on the robot. At
this point, the robot should be fully operational in terms of balancing. (Lead: Jeff)
● March/April 2011 - See if we can port the controller from the cRIO to another
microcontroller (such as an Arduino or Gumstix board) for a more permanent
microcontroller solution. (Lead: Jason, Jeff, Steve)

At the conclusion of next semester, we should be able to determine if the Round-a-Bot should
be left intact, or if its parts would be better suited for future ME552 projects.

Conclusions
The original aim of this project was to produce a two-dimensional inverted pendulum robot that
rides on a sphere suitable for human transport. Since DR3, we scaled back our design goals
to simply be able to balance the robot chassis on the ball without human support. Currently,
we have the robot assembled and working in open loop, but our attempt at hand-tuning a PD
controller without knowing the plant model was unsuccessful, so robot balancing is not currently
possible. The plan for the next semester is to run a system identification algorithm to precisely
determine the plant model, after which a full state-feedback control system can be designed.
Following the successful implementation of the control system, we plan to switch from the cRIO
microcontroller to a more permanent solution, such as an Arduino or Gumstix board.