How hard is it to program a swerve drive train in arcade drive?

[airbornehurdle]

Hello,

I'm from a rookie team (that is actually getting out of rookie status next season) and I'm the programmer lead for my team. My team was thinking of doing swerve drive train instead of slide drive train. As a newbie in Java, I was thinking that putting arcade drive on a swerve drive train must be hard. I was wondering for veteran programmers out there, how hard is it to do arcade drive for a swerve drive train?

[GeeTwo]

Arcade drive only gives you two degrees of input, whereas swerve (or even holonomic) gives you three degrees of freedom of overall robot motion. That is, you can translate in two directions, and rotate around a vertical axis. Doing two-axis arcade drive will leave one of these (or some composite degree of freedom) out of reach.

On the small-scale (about 1/3 FRC scale) swerve I played with a few years ago, I drove it with a three-axis joystick. Joystick position corresponded to translation, and twisting the joystick corresponded to rotation speed. Getting the swerve part right was MUCH harder than mapping the controls to the desired motion.

[asid61]

I would take a long time learning how to properly create PID loops and tune them for a lot of different situations before attempting a swerve drive. Once you understand the concepts involved on an intrinsic level swerve becomes a lot easier.
Swerve isn't hard- if you know exactly what you're doing going in.

[Andrew Schreiber]

Originally Posted by asid61

I would take a long time learning how to properly create PID loops and tune them for a lot of different situations before attempting a swerve drive. Once you understand the concepts involved on an intrinsic level swerve becomes a lot easier.
Swerve isn't hard- if you know exactly what you're doing going in.

And you don't flip the coordinate systems between your wheel modules and your gyro...

Really for me that was the hard part - keeping track of all the moving parts and their directions then keeping that in sync with the math.

[Oblarg]

Originally Posted by Andrew Schreiber

And you don't flip the coordinate systems between your wheel modules and your gyro...

Really for me that was the hard part - keeping track of all the moving parts and their directions then keeping that in sync with the math.

This becomes a lot easier if you structure your code in a reasonable way.

[Andrew Schreiber]

Originally Posted by Oblarg

This becomes a lot easier if you structure your code in a reasonable way.

It's also a lot easier if you have physical access to the robot and as such have an accurate mental model of the system (Which I didn't have). Hard to catch bugs with a test suite if your test suite is out of sync to the physical model.

[notmattlythgoe]

Originally Posted by Andrew Schreiber

It's also a lot easier if you have physical access to the robot and as such have an accurate mental model of the system (Which I didn't have). Hard to catch bugs with a test suite if your test suite is out of sync to the physical model.

Why are you testing your robots in sinks? Don't you risk water damage?