Our robot for Submerged, Boxetta, was quite good, as it had everything we needed, in an efficient manner. Unfortunately, it was also quite detailed and the brick had to be unplugged each meeting to charge. As such, we had some ideas to improve it:
Swap to Spike, for size efficiencies.
Remove one colour sensor and reposition the second, to quick-select missions.
Use a touch sensor as a third button, since Spike only has two?
Ensure easier access to the charging port, maybe using a 7x11 O frame as a mounting spot for the whole robot.
As a result of swapping to Spike, we had to create a new MyBlock Library, since the coding environment was slightly different, and we wanted to improve our previous code anyways.
In EV3, we had:
Gyro Drive (No control over Gain)
Gyro Turn (Slightly inaccurate, one for left & right not both in one)
Gyro readout
Gyro Calibration
Colour Calibration (Lengthy, inaccurate)
Through the off-season, we were emailing each other and sending each other google forms, to figure out what we wanted to see in our new robot, and used that to improve our robot design, since we had a central location for information about our opinions, without having to constantly check with each other.
We also had some code ideas, such as:
A timer which stops the robot at 2:30, to simulate tournament conditions.
Different gyro drive types.
When swapping to Spike, we also swapped to Pybricks, a python-based dual coding environment, with block code on one side and text on the other, so that we could:
Use Git based code management software.
Learn Python without overly hindering our coding ability.
While learning how to use Pybricks, we did some exercises, such as:
Building a brick sorting robot from a tutorial, then figuring out how to code it ourselves.
Moving a robot without using the drive base.
Moving in different shapes (Triangle, square, etc)
Bumper bot with hub buttons
Bumper bot with colour sensor
Line Following
Bang-bang
Proportional
Some PID
This brick sorter was designed to sort System 2x4 bricks, primarily green, red, blue & yellow. We also added sorting for white, and tried to sort purple or black, without great results.
We experimented a lot with how to get precise starting locations, with some of us opting to load the bricks after the program started, so that we could automate that, or aligning the L beam ourself. Some also added a beam onto the trays, so that we could do a Drive to Resistance block to calibrate location, while others changed the design of the trays to align with the beams under the motor.
We built a robot from the Pybricks instructions, then completed exercises such as those listed above.
Once we made a line follower, we also used the distance sensor to platoon our line followers.
The line follower code, either proportional or PID, can be adapted to slow down when the distance sensor is detecting a distance under a certain threshold. This, paired with bumper reflectors, can allow you to platoon more than 6 robots together.
Instead of GitHub, we instead used a locally hosted GitLab server for our code management. We had a meeting or two to learn how to use GitLab in the weeks leading up to kickoff, and experimented with it.
Each different run, worked on by around two people at a time, was worked on on separate branches, and then tested in front of a reviewer before merging. Because Git is a relatively complicated software, we had our Coach as the only person with control over merging, especially since he has experience with it.
Since we swapped to Spike for Unearthed, we needed to redesign our robot. We had some long discussions to determine what how we would design our robot, debating everything from what sensors and motors to use, what amount of walls to use and what techniques to use in our design.
Eventually, we settled on using this information to each design our own robot, with some of the Robot Design Rookies building the Spike Advanced Driving Base, while more experienced designers built their own.
Some of the Robot Designs considered were:
2 Attachment Motors
Colour sensor for attachments
Ultrasonic sensor
2 Drive Motors
Partial Walls
Colour sensor for Attachments
2 Bi-Directional Attachment Motors
2 Drive Motors (Back-wheel drive)
1 Touch Sensor
Full Walls (Completed after this image)
Partial Walls
2 Large Drive Motors
2 Large Attachment Motors (Both sides)
Large wheels
2 Large Drive Motors
2 Medium Attachment Motors
1 Colour Sensor (Attachment analysis)
1 Touch Sensor
Partial Walls
Ultimately, we would go with the fourth option, after discussing between this and the second. We chose it due to concerns over a bit of lacked polish and bias from previous seasons and negative experiences with the attachment mechanism.
M06
M08
M05
M07
M09.1
M09.2
M10
M11
M01
M02
M03
M12
M15.1
M14.1
M14.2
M14.3
M14.4
Before our Regionals competition, we did several test Robot Games, and reliably received a score of 330 or more.