The course of our season

The plan

Our goal was to participate with NK and improve the robot. First, we made priorities for the robot, so we know where to focus on. Thanks to that we had decided to shoot in the middle goal and move Wobble goals. Later, we tried to shoot in the upper goal and upgrade the arm.

The priorities that we made also made sure that we had a limit on the points we could get.

For the driving tactics we wanted to use odometrie wheels to get the position of the robot, but we could not afford that.


During the Covid pandemic it was hard for us to find sponsors. We tried to make contact with lots of companies, but eventually they didn’t respond. And others that did respond didn’t hold on the bargain. For the rest is it difficult to promote anything for a company as only the judges will see it.

Our designs

The field

Carpet, We did not have a lot of sponsors, we wanted to save money. So we couldn’t afford the field, that is why we used a carpet instead.


Power shots

We didn’t make the power shots, because we decided during the brainstorming not to do the shots. Later we found out that this wasn’t the best strategy.

Robot design




In order to drive we used mecanum wheels, because we it is easy to drive to the right or the left. These are the same wheels as last year as you can see on the picture above. The only problem we had was finding out where the robot was in the field. So, we tried a few tests, driving 1 meter one high speed and on low speed, we concluded that the wheels were more accurate high speed.


We have had a lot of trouble designing the wobble arm. Our first design uses a 25 kg/cm servo motor and a other servo to grab the wobble goal. This design was built on one corner of our robot so it give a lot of weight on one corner. The second issue with this arm was it was really unstable because we can give it a little push to the side and the whole arm moves to that side.

Also we used a strategy to start with the wobble goal inside the robot so at the beginning of the match we extended the arm. So the wobble goal falls down. This effected the servo horns the plastic servo horns broke when the wobble goal falls.

In our second design we built the servo arm right in the middle of the robot. We tested a lot of different grippers. One example is a white L shape gripper (seen in a picture)

Our final gripper design was a v shape holder with a servo to keep the wobble goal in position. It stops the wobble goal going in other positions.

In the autonomous period we start with the wobble goal inside the robot. In past matches we start the wobble goal in the arm but this was not working for us.



Our first design as a design with small parts of garden hose. These parts were way to stiff and got stick on the rings

So we used surgical tube we used these because they were more flexible. These worked but sometimes the tubes launched a ring in our robot and got stuck.

Our last intake design uses wheels. We redesigned a Lego wheel in CAD and used the rubber tire for grip.

Conveyer belt

we use an Lego conveyer belt to transport the rings inside our robot. We use it because it was fairly simple and it worked. We use an Andymark neverrest motor to move the belt.


The first component we designed was the shooting mechanism, because we thought we can build our robot around it. We had different ways of shooting the rings such as a system with an elastic band.  The system uses a motor with a rope to pull a bumper backwards. Then release and shoot the ring.

The second mechanism we thought off was shooting with two wheels. In the figure above we brainstormed about where the shooter is located in the robot and if we will use wheels or a rubber band.

We built a prototype of the wheels shooting mechanism and stuck to it, because it was simple and it worked. In the shooter we use 2 large Tetrix wheels and 2 rev ultra-planetary motors. We ordered them at the beginning of the season and used the motors with the gear ratio 3:1. After the second league meat we discovered that we can use them with 1:1 gear ratio.

The next thing we designed was these triangles.  they keep the shooting plate up. And later we build the main power switch in it.



A thing that’s unique about our code is our robot component system. We have a man class called MainRobot. This class has a list of all active robot component classes.

What this allows us to do is initialize our whole robot like this, with only the components necessary. The code below works in both teleop and autonomous. All robot components can then, taking gyroscope as an example, be accessed like this robot.gyroscope. All robot component classes extend the RobotComponent class. This class is very simple and looks like this.

This class contains a variable for the robot class. By doing this we can acces all components from within all components. The class also contains a function called startThreads. This function is called on every component when the start button is pressed. We use this for threads like position tracking and our custom logging which we will get back to later.

Our intake is a short and simple component so we will use this to show how a robot component looks. Here is the code for the class:

In the constructor we use the hardwaremap to initialize all hardware. We also make a super call to the parent class. Here we pass in the robot so it can be assigned. Furthermore, we have a few functions for turning the intake off, turning it on and checking if it’s on.

We can then turn the intake on from any teleop or autonomous by calling robot.Intake.turnOn().

To detect how many rings are present in autonomous we transform take an image from the phones camera and transform it from RGB to YCrCb. We then look at the Cr value to determine the number of rings. The higher the Cr value the more rings.

We keep track of our position via the encoders on our mecanum wheels. We don’t use odometry wheels because this wasn’t in our budget. Keeping track of your position this way isn’t the most accurate, but it does the job.

We do sometimes face the problem of a wheel slipping. This will mess up our positioning and therefore our autonomous. We have minimized this issue in our drive code. We accelerate slowly, this way we slip less. We also have our wheels zeropowerbehaviour set to smooth instead of brake. And lastly we only drive forward and make no use of strafing in autonomous. We found that slipping happens less often while travelling forward than while strafing.

Unfortunatly, after all these measures, we do still slip sometimes. This can cause us to lose out on a lot of points in autonomous if it happens in the first few seconds.

Leave a Comment

Your email address will not be published. Required fields are marked *