We’ve been playing around with swerve for a few weeks now. We are currently using the thrust master joystick. Before the switch to swerve we used it on a tank drive with great results. It’s super sensitive almost to the point of impossible to drive. I’m curious what joystick/controller teams are using for swerve?
Have you considered just turning down the sensitivity? iirc there’s a hardware knob on a majority of the thrustmaster line and ofc several ways in software.
We just used an xbox gamepad. Translation in left, rotation on right. You can try squaring inputs to increase sensitivity, or adding a “low speed mode” for the driver that caps the maximum velocity as long as a button like the trigger is held.
We watched Battlebots this season, and It appeared 75+% of teams used dual stick RC airplane type controllers , and most of the rest used RC car trigger + wheel controllers. I realize controllers like that might need to be mod’d to connect to computer rather than control via transmitter/receiver, but it’s still surprising we don’t see more of those controller types in FRC. I remember FRC 1778 did use a dual stick one & published a great write-up on how they did the mods a few years back.
We hesitated to use our apems with swerve. We found they had some firmware dead zones on the X and Y axis independently. For swerve (we assumed) you want a circular dead zone. Did you guys see similar behavior? I guess you can look at this as an upside get a free implementation of snap-to-nearest-pole
2 Likes
I didn’t notice any dead zone but I also didn’t look very close.
I use these Apem sticks on everything…I typically add a dead band to each axis in software and then scale the remaining travel.
I’m using Ether’s inverse kinematics as the basis for the software. Each axis of the stick directly correlates to forward, strafe or rotation vectors of the base.
Interesting, we have found added dead bands on each axis really limits your steering sensitivity around the poles (like in the left example). We make round deadbands by looking at the magnitude of the vector created by both axis (like in the right example).
This is really only noticeable when trying to drive in a smooth orbit around an object, you end up diving in an octagon-looking shape. There might be a way to turn this off, maybe yours is.
1 Like
I have never looked at it this closely. Do you any code/pseudo code for how you do this style of deadband?
I might try that.
The advantage of a cartesian deadband is you can deadband each axis individually. So if the driver tries to drive straight and pushes the joystick 100% in Y and 2% in X, you can ignore the X movement and make the robot drive exactly straight.
On the other hand, a polar deadband is better at ignoring small measurement errors in the joystick while cancelling out fewer “real” values.
1 Like
LabView at least has polar / cartesian conversion VIs built in, which makes polar deadbands absolutely trivial to convert to a cartesian deadbands and back again.
If you split your joyticks into ‘throttle’ and ‘turn’ for tank drive, you don’t have to worry about the x / y coming into play.
I strongly dislike single-joystick driving with a tank drive.
I haven’t done this for swerve, but have worked on dead-banding joysticks at an internship. We actually used an elliptical deadband, which provides advantages of both cartesian and polar deadbands. I don’t have any code for it, but could probably figure something out of people are interested.
You mind doing a crude sketch (like mine above) for how this looked?
So here are the three general states of how it worked. We controlled the shape by defining an ellipse with four points, with two lying on the x-axis and two on the y. We then solved for the foci with these four points and knowing they lie on the x or y-axis.
Here’s an example of a pretty big y-axis deadzone and a smaller x-axis.
equal deadzone on x and y.
Smaller y-axis and big x-axis.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.