The Zuck

FTC 2023
Engineering Binder
William Dang
 Table of Contents:
Tool……………………………………………………………..
3

Chassis and Drive…………………………………………….4

End Effector…………………………………………………...6

Autonomous Programming………………………………….8

Gameplay/Strategy………………………………………….12

Reflection…………………………………………………….13
Tool:
The arm was one of the subsystems that we were given from another robot, and what we were
given served as the starting point for the whole subsystem. We decided to keep the base design
of the arm the same as it worked for the team before us and the extra torque of its 4:1 gear train
would allow us to handle the weight of the wrist and end effector we planned on adding. We
decided on adding a wrist as it allowed the robot to be able to score when the base of the cone
is facing the robot towards the front, as well as when the tip is facing the robot, scoring over the
back. The wrist also allows us the versatility to still score even when the cone is in a less-than-
ideal orientation. To get it up to a standard we were happy with maintenance was performed on
the initial 2:1 gear ratio and bevel gear setup to ensure all the components were as stable as
desired. Then the 128-tooth gear and first stage of the arm were removed and rebuilt, attaching
the forearm extrusions directly to the gear or to the D-shaft it’s mounted on to minimise
backlash.

● 4:1 linear gear train

● Powered by a torqueNADO motor with an integrated 60:1 gearbox
● Total gear ratio of 240:1
● Extends from the stowed position to directly up in approximately 1.5 seconds
● Total torque of 19.9 nm
● First stage motor mounted inside U-channel of fixed stage extrusion for ease of
packaging.
● Near 360° range of motion, allowing intaking from the front and back of the robot
Chassis and Drive

Chassis
We wanted to have as wide of a chassis as possible as our large arm would raise the robot's
centre of gravity considerably so we made the chassis as large as it could be while still abiding
by the rules. The width of the chassis is 4 inches smaller than the length to accommodate the
width of the wheels we were using as they are mounted to the outside of the chassis. The
chassis also features a cutout in the front to allow cones to enter the frame perimeter to
accommodate intaking and allow the colour sensor to be mounted on the centre line of the robot
without making any compromises. In the space between the front rail and rear rail of the chassis
is mounted a flat plate to ensure the robot’s battery and phone are in a safe location.
Chassis Dimensions:
17” x 13 ¼”
Drive
For our robot, we used a mechanum drivetrain. Mechanum was right for our team as it allows us
to move in all 4 directions fairly simply without any extra moving parts. In addition, the usual
downside to mechanum, being poor traction, is less significant in FTC than in FRC as there’s
minimal defence and there isn’t any need for high acceleration or long sprints as scoring
locations are fairly close to the substation, at least in powerplay.

How Mechanum Wheels Work

A mechanum drivetrain is able to move sideways because mechanum wheels apply a force
offset to its axis of rotation, on top of applying the same force as a normal wheel. This effect
occurs because mechanum wheels contact the ground on freely spinning rollers mounted at a
45° angle from the axis of rotation. When the wheel spins, any force that the wheel experiences
along the same axis as the roller transmits that force to whatever object/floor it’s touching, while
any force along the axis of rotation of the roller would not be able to transmit that force to the
object/floor. Mechanum drivetrains take advantage of this effect by using a pair of mirrored
mechanum wheels on each side of the chassis. The wheels will then need to spin in opposite
directions to have their angled vector force match directions, allowing the robot to translate left
and right while not moving forwards or backwards.
Drivetrain Specs:
● Motors mounted inside U-Channel of chassis transmits power to the wheel axle using
bevel gears
● 4 independently driven wheels, each powered by a torqueNADO motor with an
integrated 60:1 gearbox
● 1:1 gear ratio from motor output shaft to wheel
● 0.523m/s or 1.718ft/s maximum theoretical forward speed
End Effector:

When coming up with what we wanted for the end-effector we first considered what we
needed it to accomplish, and any restrictions to be considered when designing it. For the end-
effector’s capabilities, we knew we wanted to be able to score cones to our front and over the
back, depending on the direction we intake the cone, ruling out a mechanism that relies on
opening inside the top section of the cone. Our other two options were a simple claw
mechanism and a roller intake. We determined that because the end-effector was to be placed
on a long pivoting arm, the end-effector needed to be lightweight. In the end, we decided on a
claw as the motors required to make a roller intake would be too heavy to put on an arm the
length of ours without a more major gear ratio, and a mass that heavy would heavily influence
the robot’s centre of gravity causing it to flip.
(1285 2023 cone grabber (later removed))
Design Inspiration:
To design our claw we took inspiration from the claws many FRC teams had on their
robots this year. The design of our claw was mostly inspired by the claws of team 1285 and
team 1114 (pre-waterloo), utilizing a pair of gears mounted on the pivots of each arm of the claw
to link their rotation. Doing this also allowed us to use a singular servo to actuate the arms of the
claw, saving on the extra work needed to get the servos properly synchronised.

End effector specs:

● 720g
● Actuated by a single Studica Multi-Mode Smart Servo
● Arm movement linked via gears
● Banebots on each arm to improve grip
● Outtake from either side
Autonomous Programming:

Due to a lack of time and precise odometry, my group decided on making a

simple autonomous routine that would just read the colour of the signal cone and move
to the designated position. While scoring on a junction was tempting, we didn’t believe
we had the precision needed in our drivetrain to pull it off consistently while also
completing our main goal.

Primary Sequence:
 In the primary sequence, the robot completes all the commands necessary to lead up to
