Skip to main content

FLL EV3 Robot

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

FLL EV3 Gyro sensor

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.

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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. 
  6. 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.
  7. 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.



  8. 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.
  9. 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.



  10. 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.
  11. 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

Popular posts from this blog

Installing Lego Digital Designer (LDD) on Windows 10

If you're using Windows 10 18.09 or later and try to install Lego Digital Designer (LDD) 4.3.11 you'll probably get an installation error for Adobe Flash Player. However, there is an easy way around it: Download the installation file for LDD 4.3.11. Rename the .exe file to .zip. If you don't see the .exe extension in Explorer, go to "View - Options" on the Explorer menu, then under the "View" tab deselect the "Hide extensions for known file types". Open the zip file with Windows Explorer. Copy all files in the zip to another directory on your computer. In the new folder: Delete install_flash_player_active_x.exe. Copy OpenGLChecker.exe and rename it to install_flash_player_active_x.exe. Run LDDSetup.exe. In short the installer will execute install_flash_player_active_x.exe during the installation process, but all it does now is to execute the same logic as what OpenGLChecker does. In theory you can run any .exe that will not retu

Windows Hyper-V Server 2019

This post will explain how to use the free Hyper-V Windows 2019 Server version. This version doesn't come with any GUI interface as provided in the full Windows 2019 Server version. Instead it comes with a character interface, but with the help of some third party tools you can easily get a fully functional Hyper-V server for free. The following will be assumed: You have a dedicated server connected to a network and you want to install Hyper-V 2019 on this server to run Virtual Machines and/or act as a file server. You have physical access to this server to do the installation. You have another machine connected to the same network to do remote management, running a recent version of Microsoft Windows. You don't want to join a domain or use Active Directory. You can do this if you want to, but this is not included in this post. First you'll need to download the Hyper-V 2019 ISO from  https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2019 . You’ll

Install OpenWRT 14.09 on TP-Link MR3420 with Huawei E353 3G dongle

This post will describe how to install OpenWRT 14.09 on a TP-Link MR3420 router, plus configure it to use a Huawei E353 3G dongle to connect to the internet. First download the firmware, plus extra packages we'll need later. Store this on your computer: http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/openwrt-ar71xx-generic-tl-mr3420-v1-squashfs-factory.bin http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base/kmod-mii_3.10.49-1_ar71xx.ipk http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base/kmod-usb-net_3.10.49-1_ar71xx.ipk http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base/kmod-usb-net-cdc-ether_3.10.49-1_ar71xx.ipk http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base/kmod-usb-net-rndis_3.10.49-1_ar71xx.ipk http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base/libpthread_0.9.33.2-1_ar71xx.ipk http://downloads.openwrt.org/