5 thoughts on “Mini-Sumo Robot Competition May 2014 in Horw”

1. Oh what fun it must be to take that class and come up with new strategies and designs to win 15 seconds worth of fame. I am sure I would love to take that class – if it were in English. 😉

   It seems to me that the first robot to detect the other is about 90% likely to win. So one would want detect and attack the other as soon as possible. What are some of the things that caused the delays in so many of them getting started? Is it hard to get them started faster?

   How complicated are the programs that run them? Is there a generic program that the students can modify, or do they have to do all of it by themselves? Can you post an example of one. I would love to see how it works.

   Are the parts restricted, or might one add hall effect (or some other) sensors to the sides of the robots to detect when they are being pushed so that the “pushee” can spin around fast and get away from the “pusher”?

   Are the contestants allowed to treat the robot treads in any way? I would want to try putting rubber cement on the tracks to make them more sticky. If that is not allowed, could one use alcohol to clean the treads? I’ll bet a dab of acetone in the alcohol might help them get “extra” clean (and sticky).

   Can one “interfere” with the sensors of the other robot, like jamming its sensors or over-powering its LEDs?

   How many teams didn’t get their robots done in time? (I can identify with them.) 😉

   Thanks for the post, Erich. It was great fun watching the robots do their thing and seeing the different ways the students tried to solve the same problem.

   LikeLike

   Reply ↓

   • Good news for you: that class is in English :-). And yes, it has been definitely fun!
     You are right: the robots who are able to locate the opponent definitely have a high chance to win. But more important is not to run of the ring because the line sensor is not working properly. I have seen (not in this course) sumo bots which had no black/white floor sensors: all what they had was excellent sensors to find the opponent, then simply go and push them out. To me an excellent minimal (and successful) strategy, if implemented right.
     And you are right that some had problems to get the bots started on time. The rule is that after the start they have to wait 5 seconds after the button press. Some robots screwed up with that (I need to check their solution in GitHub), and some had not implemented storing the calibration data in flash (which was one reason for failure). Or their button handling/debouncing was not working properly. In the next course I need to put more emphasis on this part.
     Example: I have one available on GitHub (https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples). I develop my bot application in parallel with the students (we are using a private GitHub repository), and I share (most of) my code with them. But I do not share everything on the public GitHub as it still need to be challenging for the next class ;-). Students do all themselves. During the course I go through the theory and share Processor Expert components and as well my code templates as a starting point, but at the end they have to put it together themselves. I can share with you my bot program (which has a lot of features, of course ;-), just let me know. The bot parts are not restricted at all, as long they stick to the official sumo rules: max 10×10 cm size (no height limit), max 500 g mass. They get a kit with board, chassis and ultrasonic sensor, but they are free to change or use their own stuff.
     Yes, cleaning the tracks is one advise I give (see https://mcuoneclipse.com/2013/12/12/zumo-robot-last-tuning-tips/ and https://mcuoneclipse.com/2013/11/23/sumo-robot-battle-tips/). But the wheels/tracks shall not be sticky: if the bot is put on a sheet of paper and lifted up, the paper shall not stick.
     “interfering” is only allowed as long it is not ‘evil’. I recommend you have a look at http://www.robotroom.com/SumoRules.html. Some bots in the class use white paper to be put under the opponent line (black/white) sensors to confuse them, this is allowed. But not actively jamming the signals e.g. with high power laser or emitting EMI/etc.
     And: all teams had their robots done in time. There was clearly a rush in the last semester week, but they did very well.
     Glad to read that it has been great fun: you might check out the video how the students did last semester too: https://mcuoneclipse.com/2013/12/16/intro-mini-sumo-tournament-2013-lots-of-fun/

     LikeLike

     Reply ↓

2. Pingback: Configuration Data: Using the Internal FLASH instead of an external EEPROM | MCU on Eclipse

3. My partner and I absolutely love your blog and find almost all of your
   post’s to be just what I’m looking for. Would
   you offer guest writers to write content for yourself? I wouldn’t mind creating a post or elaborating on a few of the subjects you write regarding here.
   Again, awesome site!

   LikeLike

   Reply ↓

   • Hi Irvin,
     yes, guest writers are always welcome, and be free to pick up a topic. Contact me on my email address noted on the About page of this blog.

     Thanks!
     Erich

     LikeLike

     Reply ↓

This site uses Akismet to reduce spam. Learn how your comment data is processed.