reading the signal cone.
1. The robot drives forward at 30% power for 2 ¼ seconds and stops
2. The colour sensor continually reads the colour of the cone until a colour within
the parameters set in the “(colour) move" functions is detected
3. When a “(colour) move” function is run it changes variable “autoMove” to 1, at
which point the program no longer calls for the colour values of the colour sensor
4. The sequence idles

(Colour) Move Functions:

In the (colour) Move functions, the program runs an if-do statement, where if the colour output
by the colour sensor is within the appropriate saturation and hue values, a set of actions will be
completed.

1. If the values of the colour sensor are within the given set of parameters, each function
will do the following

Red: (coincides with auto zone 1, the robot needs to move to the left)
1. Change variable “colourName” to “red”
2. Change variable “autoMove” to “1”
3. Run function “updateStats”. This function refreshes the telemetry data output to
the phone
4. Run function “strafeLeft”

Green (coincides with auto zone 2, the robot needs to stay in place)
1. Change variable “colourName” to “green”
2. Change variable “autoMove” to “1”
 3. Run function “updateStats”
4. Set power to all motors to 0 to stop all movement

Blue: (coincides with auto zone 3, the robot needs to move right)
1. Change variable “colourName” to “blue”
2. Change variable “autoMove” to “1”
3. Run function “updateStats”
4. Run function “strafeRight”

Strafe Functions:

In the “strafe(Direction)” functions, select motor outputs are flipped to allow the robot to strafe
using the mechanum drivetrain and power to the wheels is set to 30% (40% to the backRight
wheel as it was underpowered) for 3.5 seconds.

updateStats Function:
The “updateStats” function sends the data obtained by the colour sensor to the FTC driver
station for testing purposes.
Gameplay/Strategy:

Gameplay:
During the tele-operated period we would control the movements of our robot with two
people, a driver and a tool-operator. The driver would handle the translation and rotation of the
drivetrain, while the tool operator would control the elbow, wrist, and claw.

Strategy:
During the match, our goal was to score as many points as possible as we needed to
offset the points gained from the endgame mechanisms of other teams. We prioritized picking
up to three cones at a time from the cone stacks located on the side of the field. This allowed us
to score 3 cones at a time onto a junction until the cone stacks were emptied. After the cone
stacks on the sides of the field were emptied we intook our cones with the tip facing the field
which allowed us to more efficiently score as turning around wasn’t necessary by using our
ability to score behind the robot. We prioritized scoring our cones high as that yielded the
highest number of points. During the endgame, because we lacked an endgame mechanism,
we planned to place our beacon on the junction with the most cones of the opposing colour
while the other robot was doing their endgame sequence. This would hopefully allow us to
negate much of the scoring that the opposing team accomplished while the other team could not
defend.
Reflection:

Overall, despite not having the best results in the competition, placing last, I believe
many of the decisions made with the robot were the right ones to make. Opting out of making an
endgame mechanism saved us a lot of time and resources and allowed the team to focus more
of our attention on the other facets of the robot like the tool and programming. In addition, while
the arm was fairly difficult to control due to a lack of setpoints, I feel like deciding on a double-
jointed arm was a good decision. Mechanically it was fairly simple and wasn’t prone to failure
while allowing us to score cones from all orientations and all junctions. I believe that we had a
good concept for the end-effector which gave the drive team freedom in the way they could
intake a cone and allowed for the use of a singular servo, making it simpler to program.

While there were some good concepts regarding the robot, there were countless places
that could have been improved, and our robot was far from perfect. When deciding on the
dimensions of the drivetrain, we failed to recognize the clutter of game objects on the field that
would get in our way. While the drivetrain was very stable it was also difficult to navigate
through the various junctions laid on the gamefield. It would have been significantly easier to
navigate the field if all the horizontal dimensions of our robot were made smaller. The arm, while
being conceptually mechanically simple, had fundamental flaws that I should’ve corrected
earlier, and often had things like hubs that were impossible to tighten or incorrect spacing in
various areas. The wrist and end-effector could have also benefited from some changes. The
entire mechanism was very heavy, and that caused extra strain on all of our motors, and we had
difficulty lifting the arm in some orientations. We should have decided to custom 3D print our
claw, significantly reducing its weight while making maintenance less necessary. In addition to
the decreased weight, we could have also opted out of using a full-sized motor for the wrist,
instead using a servo, decreasing the weight of the mechanism even further.

In the future when I make my next FTC robot there are a few lessons that I’ve learned
from this robot that I want to apply. I want to fully design and build my robot from scratch so we
can be more confident in the construction of the robot. I also want to make greater use of
custom 3D-printed parts as the potential weight savings from using plastic are very significant.
Another feature that would be extremely beneficial to my next robot is an odometry setup,
ideally using Studica’s soon-to-be-released CypherMax through-bore encoder. With two
forward-facing wheels to measure forward and backward movement and rotation, and one
sideways-facing wheel to measure strafe, we could make much faster and more accurate
movements in autonomous, giving us the possibility to score much more consistently. I’d also
change the stock planetary gearbox on the drivetrain motors from 60:1 to 40:1 to significantly
increase the speed of the drivetrain, as our wheels would slip out before we lose pushing power.

In conclusion, while I’m proud of what myself and my team have accomplished over the past 4
months, as always, there are lessons to be learned from both our failures and successes. I will
surely take the lessons and experience I learned while creating and programming this robot and
apply them to whatever I may make in the future.