The assignment focuses on modeling and control of the isolated motor-wheel
system. Put your robot upside down on your desk.
Note that you may find it easier to do most of this assignment in
simulation (easy to do in Matlab) based on the model you create,
and then tune the results
on the real system.
Here is an example simulator.
Learning in simulation is a popular approach in robotics and AI.
The difference between the simulation and reality is known as the
"Sim2real Gap".
You don't need to collect your own data to make a model.
Here is some data to work with: Sinusoids,
and Step responses. Information about the
format of this data is at the bottom of
this page.
Units: Let's use radians for wheel angle. The command has no known units, so we
should just use it as is.
Examples of frequency domain and direct regression model-making are
here.
regress.zip includes the parse-data.c, create-commands.c, and an
alternative to process.m, regress_left.m, that sets up the data for
a regression to estimate the coefficients of a model.
Part 2B: How well does your controller controlling the actual robot match
the same controller controlling a model in simulation?
Here is an example program to start with. It is just missing an implementation
of velocity estimation and therefore velocity gains. Here are the wheel angle trajectories for 3 different
position gains (in encoder units):
Here is what "instability" looks like, a continuous oscillation:
Here is an improved step response program
servo2 for the wheel motor system,
which estimates velocity by differencing
the wheel angles and applying a low pass filter to reduce noise. The
low pass filter introduces about a 6ms delay in the velocity estimate.
In the figure below the smoothed velocity differences a(k+1) and a(k-1),
and applies a low pass filter forward and backwards in time, so no
delay is introduced. The filtered velocity differences a(k) and a(k-1),
and applies a low pass filter only forwards in time.
A Kalman Filter would introduce much less delay, since it uses
a model of the process
dynamics to predict future states such as velocity.
Introducing damping through negative velocity gain allows the position
gain to be increased much more. Here are a set of trajectories that
were generated by increasing the position gain, and the velocity gain,
so the system was roughly critically damped, but the natural frequency
was increased. Note that the initial command saturation makes saturated
trajectories begin roughly the same way. The feedback controller matters
and the trajectories differ only after the command saturation ends.
This program is using floating point numbers
to represent radians. It took me a while to figure out that
printing out floating point numbers is very slow on this computer
and makes the
servo processing take too long, and the sampling rate becomes
erratic. In the process of figuring out this problem,
I changed the program to only control one wheel, and to print
out angles in encoder units even though the program is controlling
in radians. The host computer can reconstruct what the servo
computed, so the floating point version of the position measurement
does not have to be sent to the host (and neither does the velocity
estimate, but sending that worked so I kept it in.)
How quickly can you complete a 180 degree movement?
The end of the movement is when
the wheel remains within 5 encoder counts
of the target.
Note that as long as the command is saturated what feedback controller is
in use won't matter. The controller only matters for quickly slowing
down the movement after the initial command saturation is over.
Is the state space controller "better" than a manually designed feedback
controller? When would the difference be greater?
With the model I created, an LQR controller introduces too much damping.
Why might this be the case, aside from my model is bad?
How quickly can you complete a 180 degree movement now?
Can you attain higher velocity gains, and thus higher position gains?
The end of the movement is when
the wheel remains within 5 encoder counts
of the target.
Note that as long as the command is saturated what feedback controller
or observer is
in use won't matter. The observer only matters for quickly slowing
down the movement after the initial command saturation is over.
Can you "power-assist" the wheel so that when you try to manually turn
it, it "pushes" you to turn even more? The wheel should not spin when
you let go.
Make sure your battery is fully charged.
Connect the USB cable between the Nano Every and your computer.
More information on how to use the Arduino, some test programs,
how to collect data, and how to model the data is on our
Elegoo web page.
Part 1
Make a state space model of the motor-wheel system, using any technique
you like.
Part 2
Part 2A: Design a feedback-only PID controller
to move each wheel 180 degrees (1/2 revolution).
Where does the velocity signal come from?
How quickly can you complete the movement?
The end of the movement is when
the wheel remains within 5 encoder counts
of the target.
We see that the gain=0.25 trajectory overshoots very little.
The gain=0.5 trajectory gets to the goal much faster, but overshoots and
doesn't stay within 5 encoder counts of the goal until after the
overshoot is over. If you could add enough damping beyond the friction
that is already there, the gain=0.5 might not
overshoot and thus stay within 5 encoder counts of the goal much earlier.
Note that the gain=5 trajectory doesn't go much
faster than the gain=0.5 trajectory. When we look at the corresponding
commands, we see that command saturation makes the beginning of the
gain=0.5 and gain=5 trajectories about the same:
The oscillation frequency is about 12Hz.
For a system with no saturation, this would tell us
tells us that the frequencies
around 12Hz are most important to model accurately for feedback controller
design. Lower frequencies won't have much phase lag, and large gains
can be applied at low frequencies even if the model is uncertain or
wrong at those
frequencies. Higher frequencies have too much phase lag to do much
with in terms of increasing gains to improve performance,
so we won't even try to get good
performance at those frequencies. The crossover region is where
model-based feedback
control design can improve performance the most,
which is around the frequency where
the system oscillates as the gain is increased too much. The gain and
phase margins have been reduced to zero or become negative.
Since this controller is saturating the command, it is likely that the
true crossover region is at a different frequency. The most accurate model
I have oscillates at 8Hz when not saturating. It is less damped than
the actual robot, probably because it does not include friction that
is not linear with respect to velocity.
Part 3
Design and implement a feedback only
state space controller for the motor-wheel system based on your estimated
model.
Does the state space controller match the feedback controller you designed
by hand?
Part 4
Does adding an observer to your state space controller
such as a Kalman Filter to filter noise and
estimate missing states help?
A Kalman Filter should introduce much less delay that a
simple low pass filter, since it uses
a model of the process
dynamics to predict future states such as velocity.
Here are the results from my implementation, where the
Kalman Filter has much less delay, except towards the
end of the movement. Any ideas why that might be happending?
Part 5
Add a feedforward command. Does this improve performance, in terms of
how quickly can you complete a 180 degree movement?
The end of the movement is when
the wheel remains within 5 encoder counts
of the target.
Note that as long as the command is saturated feedforward commands won't
make any difference.
However, a bang-bang trajectory, where negative command saturation slows
down the movement, is likely to be the way to make the fastest movement
to a goal.
The figure below shows that fast movements driven by a feedback controller
begin with a saturated command,
and going faster makes the negative part of the command almost saturated
as well. In this example the velocity gain was limited by instability,
so I couldn't make the negative pulse saturated with only feedback control.
Bonus Part A
Can you write a program to learn a feedforward command that makes
the shortest possible movement?
Bonus Part B
Can you design a nonlinear control law that generates a time optimal
bang or bang-bang trajectory
from any state to a goal angle.
Bonus Part C
Can you "cancel" friction so the wheel turns freely?
Note that you can try to separately compensate static and dynamic friction,
or friction components due to the velocity, friction components that
are just due to the direction of movement, and friction observed when the
wheel is not moving.