This blog post is about our current EV3 robot we're planning to use in the 2023/2024 FLL competition. Some features: 2 large motors for steering. 2 medium motors for attachments. 2 colour sensors for picking up the white and black lines, also used for line squaring. 1 gyro sensor. To enable attachments to be changed as quickly as possible we're using gravity to keep the gears connected, i.e. you don't need to fasten anything to the robot. Every attachment has 2x 12 tooth double bevel gear (part 32270) which comes in contact with the 2x 20 tooth double bevel gears (part 32269) on the robot. The medium motors are horizontally aligned on the robots, but we use 12 tooth double bevel gears to convert that to vertical alignments. These in turn are connected to 20 tooth double bevel gears, and the attachments in turn connect to these 20 tooth double bevel gears with their 12 tooth double bevel gears. The complete robot is modelled in Bricklink Studio 2 . You can download the rob
I have been mentoring a FLL team for a couple of years and I see a lot
of confusion when it comes to the EV3 gyro sensor. In this post I will try to
explain some of the things I have learned and hopefully clear up some of the
confusion.
- There two different
generations of EV3 gyro sensors - although they look the same from
outside. You need to look at the code on the sensor itself to determine
the generation. The code is in format 99N9, where the first 99 is the week
number and the last 9 is the year number (from 2000). If the year number
is 2 or 3, you have the old generation, and if it is 4 or higher you have
the new generation. Read this page to learn more:
https://ev3lessons.com/en/ProgrammingLessons/advanced/GyroRevisited.pdf
- The new generation (N4 and
up) is more accurate. We are only using the new generation because the old
generation gave us too many problems.
- There is a difference
between resetting the gyro and calibrating the gyro. To understand the difference,
you need to understand the inner workings of the gyro sensor.
- The gyro measures angular
rate by using a MEMS sensor. Angular rate means it measures the change in
angle. By simply adding up all the changes in angle you can get to an
estimated angle, i.e., the angle itself is not a direct measurement, but it
is a function of all angular rates added together. The sensor will do this
calculation for you.
- The angular rate reading you
are getting back from the sensor is affected by the following two factors:
- Noise. The reading always
contains noise. All it means is the reading is not exact, there is a bit
of uncertainty. E.g., you may measure +0.0001 degrees per second and a
second later -0.0001 degrees per second while the sensor is not moving at
all. In an ideal world you would have measured exactly 0.0000 degrees per
second.
- Bias. Internally the sensor
is returning a voltage, let us assume any value between 0 and +5 volts.
The value in the middle (2.5V) would be the output when there is no
angular rate. If you spin the sensor anti-clockwise it will output a
voltage lower than the bias (e.g., 2.0V) and if you spin the sensor
clockwise you will get a voltage higher than the bias (e.g., 3.0V). The
problem is this bias is not fixed to exactly 2.5V, but it fluctuates over
time (e.g., when temperature changes). When you power on the gyro sensor
it will internally try to find the bias value.
- Since we are adding up
angular rates, and the angular rates contains an uncertainty (noise and
bias), it implies the angle's uncertainty will increase over time. Or more
bluntly: The more unknowns you are adding over time the more unreliable
your angle estimation will be. In EV3 world it implies the angle will be
relative accurate when you start, but over time it will get less and less
accurate. You simply cannot assume the angle will stay accurate enough to
do all your missions in 2 min 30 seconds. If you need to be very accurate
you cannot even reach the other side of the board without running into
problems.
- The bias problem is very
evident when you power up the gyro sensor while it is turning. What you
will typically get is that the angle reading on your gyro sensor will
"run-away", i.e., change at a constant rate even when the sensor
is not moving at all. To fix the bias problem you will need to
re-calibrate the gyro sensor. The link in point 1 contains code you can
use to force the sensor to re-calibrate. We typically do this once when
you set up the robot before a match. We have an entry on our menu to do a
re-calibrate. We also show the angle value on our menu screen, which
implies the student can see if the angle runs away or not. If it does run
away, they will first need to do another re-calibration before you run a
mission. You do not need to do the re-calibration on every mission. If you
do, you will lose a couple of seconds on every mission.
- The uncertainty problem
implies you cannot rely on the gyro reading alone. Periodically you need
something else to start from fresh. We are using line squaring (i.e.,
robot aligns on the white / black lines) and after that set the angle back
to 0. You can also back up the robot against the wall to square it. You
can use the gyro sensor block "Reset" to set the angle back to
0. This means your axis might now be different compared to when the robot
started, but we code around that. We have not found a way to reset the angle
to a specific value.
- We are using a simple
proportional controller where we pass in the desired speed and desired
angle in a custom block. An error is calculated between the desired angle
and the real angle and multiplied by a constant value. This value is then
subtracted from the desired speed and added to the desired speed, and
these values are used to control the two motors directly. If you need to
turn right 90 degrees it means the left wheel should move faster and the
right wheel slower. Typically, we use this custom block inside a loop
where we control how far it should go, usually by looking at degrees on a
specific motor or by looking for colour. The proportional value we are
using is typically 0.7, but that is working for our wheel size, you will
have to experiment on your robot to see what it does. If the value is too
high the robot will become unstable (it overcompensates and in effect
causes a greater error, which then again gets amplified). If it is too low
your robot will be very slow to turn.
- Some teams are using a PID
controller, and although it is a better controller it is adding a lot of
complexity which I do not you will need. I do not think you can expect a
school child to understand the inner workings of a PID controller.
- The downside of a
proportional controller is that it will not work well in cases where you
pass in a speed of 0. It will never reach the desired angle. This is where
a PID would be better (the integral part will ensure the error will grow
over time). What we do is to always pass in a speed, i.e., turn while the
robot is moving.
If you have any questions, please let me know in the comments and I will
try to answer them.
Comments