The table of contents is as shown below.
From last year, we have improved a lot from our previous standards.. Before Nationals last year, Andrew had already begun to work on improving the code, so that we had a proper menu.
The design process for our code was as follows:
Get a working gyro readout
Get a "working" menu setup
Realise the menu did not work, so go back to the drawing board.
Find the Seshan Brothers menu system, and make improvements to it
Add in our original configuration code (Gyro, Colour, Motor)
Add in a gyro drive
Think about whether some pieces of mathematics were required in the gyro drive
Realise that it was required
Add a gyro turn
Find that the gyro turn did not work
Find the Seshan Brothers gyro turn, and draw inspiration from that
Find the Seshan Brothers PID line follower, and use it
Calibrate both the line follower and gyro turns
This was designed as the prototype menu, that we could base all other code on, however it had flaws, such as the fact that we could not "Go back" in the code. This meant that we would not be capable of going to M01 without going all the way through M02, M03, M04... M016, which would take a long time.
As our main piece of code, we instead we took inspiration from the Seshan Brothers and their menu system, which utilises variables. This has a gyro readout which is constantly running, so that we could see if we had gyro drift at any stage,, a gyro calibrator, a colour sensor calibrator, and a motor 'jiggler', so that we could put our attachments on, calibrate the Gyro sensor or the Colour sensors. Then, for the main section, if we press up or down, it will add or subtract 1 from the variable, and if the variable is (x) then (x section) will run, leading to (varying results) occurring, depending on which piece of code we used.
This shows the maths which we used to create our gyro drive, which was done on Wolfram Alpha
In this image, we can see that we have changed our code into myblocks, so that it is more compact. The menu interface remains the same though.
This is the gyro calibration and motor jiggler, as a myblock to allow for more compactness.
This is the colour calibration, with a few modifications. It now has capability of setting up both sensors, with white or black.
This image has a PID colour sensor, which was obtained from the Seshan Brothers, a gyro drive, and a gyro turn, also from the Seshan Brothers.
The PID line follower uses variables and maths blocks to line follow, the (proportional) gyro drive uses a lot of maths functions, mainly adding, subtractions and multiplication, as well as a mod function to make sure that it is within 360 degrees.
This was the mathematics we used for our Proportional Gyro Drive.
It first checked the difference between the current angle and our target angle (0 in this example), before offsetting it, so that when we apply modulo it wouldn't go backwards, (And would work with both positive and negative angles), applying modulo and un-offsetting it, and multiplying by the gain (0.5 in this case).
We were given the code by our coach a few seasons ago, however this season we truly understood it and mastered it.
For our robot design, we did the following, in order
Decide what key parts of the robot have
Those parts being 2 large and medium motors, 2 colour sensors, a gyro sensor and a touch sensor.
Place the motors, sensors and brick in a rough shape of what we wanted the robot to be
Realised it might save space if we only had 1 colour sensor, but if the time comes, we could reconfigure the robot design to include 2 colour sensors.
Begin to connect the motors to the brick, and then the sensors.
Add a frame
We decided to keep the name we decided on the previous year, Boxer (for the time being). We planned for there to be a gyro sensor, 2 colour sensors and bi-directional touch achieved by using a touch sensor. We then would have 2 large motors for the wheels, and 2 medium motors for the attachments. The attachment point is supposed to be at the top of the robot, with 2 motors at the back of the robot. This means that we are able to have attachments on the top of our robot to be then hanging next to our robot on the side to complete missions.
We managed to get a rough robot worked out, with the two drive motors on the bottom, two attachment motors facing upward, a gyro jammed in the middle and a touch sensor at the front.
We decided that the Submerged map didn't really involve a bi-directional touch system, and after conversing with some T.R.I members, found that they didn't use theirs much. We took that into consideration, and decided it would be simpler to ignore bi-directional touch.
This was one of the ideas that we came up with to attach the touch sensor, but it had faults - The maneuvering required to attach it wasn't going to be a good solution.
Using a slight modification to the previous sensor attachment (Seen to the left), we could attach it to the frame with ease.
These images show the other pieces of progress we made to Boxer v2.0, which were more efficient positioning and attaching a colour sensor.
In our supply, we realised that we had some large O-frames, first seen by us in the 2023 Masterpiece missions. While messing around, we realised that it fit perfectly on the bottom of an EV3 brick. We realised that it could be used to create a sturdy frame on the robot, and decided to scrap Boxer V2, instead beginning V2.1 instantly. We observed that because the charging port was obstructed by the O frame, the brick would need to be detachable, to be charged, so we would make the upper part of the robot - everything above the O frame - detachable using slip on/off style pieces, so that the brick could be charged easily, while everything below the O frame would be sturdily attached.
The first of two designs that we constructed in our tests, this design is very sturdy, and is easy to detach the brick from, because of how sturdy it is.
As you can see, the frame uses 3 long blue pins, braced from beneath. It allows for the bricks to be taken off easily, but still sticking on easily.
The top view of the second design, very compact and sturdy, although the brick can slip off, because it uses axle-pins.
It also can incorporate the gyro sensor easily, while remaining compact, as shown by the touch sensor that is positioned where the gyro will be, as a stand-in.
We decided to go with the second design, with some modifications to fit everything in and be sturdier. We got the attachment motors on, the sensors on, everything connected to the brick and framed, then decided to improve some more, by moving the attachment motors, adding a second colour sensor and improving the sturdiness of the frame. We also considered renaming it, with some suggestions being "Boxetta", "Bee" and "Boxetto", on account of Boxbot V2.1 being framed in such a way that it looked similar to Bumblebee, from the Transformers movies, and the fact that we wanted to continue using the "Box..." theme. We decided that we had reached Boxbot V2.2.
We also realised that we didn't need to make everything above the O frame slip on/off, and instead just made a system to access the brick, without permanently removing anything else. We decided that we would need to colour code Boxer's wires, using 1x3 coloured beams and loom bands, but hadn't gotten around to that yet.
In the end, we managed to get a robot that was 3 studs longer than T.R.I's robot, which was the aim of Andrew, who was a main coder, and who realised that Spike was much more compact compared to Mindstorms, and was rather persistent on getting the robot to be extremely compact.
For fun, we decided to put an FLL chicken into our robot, and considered including a spring, for fun (Alright, and also for miscellaneous fidgeting). We decided not to, though, due to space constraints.
We then began duplicating the robot (which we named Boxetta) and made "Hattachments" - placeholders that go onto the top of our robot to hold attachments. Because it went on top, we thought it was like a hat. We made 3 of these, and then created 2 more a couple of weeks later.
We ended up designing some attachments to go onto the "Hattachments". For example, for a lot of missions, there was a claw action that could be done. So Iain and Muse had designed a working claw that came off of the top motor. The missions that would benefit from this attachment was M01, M02, M04 and some collection of materials for M15. There was also a passive attachment that was used for M04 and M01 to get the Scuba Diver and the Coral tree onto their support. There has also been innovation for the Unexpected Encounter Mission. The plan originally was to build an attachment for the "Droptopus" to go onto, but it was found that it was easier to just let the "Droptopus" go onto the top of the robot and make it back to home.
We finished duplicating Boxetta, although we ended up without the FLL Chicken or a Spring within it. We then worked on creating attachments for certain missions, with varying success. Aaryan also worked on creating a dud robot, which was just a frame on wheels, to work on his hattachment without needing a full robot. He eventually succeeded, and it was used thereafter.
Iain created 2 boxes, for the Unexpected Encounter Droptopus, and the Shark, as well as a "hook" and one-way trap (Tim made it, Iain utilised it) for the Coral Tree and collecting the shrimp and coral. The one-way trap was later added to his hook hattachment, for compaction during Equipment Inspection.
Tim, meanwhile, created a dropping system for Feed the Whale, which was mostly reliable 3 weeks prior to the tournament.
We managed to make a lot of progress in the three weeks leading to Regionals, with 6 runs by tournament, allowing us to score enough to get to Nationals, which we compacted our code significantly for, with some reliability improvements.