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.
The assignment focuses on modeling and control of the isolated motor-wheel
system. Put your robot upside down on your desk.
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.
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):
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:
Here is what "instability" looks like, a continuous oscillation:
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.
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.