Gucci
Contents
Introduction
Gucci is the sumo robot created by Battlebots between Summer and Fall of 2018. It competed in the 2018 All-Japan Sumo Robotics Competition in Tokyo, Japan. It was the first of the next line of sumo bots in RoboJackets after the Pushi line. This guide is designed to walk you through our process for designing Gucci. We hope you can learn from our successes and failures when designing your own Sumo bot.
Gucci was defined by being the successor to Pushiv. Pushiv did not win a match at its competition, our main goal was to win at least one match. This may be in actuality too high of an initial goal, but when we looked into how we could stand a better chance there were some clear directions. Pushiv was a very unique sumobot, primarily in its use of worm gears. The purpose of Gucci was to create a solid bot that sticks close to the meta. Instead of trying something untested, we wanted to create a quality sumo robot that future bots could build from.
Mechanical Design
Drive
Introduction
We designed the drive wrong with Gucci. If you want to know what we think is right, scroll down to Gucc$$$. The mistake we made was that we believed we should be designing around a desired speed and then picking a reasonable acceleration. Turns out, when you do this you reach your target speed but drive off the edge. Because of this blunder, we used a fraction of the power our motors could have output. This is what really cost Gucci from being a competitive sumobot.
A general tip for sumo drives is to plan to use shims. Shims are very thin spacers. The spacing of the drive components is very important, especially because a small change in magnet height drastically impacts its force, and using shims can help you correct tolerancing issues or wheel deformation.
Design Decisions
We got really nice motors from Maxon, which came down to our budget and negotiating a discount. We used these gears, which seemed standard from Jsumo, with a 4.3:1 gear ratio. We used these wheels from JSumo, which in reality were a millimeter less in diameter than advertised. In addition, they deformed about another millimeter.
Differences from Pushiv/How it fits the Meta
We did not use worm gears. We used a much lower gear ratio, because it appeared to us that speed was much more important in the meta than Pushiv had been designed around.
Baseplate Magnets and Skids
Introduction
The baseplate is the core of a sumo robot. A sumobot is pretty much motors and magnets, so the thing that connects those two is important. The main intellectual task of designing a baseplate is deciding where you want your centroid, or center of magnet force, to be. Weight on the wheels is going to increase friction and prevent you from slipping. Weight farther forward is going to resist your robot from being flipped. This is important because in a plow versus plow contact the robot that wins is typically the one that gets beneath the other one. Remember that bar magnets have an inverse cubed relationship between force and distance, and thus getting lifted a small amount has a large effect on magnet force. If you are designing a sumo robot that uses skids, like most sumo robots, moving the centroid farther forward will put weight on them. This is probably a good idea, but you have to analyze what capacity they have and how that weight will affect their behavior. You also have to consider whether you want the plow to bend, and if so you need to be very precise about how much it is allowed to bend and how much weight it will take.
Design Decisions
For our magnet layout, we decided to surround the wheels with magnets to create our friction. We then added a row of thicker magnets at the front of the baseplate. We wanted the magnet force to be generally at the front. Aligned with the magnets in the front were our skids. We decided to use ball casters. The ball casters we used could support the weight of the magnets concentrated at the front of the bot.
Differences from Pushiv/How it fits the Meta
Our magnet centroid was closer to the front than pushiv, which seemed to be very centered. We also used ball casters instead of small, solid, HDPE skids.
Plow
Introduction
Most plows seem to be rigid flat sheets that are angled at a shallow angle against the ground. Some plows are made of flexible spring steel that flexes to contour against the ground. We don’t really have the data to say whether one is superior to the other at this point. At competition we only pushed one bot, and we weren’t able to scoop them. This could have been due to low power, however.
Design Decisions
We inherited a unique strategy from Pushiv, which was to attempt to use both strategies. The way this works is to have a first stage (the stage closest to the enemy bot) that is springsteel, but after a short distance overlap that with a second stage that is made of rigid steel.
Differences from Pushiv/How it fits the Meta
In this case we decided to give Pushiv’s strategy another try because we didn’t see anything wrong with it and had no data from Pushiv on whether it was effective or not.
Exterior
Walls on a sumobot are only important for protecting your electronics, and potentially mounting sensors. Unlike battlebots you won’t be facing any weapons, but there is a high likelihood of your robot being flipped. If your walls are well designed, the electronics won’t take the brunt of the impact when the robot lands. Our walls were 1/8” HDPE, and while they were not used intensively we did not see a problem with that design.
Electrical Design
Microcontroller
The microcontroller of choice was the Particle Photon. The main driving force for the decision was the thought of keeping the software we had at the time without changes so that the software team could focus on expanding on strategy and teaching new members how to work with the microcontroller. Gucc$$$ and newer sumo robots have moved away from the Particle Photon towards Teensy for more flexibility on pins and types of communication.
Sensors and Sensor Locations
Line Sensors
We used a total of four line sensors, each mounted in a corner of the robot. The idea being that we would be able to detect not only if we hit the line, but in what orientation we are in relation to it. We decided to go with the analog version of the sensors because when the field gets dirty, the white lines become grey, which could cause non deterministic behavior.
Distance Sensors
For the distance sensors, we chose the Adafruit VL53L0X. These sensors are analog and communicate with the microcontroller through I2C. We put 6 of them in an array covering the front half of the robot; that is, two facing front, two facing diagonally, and two facing to the sides. The main reason we chose these sensors was because they provide you with a better idea of where the opponent is; however, we encountered some difficulties while mounting them.
The main problem is that we neglected accounting for the sensors’ vision spread because we assumed it would be something resembling a straight line coming from the sensor. It turned out that the vision spread is more of a cone, which was obstructed in most of the sensors. The sensors at the front had to be moved higher up to prevent interference from the plow, and the angled sensors had to be moved from a 45 degree angle to about a 60 degree angle from the front.
PCB
We decided to go with the same approach as Pushiv towards the pcbs. We made a main board and an auxiliary board. The auxiliary board was connected to the main board through a bus and broke out the lines for all the distance sensors and the front line sensors. Unfortunately, the CAD exported by EAGLE into Fusion 360 did not represent the height of the auxiliary pcb appropriately, which meant that the planned space under the plow was not sufficient for it. We ended up moving the auxiliary pcb to the electrical plate in front of the main board, which made it redundant and somewhat difficult to work with because of the position. All the pcb files are in GitHub for reference
Electrical Plate Design for ESC and PCB
The electrical plate was made of ⅛” HDPE and was made to accommodate the main pcb between the ESCs. The only annoying, but unavoidable part of the setup was that if we needed to remove an ESC or the pcb for any reason, the electrical plate had to come off first because the ESCs are screwed in from the bottom, and the PCB had nuts holding its screws in place at the bottom.
Software
- Software remained largely the same from past years, adopting a ‘seek-and-destroy’ tactic. Some things of note:
- Software drove the robot at the maximum speed it could without the robot stopping after its entire body crossed the line
- The input from the line sensors always took priority over other move logic
- Input from the distance sensors was piped into a framework called “Fuzzy Logic” for the Particle Photon. Essentially, the library would read the input from the sensors and decide the next movement based on the ranges we defined in rulesets
- It must be noted that Fuzzy Logic defaults to the lower end of the number range for the output, and previous code decided that output in that range was a command to make a hard left. This was fixed before the competition
- Logic to turn sensor input into movement commands was expanded to account for the two extra sensors, basically doubling the number of sensor rules we needed
- It must be noted that this code implemented logic for the start module the same as previous years’. This was actually incorrect, as the robots this year were to start as soon as the judge pressed the button on the remote. More in-depth reading of the rules is suggested so that we do not make this mistake again.
- This differed from high-performing robots in that the other robots seemed to make movement commands based on the actions of the opposing robot. That means that if the opponent moved, the robot would try and position itself in a way in which the plow was always pointed towards the opponent. If the opponent didn’t move, then the robot would jolt forward periodically (~10cm at a time). Once the opponent was close enough, the robot would turn its speed up to push to opponent out, as the chance that the opponent would be able to dodge the robot became significantly smaller.
Competition Review
What happened at Competition?
At our competition, we quickly lost our first point. Our opposing bot stopped working after this. We were able to push this bot out of the ring when it wasn’t moving. The judges repeatedly gave the opposing bot “redos” until after many attempts they gave us the win. This was the first ever RoboJackets win at this competition. We also received a 2nd round bye, advancing us to day 2 (The top 32). In our round of 32 match, we were launched out of the arena very quickly. This ended our run. It must be noted that we were in fact pushing the 2nd robot when it was pushing us back. That means that either we were not providing enough power to the motors, or our magnet force was too weak, or a mixture of both.
What did we discover?
Firstly, we found that our bot using 5% motor power (It was doing this so the line sensors could react), which was too slow. It was programmed to move at higher motor power when we entered a pushing match, but our magnet force was too weak (150 lbs) to actually achieve this. Most bots seem to move at a higher speed when the front sensors detect the opposing bot a certain distance away. We also found that input from the distance sensors didn’t really matter if the opponent made the first move and pushed us out.
What issues did we find with our design?
Mechanically, we found that we did not have enough magnet force and our spring steel plow system was not very useful because the spring steel never bent enough to be a smooth plow. Also through shop testing, we found that ball casters were not the ideal choice for our skids. As mentioned before, the distance sensors also gave unreliable input. Sensor logic was disabled during the entire tournament.
What did we learn about the Meta?
We learned that most teams are a lot less concerned with scratching. They even have magnets touching the ground. We also learned how other teams design skids. A lot of bots use carbon fiber base plates which is lighter. Bar magnets are also a lot more common than we thought. There was a pretty even balance between bar magnets and ring magnets.
Gucc$$$
Gucc$$$ Introduction
At the competition we discovered that there were many parts of the metagame that we did not understand. Gucc$$$ is a partial update to Gucci. We did not feel that an entirely new bot needed to be designed and fabricated, but we made a few crucial changes that fixed some of the severe discrepancies between Gucci and the meta.
Gucc$$$ Mechanical Design
Drive and Magnets
Why did we change and how?
The most important thing we learned this year was how to spec motors/magnet weight. We made the mistake of trying to choose motors and magnets based off of how fast we wanted to move and how quickly we wanted to accelerate to that speed. What we learned at competition was that the only statistic we should have been designing for is how quickly we can stop moving. The reason for this is because our firmware operates by repeatedly checking for the thick border of the field using a line sensor while driving forward. When the border is detected, we need to decelerate quickly enough that we do not drive off the edge of the track. By designing without this in mind, we built a sumobot that could not go near its max power without driving off the edge. There are some possible workarounds by doing clever things with software (if we know we are approaching the edge beforehand we could slow down), but until we are there, the priority for the mechanical team should be not driving off the edge. To assist with this problem, we moved our wheels to the back of the bot rather than the center. This gives more time and distance for the line sensors to react. Another drive problem we had previously was magnets behind the wheels causing us to tilt backwards and get stuck on the floor. We had to remove these before competition. Now that the wheels are in the back, the bot only leans forward from magnet force.
The other thing we were wrong about for Gucci’s drive was that we worried too much about scraping the ground. We had a lot of distance between the bottom of our magnets and the field. When we talked to Sumozade at competition, they told us that they did not have any space between their magnets and the field (they dragged). The field is harder to scratch than we expected, because our practice field is not a great representation. Scratching is illegal, so the tricky problem is discovering how much force is ok before the robot starts scratching. We did not figure that out. Our plan for Gucc$$$ is to have nearly no distance between our magnets and the ground, but use shims to be sure that the weight of the bot is supported by our wheels and skids (shims are necessary to account for wheel deformation). When we moved the magnets closer to the ground in CAD, our Magnet force increased from under 200 lbs to over 450 lbs.
Skids
Why did we change?
While Ball Casters initially seemed like a good idea, we found that small particles get inside of them really easily, making them “Crunchy”. We were constantly having to buy replacements. Most bots are competition used skids that were kind of like small wheels. We did our best to do something similar, because this bot was designed around matching the meta.
How does the new design work?
The new skid design is a 0.25 inch thick rectangle. It has a hole for a small steel axle to slide though, and 2 small PEEK plastic bushings sit on this axle. This is closer to the small rollers we saw bots use at competition (with some different material used) and it helps us stay closer to the ground.
Plow
Why did we change?
While the 2 stage spring steel concept was a cool idea, we found most teams used a sharpened blade that stayed close to the ground. The main issue with our spring steel design is that it could never bend enough for a smooth connection to be formed with the solid steel portion of the plow. Using this design, we would never be able to fully get under our opposing bots. The opposing bots plows would get stuck in that gap which is interesting, but not really effective unless in very specific cases. Also, most bots at competition used aluminum plows and only sometimes had steel, but when they did it was only at the very front.
How does the new design work?
The new design is still 2 stages, however both stages are aluminum. Each stage is at a different angle. The first stage can be sharpened to be flush with the ground. The front plate is also now angled so we have 3 different angles in the front of the bot. This aligns more with the curve shape other bots seem to have.
Gucc$$$ Electrical Design
Microcontroller
We moved to the Teensy 3.6 since it gives more flexibility to the components we can use. All of its digital pins are interruptible, it has 2 pins with DACs, and it can use most communication methods (I2C, serial, CAM, etc). The controller is also programmable through the Arduino IDE, which makes things a bit simpler for Windows users.
Sensor Mounting
On the previous bot, we ran into issue with the TOF sensors being too close to the ground. We moved the sensors up on the robot (Using cutouts on the side plate and front plate) and design new 45 degree mounts that are internal. We also added a standoff for the front line sensors to add greater distance between them and the wheels.
PCB
We removed the auxiliary pcb due to the redundancy created in the previous iteration. The main pcb now has a comparator IC to allow us to use pin interrupts on the Teensy while being able to adjust the interrupt threshold and keeping the analog signal going to the Teensy as a debug tool. To give the robot better control over its motion, we routed the motors’ encoder outputs to the Teensy and added an IMU as well. The only downside is that the board operates at three different voltages now. 5V comes from the ESCs and is used for the encoders and Teensy. The line and distance sensors are run at 3.3V since the Teensy’s pins cannot handle more than that. And the IMU runs at 1.8V.
Gucc$$$ Software
New Tactics
- In April 2019, an experimental project began with the new software members to implement code that would help the robot adopt a more “cowardly” strategy in which the robot would dodge out of the way and then push the opponent once the opponent crossed in front of the robot again. Only the timed movements were created for the experiment, but it looked pretty promising.
- This could probably be used at the very beginning of the matches, as many opponents like charging straight at us.
Team
Here was the team that worked on this project:
Mentor: Mason Murray-Cooper Mechanical Leads: Alex Field and Hank Hellstrom Electrical Lead: Juan Elizondo Software Lead: Andrew Chang Team Members: Phillip Holloway (Mechanical), Christopher Quinn Johnson (Mechanical), Logan Schick (Software) Special Thanks to Varun Madabushi and Joe Spall for helping with Electrical and Jonathan Spalten for helping with Mechanical during crunch time
