Software · July 14, 2022

Collector Robot using Lego Mindstorms EV3

To better understand this project, here’s a bit of context:

2021 was the year I decided to leave everything behind and start anew, with the goal of working in the space industry. I was always fascinated by space exploration, as well as all the new and innovative technologies we develop and use to further our understanding of the universe. In my research to find a course that would help me transition, I learned about the International Space University (ISU). They have multiple programs, but one caught my attention: the 1-year long intensive master program that would teach me everything I need to know about space. It didn’t take long to make up my mind and a few months later, to my surprise, I got accepted in the program. In September 2021, I officially started the Master of Space Studies at ISU in Strasbourg, France.


The Competition

Early robot prototype testing a mechanism for gem collection

As part of the curriculum, a robotic workshop was scheduled in January 2022. In fact, the workshop was a competition. Teams of 5 or 6 were assigned and each given a kit of Lego Mindstorms EV3 containing:

  • 1 x EV3 programmable microprocessor (“Lego brick”) with rechargeable Li-Ion polymer battery
  • Sensors (1 x ultrasonic sensor, 1 x color and light sensor, 1 x gyroscopic sensor, 2 x contact sensors)
  • Servo motors (2 x big servo motors, 1 middle servo motor)
  • USB cables, instructions, etc.
  • A bunch of Lego pieces of various sizes

The Rules

In the next 3 days (minus a few classes), we had to build and program a robot to perform a specific task: collect as many plastic “gems” as possible. Points would be assigned for the number of gems collected, but also each time the robot would autonomously avoid an obstacle. The competition area was a simple square delimited by white tape on the floor, which I will call the “play zone”. Obstacles were concrete blocks placed randomly at the start of the competition. Each robot would be allowed a total of 7 minutes. The competition had the following rules:

  • Within the 7 minutes, each team are allowed 3 runs.
  • A run will be terminated if a robot fully crosses the white boundary line or if the designated pilot shouts “STOP”.
  • Only the highest score of all the runs will be retained.
  • Team members are not allowed to touch the robot once a run is started.
  • Robots must start on a black mat, fixed in the center of the zone.
The competition area with obstacles

Design and Behavior

Team members had different roles and, since I was the only one with software skills in my team, I took the responsibility of programming the robot. Several methods were available to program the robot, but I chose to go with LabVIEW, since I was already familiar with this language. For those interested, LabVIEW is a visual programming language perfect for data acquisition and systems engineering, as it allows to quickly and efficiently test, measure and monitor data. The LabVIEW editor available to download on Lego’s website is very straightforward to use, as it already comes with predefined blocks for all the Lego Mindstorms EV3 motors and sensors.

Our robot, nearing completion

So, while I was figuring out the algorithm, the rest of my team was hard at work on the robot’s design. The hardest part was to figure out how to collect and store gems with a limited amount of parts. Someone pitched the idea of using the wheel motor to also spin a rotating “tumbler” that could grab and throw gems under the robot. The team implemented that idea and it turned out pretty effective, so we stuck with it! Sensors were critical to place, since they would provide data to the algorithm for boundary limit detection and obstacle avoidance. Avoiding obstacles was done with an ultrasonic sensor and the two contact sensors. Whenever the ultrasonic sensor detected something close, the robot would back track, then choose at random whether to turn left or right, then continue. When a contact sensor was triggered, then the robot would do the same, but rotate according to which sensor has been triggered.

Robot’s front view, almost fully built

As for the boundary limit detection, that was a tricky one, because we only had a single color sensor to detect the white tape on the floor. Because of that, the robot had a “blind spot”. I’ll try to explain.

When the robot detects the white tape, it would move backwards for a second or two, perform some hard-coded rotation towards its left or right, then continue with its normal operation. In the majority of cases, it works as intended and the robot stays within the play zone. The problem is that the robot has no idea of its angle relative to the white tape. Let’s say the robot arrives at the boundary at a very shallow angle, almost parallel to it. If the white tape is on the right of the robot, but its color sensor is on its left side, then the robot will almost fully cross the tape before detecting it. Now, while almost parallel to the white tape, imagine the robot going in reverse for a second or two, then rotating opposite to the play zone. That would place the robot somewhere over the tape, but facing outside the zone, with its color sensor also outside. The algorithm would then continue straight and make the robot fully cross the border, ending our run.

In our test runs, this problem happened a few times. We haven’t found a perfect solution for it, except tweaking the amount of time it goes in reverse and the subsequent rotation angle. We just had to hope that it doesn’t happen in our 7 minutes. However, if we would have had a second color sensor, then we could have programmed the rotation accordingly, greatly minimizing that “blind spot”.

I talked a little bit about the robot’s behavior depending on the sensors. Here’s a little summary of the code sequence:

  1. Check the color sensor output
  2. Check the ultrasonic sensor output against a predefined threshold
  3. Check the left contact sensor output
  4. Check the right contact sensor output
  5. Check the “special end case”
  6. Continue with normal operations
Our robot’s code (click to see in full resolution)

For anyone interested in checking the actual code, you can see above an image of our latest version from the LabVIEW editor. You will also find different blocks that allow the robot to play audio files and change its LCD display to show some cartoon faces.

Since steps 1 through 4 have already been explained, let’s discuss the “normal operations”. It could have been as easy as moving the robot straight. But I figured that would simply push the robot to constantly drive towards one side or another. Instead, I programmed it to reverse a little, then turn randomly after 7 seconds of continuous forward motion, which is about the amount of time it takes to cross 75% of the play zone. In the event where the robot crosses from one side to the other, this would hopefully allow it to turn around before the white tape and explore a bit more in-between the obstacles. Everything to stay far from those boundaries!

Now. What is that “special end case”, you ask?
Well, a rule I haven’t mentioned is that if the robot can stop by itself on the black mat, the points awarded for the collected gems would be doubled. As you can imagine, this wasn’t a rule we could ignore (not that we ignored others)! To make it worth, we trusted that our robot would last the whole 7 minutes in a single run. Therefore, I programmed it to stop automatically after 6 minutes if the color sensor would ever detect something black. The one thing out of our control though, is the fact that the robot has no idea where it is at any moment. This means that we can’t tell it to move in a specific direction to go back to the starting mat. Rolling over the black mat was going to be a lucky event, but at least we had the code ready if that ever happened. In all the Lego competitions done at ISU, only a single team achieved this feat!

Rockhound in action

The Verdict

On the final day, each team had to present their robot to the teachers and describe its features, before leaving it loose in the play zone. Ours was named Rockhound, as a tribute to the rock hunters and geologists out there. Eventually, our turn came. Our designated pilot started the robot on the black mat and we all watched it roll. It performed beautifully, collecting gems as intended, avoiding obstacles and staying in the zone. Near the end of the 7 minutes, we were eagerly awaiting to see if the robot would cross the black mat. But it never did. Oh well!

After all the teams had their turn, results were in… and we won first place! We haven’t collected the most gems, but points were also given for obstacle avoidance and we lasted the whole 7 minutes.

The overall experience was amazing. I had a great team and everything went smoothly, so we had plenty of time for testing. I also had time to help other teams with their programming. One of the team was so grateful that they named their robot after me! Overall, every team did great and some had really awesome designs and collection mechanisms. This event was definitely one of the highlights of my time at ISU!

Me and our winning Rockhound