I teach an introductory course using the LEGO Mindstorms EV3 set. My students are 7th graders who are required to take the course and may not necessarily have any background in programming/building. My school is on a trimester schedule so the course runs for thirteen weeks at a time. For this particular trimester I have one class of thirty-two students and one class of thirty-four students. I meet each class for one 50-minute period each day, five days a week. I have thirty-four computers in my classroom and one EV3 kit for every two students. I’ve been teaching this class in its current form for two years, though I’ve been teaching Robotics for eight all together.
One of the highlights of my class – as far as my students are concerned – has always been the Sumobot competition. With almost universal buy-in, they gleefully build and program robots to battle each other and knock their opponent out of the ring and into oblivion. Yet as I continually orchestrated this final unit, I found it was lacking. Lacking in sophistication, difficulty, solid building principles, etc.
While sometimes I get a cool result like this one where the students employed technique and strategy:
Most of the time I would get two robots that drive into each other like this:
More often than not (watch the entire playlist if you like) robots would smash into each other and then push forever, like this:
While I could include limiting conditions like you must use a certain sensor to detect your opponent or you must program evasive behavior, I have found that the students soon get tired of these additional limitations and I soon defeat the whole purpose of the endeavor this way.
My challenge this time around was how to keep the students excited while requiring them to learn some more sophisticated programming or building techniques. What I stumbled upon was having the students use bluetooth communication to create remote controls for their robots and to then battle with them. I simply call it Battle Bots.
I operate my Battle Bots very similarly to Sumo Bots with one important distinction: Battle Bots are remote controlled by a second EV3 brick using Bluetooth communication.
While the results are often the same:
I find that there is a far greater ability to employ strategy in the actual battle:
As an instructor, if you are unfamiliar with the use of Bluetooth communication, I would start here. The slide show at the bottom of this page from the Seshan Brothers’ great website, www.ev3lessons.com, is excellent, as is all of the other material on their site. I also have two other documents that I make available to my students.
- How to connect two EV3 robots by Bluetooth (Word, 1.1MB)
- Simple Bluetooth programming (Word, 0.6MB)
I begin the unit by showing my students that I can click a button on one brick and have a second brick respond by saying hello. The Bluetooth range of EV3 is pretty good as I can go outside the classroom door and do this from about forty feet away. This usually impresses even the more jaded students. I challenge them to do the same by pairing EV3 bricks together. Below are some screenshots of the basic types of programs they come up with. There are quite a few variations that can be done, but based on the information in one of the above documents, I like to encourage them to keep it simple.
In this program, the students first initialized a Bluetooth (BT) connection. You only have to do this on one program (send or receive) but not both. And this will only work after you have paired two robots together. After the BT initialization, a loop called SendMessage was created. Inside this loop the robot waits for the center button on the EV3 brick to be pressed, and then sends a BT message. Below I will look a bit more closely at this icon. After the message is sent, a one second wait for is included (I have students place this to just slow them down, it is not absolutely necessary) and then the loop repeats.
The picture above is the Message icon. In the bottom left is where you configure what type of message you are sending. The forward arrow and number sign indicate that it is sending a numeric message. The “respo” is the name of the robot I am sending the message to; its full name is “respond.” Next to that is the message I am sending, in this case “1”. In the top right corner of the icon is the part that can often confuse students. That is officially the message title. Because it is also “1” in this case that is where the confusion arises. I tell my students that this can be though of as the title of a book and the message itself as the content of that book. When you change the message title, you are telling the responding robot to look in a different book for a message.
Below is the responding program.
This program consists of two loops. Inside the first loop is immediately the second loop which waits for a message. If you look closely you will notice it is waiting for a numeric message in message title #1 to be equal to “1.” If it receives this message (which it should if the center button on the controlling robot is pressed) then it will exit the loop and play the cheering sound at full volume. Then it will repeat and wait for the message again.
Once my students have this down, I have them try to make a motor move on one robot when a button is pushed on a different brick. If they can get this to work, I then let them choose a partner team and start making their Battle Bots and controllers.
Another resource that I used the first time around, but may not use next time, is this excellent video from Kyle Markham (known as Builderdude35):
He includes everything that you need to know to get started with controlling one robot with another Ev3 brick via BT. Sometimes my students follow his advice blindly and don’t think for themselves. I’d love to see what they can come up with on their own. Whichever way you choose, Kyle’s videos are of immense help to any students or teacher using EV3. I recently met him at the Tufts University LEGO Learning Symposium and it was a real treat.
Here are a few videos of my students in the process of working and testing their solutions to this challenge:
What became quite popular among my students was the inclusion of the medium motor for some type of attacking weaponry. One of the difficulties many of them had was getting this to work independently of the motors moving backwards or forwards. This is where the use of parallel programming and different message titles really helped out. I also noticed a few other things of interest. One is that all students used one button for both motors forward, one for both motors backwards, one for one motor turning fully while the other stayed still and a fourth button for turning the opposite way. While there are undoubtedly more ways to control a robot (just using four buttons you could control each motor independently in both forward and backwards motions) this seemed to be the simplest for my students to pick up. None of them looked into variable motor speeds and/or direction by using a motor as a remote controller. There are other ways to do this, but time is short and this is a beginner class. One real startling observation is no teams realized they could also use the 3rd and 4th large motors from their partners’ kit to put on the Battle Bot.
Here are some of the many battles we had (there are a total of 46 on the youtube playlist if you are so inclined):
While there still is a lot of robots hitting each other head to head and shoving, there is at least the possibility for students to move, dodge, weave, or other wise get away and try again.
One of the main problems that we encountered was how to get a robot to stop all movement. Some students tried to do this with the push of the center button or by adding a touch sensor on the controlling robot. If this button was released (not pushed), the robot would default to whatever behavior was marked as the default behavior in the switch on the receiving robot. What we discovered was the best way to do this correctly was to make “no button pushed” send a signal, and for the receipt of that signal to not only stop all motors, but also to be the default position in the switch.
Here are pictures from the controlling and responding programs:
In the top of this switch, when no button is pushed, the text message “stop” is sent to the robot named “Respond” in message title 1. This is also the default message to send as indicated by the black dot next to the black controller logo. In the other two options visible in this image, you will see the black dot is gone and there is just an empty white circle next to the controller logo, with one of the controller buttons colored in red.
Here i part of the receiving program:
In this loop, an incoming text message is constantly being read and the message is being sent to a text switch. At the top of the switch you will see that if the message reads “stop” then both motors B and C are turned off. Thus the default for the Battle Bot is to not move if nothing is pushed on the controller bot.
See below for the two programs that I used to create this post.
As always I welcome any comments, questions, and critiques. If you try this yourself, please share some video!
Resources
- How to connect two EV3 robots by Bluetooth (Word, 1.1MB)
- Simple Bluetooth programming (Word, 0.6MB)
- BattleBots (EV3)
- SimpleBT (EV3)
Also in A Week in the Life
Ian Chow-Miller covers the highs and lows of his introductory robotics class for 7th graders.
- A Week in the Life #10: Candy Sorter
- A Week in the Life #11: Sumobot to Battlebot
- A Week in the Life #12: Robot Monsters!
Latest posts by Ian Chow-Miller (see all)
- Using Video to Assess Robotics Students - 21 November 2018
- A Week in the Life #12: Robot Monsters! - 9 February 2017
- A Week in the Life #11: Sumobot to Battlebot - 28 June 2016
- A Week in the Life #10: Candy Sorter - 27 June 2016
- A Week in the Life #9: Walk This Way… - 23 November 2015
