Let's Make Robots!

Make your sumo celebrate

When making a Sumo-style robot, make it celebrate it's victory easily

Sumo robots are very, very fun to make (and always make 2).

Tip on programming your Sumo robot so it is more fun to watch:

Unfortunatly I had my sumo-period just before LMR was born, so I dont have them in posts. But I just saw some of the great Sumos, and Nano-sumes that you guys make, around the site, and I got to think of this tip:

Make them celebrate victory, it is much more fun than just driving around for ever :)


Most Sumo's can look ahead, and down - if there is something in front and if line is crosed.

Most videos that you see of Sumos are Sumos that push stuff out of the ring, and then spin around and frantic look for new stuff to push out of the ring. Point is; They never rest, never celebrate. And that is a shame IMHO.

It is very easy to let your Sumo know that it has won: IF there is something close in front, AND there is a ring below, THEN you have WON!

And then why not slow down, zig-zag-back up, find the center of the ring, and "bow" by driving a half circle backwards or something? :) If it has sound, even spit out a jingle of victory, tata da daaaa!.

Perhaps then enter a state of "sleep" only intereupted if there is something close in front of it, like a hand, or a new opponent :)


I got some comments on this, and therefore: For those wondering if this will make the losing robot celebrate; A) Who gives? B) Make the routine first stop doing anything, and then, if there is no change, it has won. If it stops doing anything, and there are changes, it has lost. But never mind the losing routine, the above will work wonders alone, trust me :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Sumo competition robo at our University and into programming stages.

We are using atmega 328 as our microprocessor( no microcontroller, all mounted and connected from scratch). I have been dweling on frits comment:

exremely bad sumo-programming to just keep on pushing

We will have an ir front sensor to detect robot and another to detect tower, but the point is that when we make contact we are going to PWM 255 our ~9v motor until our line sensor is triggered.

here is my flow chart of the schematic, am i missing something to not understand why pushing is bad sumo programming?

thank you in advance

and it's my first robot please dont throw sharp objects :)


My best answer is this: Check YouTube for some killing sumo bitches! You will see that any good Sumo has a strategy of it's own - there are many factors and ways. So my best advice would be to either try your own initial thoughts out first, or see what people have done.

Normally I'd try and be more concrete in any answer, but this is a very open challenge. All I can say is that a robot that just keeps on pushing is very easy to beat; Just do not do the same, but let it slide, and use it's own inertia against it ;)

Uh! :)

you gave me ideea with this:


let's see... victory ass shaking robot:



scared behaviour... as you see... when the robot says something in front... he stops... drives a bit back as "oh you scared me" than as a revenge push it out






As AgentBurn says robotA has better grip than robotB. The rotation of the tires of both robots will actually be forward (they both try to push each other around). The only difference is that robotB is slipping due to robotA pushing him.
And what if robotB gets pushed sideways? How will robotB know it lost?

You are inventing problems and sollutions to them. But the problem is not there.

I was talking about making the winner celebrate, not the loser knowingg it has lost - and if something goes "wrong" as you say so the loser thinks it has won, it is still better that it stops than without this addition to the code :)


My solution sucks xD 

I should have gave it more tought before giving that bad solution. Another solution would be accelerometer, so he knows in which direction it's going, but that would just give too much cost to small sumo bots... 

I found a problem with your code. Let's say you have 2 sumo robots, with identical code and build and everything with just one difference, and that is that one has better grip on the ground, and when they colide frontaly that one will win. Moments before he win he will push the other to the edge and that one will see the line beneath him and something very close infront and he will think he won and will start dancing!

It wouldn't be fun to just give a problem, so I had to think of a solution. You could add 3colour optical rotary encoder so he knows the direction it's going, and if he meets the "win" requirements with encoders going forward he starts dancing and if he does it while going backwards he starts crying :)

Btw, it would be nice to make it a challenge, it would give me additional motivation to finaly build it myself :D

Well, good thinking, but no :)

I was trying to keep this uncomplicated, so I did not get into this part. The principle works fine for making the winning bot celebrate, for 2 reasons:

Reason A:

Let us call this routine CR (Celebrating Routine).

Now tell me, what happens WITHOUT CR?
One wins, and it drives frantic around, perhaps even try to push the one outside the ring because it can see it. The loser - what does that do? Depending on the track, it drives off the edge, or something ele stupid.

Then what happens WITH CR?
The loser will (may) a victory dance - but if this includes stopping, then it is better than driving frantic around outside the ring, no? Would you not prefer it to stop? Well, if pushed backwards out, it would do this. In reality this will be rare, but you will just have to take my word for it, it will take too long to describe why - but look below for a little reasoning.
The winner will do he's dance inside the ring.

So, all in all, it is better with CR than without, no?


Reaon B:

There are a number of reasons for a "death match" usually do not end in 2 front facing sumos, one pushing the outer out. Here is one major reason to why:

  • It is exremely bad sumo-programming to just keep on pushing. No matter the grip, you will never win that way over a better programmed sumo that will sneak around, and push you from behind / from the side, and use your own energy against you.

Well it is better, it makes them cooler and gives them more personality and that is what makes small nonindustrial bots the awesomest thing ever, but I don't like makeing stuff with small "flaws" in the design phase, then when you get to the building you get small flaws too and in programing even more and when it all adds up it looks like it has big flaws (my code for going straight with encoders looked like it has epilepsy while moving) 

That's for reason A.

Reason B is ok, I understand that good programing greatly reduces chance of mistakes happening, but it's still better to remove them in design. I don't want you to think I don't like your idea, on the contrary, it sounds great, I will probably implement something like that when I make it, but I was just trying to start a discussion on how to solve that other "problem" in simplest way possible.

Well, you sure do the talk. Let's see the walk my friend ;)