For the sumo challenge, we built an awesome sumo fighting robot called Kano. Kano is different to all the other robot designs because it has a weapon.
We wanted to make a simple but effective build. We tested many different builds and programs to get the best result for Kano.
There was some very difficult programming to get the robot to spin around and to stop at the black line at the edge of the board. We had to change a few things with our program, which meant that we had to take a step back to move forward.
We made some changes to the robot and the programming and we had to test them out. We had to change the weapon to no weapon because it was not working. It would go down, but it would cause the program to glitch.
In the end with no weapon we came third in our class.
This past week’s challenge was to make a sumo robot that was good enough to win a competition at lunch in a free for all between both robotics classes combined.
For our robot we wanted to go for a simple approach, so we didn’t add any big weapons or anything fancy. We decided to make it very low, but wide. It means the robot had a very low centre of gravity which made it very difficult to move and tip over. We made the robot only with two wheels at the back to make it rear wheel driving which gives it a mechanical advantage when pushing.
Some brainstorming ideas were
Whether to have the brick facing up or down
Whether to have the robot low profile
To have a swivel wheel, a ball bearing or no wheels at all
Ways to detect things such as, light or touch (We chose both)
Whether gears were worth it, but they weren’t strong enough to support the build
The overall size and weight
The speed at which the robot moved
Although we did make prototypes we didn’t think to take photos at the time.
The first prototype featured gears, this robot was quite weak, the wheels weren’t attached correctly, the size didn’t meet requirements and the sensors couldn’t be placed anywhere that was easy enough to manage. This robot didn’t have a program and so we scrapped this design very early on.
This robot was our second design which we made smaller and got rid of the gears, it fit the requirements tightly and didn’t have the most complicated and thought out programming. It only had an ultra-sonic sensor which means it quite easily lost control and drove off the arena. Our programming will be featured below. We went in three battles and we lost two due to the robot driving off the edge.
Our third prototype is very similar to the model we used in the matches at lunch. It had mainly the same build, minus the extra parts to add weight, we added cable management in this build and made gave it a colour sensor to help it navigate around the arena and not drive out. The wheels were slightly weaker in this design, which we fixed for the final battle. Another improvement was the finished programming which made our robot an overall improved machine in all aspects.
The competition overall went quite well, with the final design of our great machine, Dave, an improvement on all previous prototypes. With our mechanical advantage allowing us to push all other robots in a head to head, and light weight allowing for greater agility than our opponents. Our robot coming second in the class and third overall. Only losing one battle, which happened to be to the victors of the tournament.
If we had more time and maybe knew the competition a little better we could’ve reflected this by making adjustments, such as adding wheel protection and a defence to ramps.
Our team could have done better maybe if we had a greater degree of team coordination, however our time management was much better. There wasn’t a moment when you could find all team members distracted.
The challenge was to make a sumo robot that will compete in a sumo tournament against the other groups in our class as well as the groups in the other class.
Ideas and Prototypes
With our robot, we had many ideas and prototypes. Some of which we/I tested and some would have taken too long to make or were to unrealistic to make. Some ideas we:
A gear ratio was one thing that we used. We originally had it so it was faster but with some thought we decided to switch the gears around to make it have more pushing force. This did make the robot slower but that was ok. The pushing power made up for it.
A sideways motor on the front with hooks on it to catch the front of the other robots and/or cords. This was a problem because of the light sensor that we needed to have on it get in the way.
This was also the case with a motor on the front facing downwards with hooks to push the other robots to the side. The whole idea was to make it wait 2 seconds, move backwards until it sees the line, move forwards a little bit so it’s not that close to the edge, and push the other robots to the side leading them off the edge.
To have 1 of the motors off set/reversed to make it spin along with the gear ration to make it super-fast and give it a hammer arm for extra pushing power.
We thought if it started on its side and had the littler motor on the top with one big hook on it to flip it up so we could make it as long (sideways) as we want. This would have taken some time and other parts, more than what was in one mindstorms kit and we weren’t allowed to do that.
We ended up doing a gear ratio, a sensor on the front (so if it sees black it will stop, back up 1 wheel rotation, turn around 80° and keep driving) and having a “folding out” ramp that kind of worked. I wasn’t at the sumo tournament so I don’t know how we did but in the practice tests, it works as intended. It stared of with the 2 second wait like it was supposed to and then it has a moment of going forward fast for a second (to flip open the ramp).
The programming was simple. All it had to do was turn around when it sees black, and go forward otherwise.
What we did was trade speed for power so we were strong but slow.
We had a small ramp that was used to lift are opponents so we could easily lift them up to stop them pushing us and so they cannot get us out of the ring.
We did a fair bit of testing and found that we loved having more power than speed.
We changed the wheels and placed gears to stop the wheels from gaining too much speed so we could be like a wrecking ball and hit like a truck.
Sumo robot & competition: by Harrison, Lucas and Tyson
We recently did a Sumo challenge between our class and another. Our robot was designed to push the other robot off the edge of the area to win.
We decided to call our robot Stevie Wonder, as he had many troubles with the sensors in the beginning.
We did not have many prototype robots, we mainly just built upon the one design however we did suffer a few hiccups along the way. At the start we found it a bit challenging to keep our robot within the limited size limit (inside a cone) so we had to make many modifications and changes to fix this, this involved redesigning parts of the robot.
When we first tested the robot in a practice sumo challenge it worked surprisingly well. It won that practice match and we were very happy with it. However when we added the colour sensor and made a few changes to the design/programming and it stopped being as effective. It did not seem to have enough power to push the other robots effectively. We believe this is due to a some external design flaws.
When we did the proper sumo challenge our sensors worked properly and effectively however it still did not have enough power. We ended up losing and only winning against one opponent (there robot kept driving off the playing field).
If we did this again then we would try to fix whatever programming and physical problems there were with our robot. We would have to make a few changes so this could be a good and competitive sumo robot.
In the first iteration of the robot he did fine he had a good amount of speed and power but wasn’t as defended as the later versions as well as not having a colour sensor which just made him run off the edge he would find the opponent by spinning until it’s ultrasonic sensor spotted the other robot would would get him to charge at them. next we added a colour sensor and fortified him but something was wrong, he couldn’t push anything which was a HUGE problem as that is what he was meant to do but at least he stopped running over the edge. as we went back to the drawing board we decided to remove a lot of his weight and the programmer tried to make it turn and mover all around faster.
The final version of the robot was the worst version as it lacked the defences of version 2 and the ability to actually move the opponent from version 1 but it did turn quicker at the start so it could see people which wasn’t much use as it couldn’t do anything after that making it lose the 2 matches it played in and in the first match it didn’t even win a bout. we believe the reason it couldn’t push the opponents is because it didn’t have good balance between power and speed as the lacked one of them as well as one of the wheels appearing to be faulty. at first it was believed to be him being to heavy but after removing a bunch of the weight from it.
In conclusion our robot started out well but the following version proceeded to get worse which probably not a good thing and in hindsight we shouldn’t have said he was really good in his bio. if we did this again we would probably have to make the robot more similar to the first version compared the final version as the first version actually worked properly.
The goal is to create a robot that is able to push, grab or outmanoeuvre an opponent in a game of Sumo.
Main Theme/Idea of Prototype
Our robot was originally designed with a ramp on the front for lifting/pushing other robots out of the ring, however it exceeded the size limit.
The front of the robot featured a small neck which was fitted with a light sensor for detecting the outside of the ring to prevent it from throwing itself out of the game.
The robot was named Bob the Generic because of its creators lack of interest for making a perfect robot. Our team created a program which allowed the robot to make quick and sporadic movements. It didn’t detect other robots, it was designed to be undetectable to other robots due to its insane agility.
It successfully outmanoeuvred the opponent robots most of the time.
The light sensor worked 100% of the time and Bob never fell out of the ring.
The neck allowed it to safely peek over the edges without falling off.
The program overall was successful.
What Didn’t Work?
Unfortunately various tests and rules prevented us from keeping the ramp.
The design process for the neck was rocky, however we were able to resolve it.
It has a lack of sensors to actually detect opponents.