Gucci

From RoboJackets Wiki
Revision as of 11:47, 16 June 2019 by Afield3 (talk | contribs)
Jump to navigation Jump to search

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?

What did we discover?

What issues did we find with our design?

What did we learn about the Meta?

Gucc$$$

Gucc$$$ Introduction

Gucc$$$ Mechanical Design

Drive and Magnets

Why did we change and how?

Skids

Why did we change?

How does the new design work?

Plow

Why did we change?

How does the new design work?

Gucc$$$ Electrical Design

Microcontroller

Sensor Mounting

PCB

Gucc$$$ Software

New Tactics