1690 Swerve Drive 2019 off season project

Team 1690 is proud to present our 2019 offseason swerve drive project!
We started to work on this project in the summer, right after we came back from IRI, and after a lot of tweaks to the design and code, we’re quite pleased with the result.
The module’s design was heavily inspired by Swerve Drive Specialties’ Mark 1 module, with some changes to better suit our requirements.
Our field centric swerve code was all made from scratch and implements a lot of tricks that make driving the robot very easy and intuitive.

Link to reveal video: https://www.youtube.com/watch?v=wCakzMfRPKs

GrabCAD link: https://grabcad.com/library/1690-2019-off-season-swerve-module-1

Technical Details

A NEO motor is used to drive the module, while a 775pro is used to steer. We chose a 775pro because we wanted to use a Talon SRX + Absolute encoder for azimuth control and to run the entire control loop on the motor controller, which is impossible with a NEO.
The two bevel gears were custom machined on a 5 axis CNC Mill: The large one is made out of aluminum with a Teflon-infused anodize coating, and is combined with the wheel itself. The smaller one is made out of brass. We chose to custom machine them because, for our current manufacturing resources, it was the same effort as purchasing gears off the shelf and milling a pattern into them, and this option saves a lot of weight (around 300g for each module). So far, the gears work great even after almost two months of non-stop use.
A US Digital MA3 Absolute encoder (12 bit PWM output) is used to sense module rotation, and while we planned to use an incremental encoder to measure wheel speed(which was connected to the NEO shaft with a small timing belt), we removed it later because the NEO’s internal encoder was enough for our needs.
Both motor controllers are mounted to the module itself, which allows easy wiring and replaceability for easy maintenance.
The 4 modules were connected to a chassis for testing. the overall weight of the chassis with all modules mounted to it + electronics was 17.5kg(38.5 lbs), we then added 5 batteries to reach a weight of 101 lbs.

Our software team decided to write the code for the swerve drive entirely from scratch.
The core of the algorithm receives a velocity vector in the field coordinate system, and a requested rotational velocity and controls the 4 modules accordingly. This same algorithm is used both in teleop driving and in autonomous (following a trajectory generated by a dedicated swerve motion profile generator we wrote).
Both in autonomous driving and teleop, we incorporated vision control that smoothly guides the robot towards vision targets.
To allow the robot to reach it’s physical limitations without skidding, tipping over or requesting more than 100% of the motor power, we designed 3 layers of acceleration limits:

  1. Omni-directional, for skidding
  2. Separate limits for each robot axis
  3. Forward / Reverse limit that is a function of the robot’s actual velocity

To prevent a module’s rotation when reversing, whenever a module “wants” to turn more than 90 degrees in one cycle, we reverse the wheel’s rotation and rotate the module in the shorter path to 180-wanted_angle instead.

One nice feature of our motion profile generator is that it optimizes the rotation of the robot along the path, to reach the desired angle to the target in the minimal time. As can be seen in the autonomous driving videos, the robot continuously and smoothly rotates along the path to reach the vision target in the right orientation and then the vision control algorithm gradually takes over.

A Video of the swerve drive running an autonomous path with integrated vision control:

Showcasing the vision control; in the clip, we ran a path but forgot to not use vision correction at the end of it. the robot immediately shoots itself toward the target.

A video of our driver practicing with the swerve drive, cycling between targets and around obstacles.

A video of our driver practicing defense jukes against our 2019 robot (note the distance from the tires to the wall is only 1.8m, 2/3 of the distance from rocket to cargo ship)


What system did you use for your swerve path planning and if so, is that available anywhere for reference? Incredible work all around, definitely going to keep my eyes on this as it evolves.


Looks great! Will you be releasing your code?


■■■■■ Looks real good.

We debating cutting the bevel into the wheel like that and chickened out. Cool to see someone did it!


MFD hella


This looks super solid! I love the drive testing with the vision targets. That is a great idea for some good development next offseason.

1 Like

That auto is crispy :ok_hand:


Love this! Your videos do a great job of showing how great vision alignment with swerve can be as well as how effective swerve can be against defense.


That’s sick. Are you considering using it in 2020?

1 Like

Swerve used to be an elite club. Looks like many new members in 2020.

That depends on the game… Hopefully FIRST will give us a swerve-friendly one :pray:


Really cool! Can’t wait to see what you guys come up with this year :smile:

Would you consider any game with mild terrain to be swerve friendly? Your swerve is very impressive and throughly developed, it seems that only a Stronghold-style game might make it less advantageous

1 Like

Awesome stuff!

I’m digging the tread attachment. Have long considered something like that ourselves. Do you have any better images of it?

1 Like

That looks great! Was the wheel made on a 5th axis? Would be cool to see videos of that, or at least a CAM simulation

Would also love to see your code!

we wrote a path generator ourselves from scratch
(currently the code is a prototype and quite messy, hope to release a clean version soon, written in “Go”)

the code can be found here: https://github.com/YonatanTzury/Electron-Example

  1. a GUI in JS (Electron) - graphic interface for setting the way points (X,Y,robot movement direction, robot heading, etc…), defining the path and trajectory parameters and displaying the output

  2. algorithm in python - runs the path and trajectory generators. the path is based on Quintic Hermite polynomials and optimized according to a cost function that takes into account our preferences for the path. the trajectory generator accounts for the max velocity, acceleration and jerk of the system, taking into account the velocities “lost” to rotate the robot.


That really depends on the game itself. For example, even if Deep Space had rougher terrain/obstacles, I would still argue that a swerve drive is a huge advantage, mainly for the huge benefit that moving sideways can give you when placing game pieces. Who knows, if the benefits of swerve will outweighs the downsides, we might even go full Swank :wink:

Yes, it’s not that easy to change treads with it though, takes about 2 min per wheel. The main issue is that threading the ziptie into the small hole in the tread is pretty hard in such a small space. Another issue is that the small bump where the tread goes into the wheel is fairly noticeable. We tested peeling the rubber off of the tread on the ends, to reduce the bend radius drastically and therefore to make the bump less noticeable. The tests went well, and the next version will have a narrower slot for the treads to go through.

Unfortunately, we don’t have any videos of the manufacturing process, it was made in an outside facility (that, AFAIK, doesn’t allow photography)


If you guys want to run it, first make sure you have Node installed. Next, clone the repository and remove the node_modules folder. Then, cd into the folder and run the command: “npm install”. Once that finishes, run the command “npm start” and it should boot up :smiley:

Do you have the code for path following? What algorithm/method did you guys use to follow the generated path so cleanly?

1 Like