VRC Season - Change Up

This was team 1104A's robot for the 2020 - 2021 VEX Robotics Championship (VRC) season. For this robot, I wrote code for both automatic and manual control during specific portions of a match. The code includes PID capabilities for smooth navigation, global position tracking with odometry, and object detection and colour recognition for game-specific tasks.

# Game Information

This season's game, Change Up, was relatively simple. In a nutshell, the goal of the game is to score team-coloured balls into goals and to connect rows together to score points. VEX has a great video that explains the mechanics of this game, which I will embed below.

This game looked deceptively easy at the time. However, there were many challenges I encountered throughout that season. I'll shed some light on some of those, as well as some of the things I thought were pretty cool.

# Code and Features

Compared to last year's code, this year's code was a lot less jank and a lot more organized and robust. To keep things brief, here are the changes I made to the code this year based on the lessons from the season before:

• Encapsulated and abstracted components of the robot into classes where it made sense.
• Documented code with easy-to-digest comments.
• Implemented PID control for movements and actions instead of using bang-bang control.
• Wrote odometry code that tracks the global position of the robot. *
• Utilised the VEX Vision sensor for colour and object-based detection and sorting of balls.

* There were some problems with this code, but I will explain this later.

We were even proud enough of the code that we tried to submit it to one of the additional challenges teams can apply to. Unfortunately, we didn't win anything from it, but nevertheless we were still pretty happy with the result. Below is our video submission to the challenge:

Of course, no code is perfect. This code was certainly not without it's faults. However, given how questionable last year's codebase was, I'd say that this season was a decent success; I finished the season feeling happy with the work that I've done and that trumps any sort of medal or award someone could get.

# Reliability of Hardware

As cool as the code was, the hardware was pretty awesome, too! Granted, I think the improved build quality of the robot was owed to us designing it with CAD first instead of trying to hobble aluminum bars and screws together, but it's still nothing to scoff at.

That being said, although the quality of our build might've improved, we couldn't say the same about the quality of the components and parts we sourced. In fact, the condition of the hardware degraded the reliability of our code, much to my dismay. Here are some of the issues we encountered with the parts we had to work with:

• Allegedly, the PCB of the main controller, the VEX V5 Brain, was ungrounded. We've had one of these Brains die on us before. The ports where electronics are plugged in didn't fair any better, either, as some of them shorted due to static electricity picked up from the foam mats of the game arena.
• Our PID controllers didn't work as well as we wanted them to, only because the motors actually have their own internal PID controllers that cannot be disabled. You can somewhat bypass this by controlling the motors with voltage commands instead, but this leads into the next issue...
• The temperature sensors in the motors sat on the PCB instead of on the motor casing. By the time the temperatures were high enough to be registered by the sensor, the motor itself was already way too hot and the motor will automatically attempt to compensate by throttling the voltage supplied. We resorted to strapping frozen ketchup packets on the motors in an attempt to cool them down, which was a little silly. 🫠
• The sensor we used for colour recognition, the old V5 Vision sensor, does not work unless the arena is brightly lit. During testing, the sorting code works well and the robot kicks out opposite-coloured balls well. However, in an arena where the hosts add dramatic lighting to hype up the crowd, the system was effectively dead and there was nothing we could do about it. We found that out the hard way, unfortunately.
• The encoders we used for position tracking had poor manufacturing tolerances. This made our odometry code really inaccurate, even with extra filtering added on top. The inaccuracy was further compounded because our original robot design meant that the center point the robot turned on was not in the exact center.

The main takeaway from all these issues was that your code is only as reliable as the hardware that runs it. In these kinds of situations where code interfaces with physical hardware, ensuring the quality and reliability of both parts is essential. Obviously, in this case, things were kind of out of our control, but it's still a good lesson to remember for when I design my own electromechanical devices.

# The Importance of Sensors

In the next iteration of the robot, we ended up stripping a lot of the sensors. For manual control, this isn't the worst thing in the world. However, when it came to autonomous control, the robot was more or less completely blind. I tried my best to make do with the internal encoders in the motors themselves, but those encoders measured the rotation of the motors themselves and not whatever part it was moving.

I'll be honest, this is what annoyed me the most during the season. A robot without sensors might as well just be a lump of metal. It's almost impossible to control the robot accurately during autonomous portions of the competition and the performance of any routines I wrote was pretty much based on random chance. Sensors serve as a robot's only connection with the physical world and without any of them, regardless of how good the code might be, the system will be extremely limited in capabilities.

# Reflection

Despite the challenges involved with this year's game, this was still one of my most favourite experiences I've had; I can more or less guarantee that this was the genesis for my love of robotics.