We did robot oriented in 2015 for our kiwi drive but field oriented for our swerve in 2022, the field layout made it so robot oriented worked out well in 2015 and our driver was already used to tank from 2013 and 2014 but 90% of the time field oriented is probably going to be better.
2 Likes
It comes down to driver preference a lot but I personally hate single joystick and find double joystick to be just fine. The problem I have with singe joystick is that its difficult to rotate without having some incidental effect on translation through joystick inputs. Tried it once in an offseason with a 6wd and I found it clunky to control due to that. With two joysticks, translation and rotation have separate inputs which I find is easier to have fine control over each input.
For the 2022 season, I drove with linear ramps with with the joystick having full speed unlocked be default. While fine-controlling rotation was a bit difficult, linear ramps were used because I was already used to them through ftc and after trying quadratic ramps for a few hours I found it more of a hassle to change the control behavior mid-season.
As for 100% speed, Rapid React favored going fast almost all the time because of little accuracy being needed for intaking and shooting balls, so unlocking the speed by default made sense. If it were instead 2019 or really most other games that don’t favor being at full speed all the time, things would likely be much different.
1 Like
I’ve been wrestling around with some swerve control ideas for a while, and I’m curious what people think.
Most people seem to agree that the ability to finely control your linear translation rate is beneficial, but how beneficial is it to be able to finely control the angular rotation rate?
How beneficial is it to be able to finely control the rate of angular rotation of a swerve drive?
- 5 - Very Beneficial
- 4 - Slightly Beneficial
- 3 - Neutral
- 2 - Slightly Useless
- 1 - Very Useless
0 voters
But really my answer is “it depends”.
Good mechanisms won’t require precision alignment in any direction.
FLL-style Mechanical Alignmnet will always be preferable to a driver attempting to do it with precision remotely.
A gyro can be used to ensure good alignment to a fixed angle (say, to align to an angled wall for gamepiece pickup).
If lots of precision is needed, a better solution is to move the mechanism (a la turret) rather than the whole robot.
So, if you’re doing things “right”… precision rotational alignment is pretty useless. However, there are very very very few robots that do things “right” all the time.
3 Likes
This isn’t alignment, but instead controlling the rate of rotation. Slower rotation rates give you larger translation rates while translating and rotating at the same time, and vice versa. I can see some level of strategic value in that, but I’m not sure.
1 Like
Even with a good full width intake, intaking can still be wonky without fine angular control and being at the wrong angle tended to be the main reason I missed balls this season
1 Like
Our team did rotation at 1/2 speed with a squared control. It worked pretty well. We favored finer control on rotation because high speed rotation wasn’t important.
3 Likes
hmmm ok. I had merged the two concepts in my head - the ultimate goal of having a controllable rate of rotation is to achieve a certain alignment.
I’m actually not sure I have a ton of counter-examples. Spin moves to evade defense come to mind… as well as that whole victory-spin thing.
1 Like
4 Likes
We used the same squared control on our rotate and capped rotation rate at PI radians/s, usually the most we need to rotate with the dual intakes is pretty small so we favored keeping it slow, smooth, and predictable.
1 Like
For anything super precise we have a “snap” button that aligns the robot while keeping translation flexible.
When it comes to normal teleop driving, we have a quadratic on the stick rotation, and a slight cap around 70% which helps with controllability, and then it’s up to the driver to be able to manage the max vel vs max angular vel trade off.
9 Likes
A common problem with most swerve teleop control algorithms is that a large portion of the possible joystick configurations saturate the wheels at maximum velocity, in turn reducing controllability. Last fall we wrote an algorithm to address this, smoothly mapping the joystick values to wheel velocities and eliminating all saturation. Our driver (and a few other teams who also implemented the algorithm) found it significantly increased the control.
Attached is a diagram demonstrating this, with darker shades of blue indicating higher speeds (and white being still).
8 Likes
All swerves are not created equal.
Many people try to roll their own swerve. Some do so successfully. But the COTs swerves that are on the market right now are a result of some very smart people and some serious iteration. Things like minimal backlash (or zero backlash) on the sensors, etc.
So strongly consider that before trying to build your own.
Code.
Not all swerve code is created equal. For a swerve to be effective you need to be able to verify that every module is acting the way it should. Steering RPM, wheel speed, etc. Tuning and testing is very important.
Practice.
This is true of swerve or tank. Your FIRST priority should be a drivable drive base. Put some sharpie marks on it to represent intake / shooter etc, then let your driver drive it until the wheels fall off.
If you’re constantly taking the drive base away from the drive team to add components to it, you’re defeating the purpose. Having a ‘basic’ drive base that is theirs is pretty critical. We keep past chassis, knowing full well that we can bolt on the swerve or tank modules in the first couple days to have something. (Even if that doesn’t always work out perfectly).
Expectations. We’ve had drivers that complain about every little thing. They need to be counseled that “this is what you’ve got” and get good with it. We’ve fielded robots that were absolute nightmares to drive, but the drivers looked good driving them because of the amount of practice they had.
5 Likes
If they like zero sensitivity at the center.
Not sure what you mean?
Second order (parabolic) equations have x^2. There is literally no sensitivity at the origin/center. 0.001^2 = 0.000001. Cubics allow a non-zero sensitivity at the origin, while amplifying it near full throttle.
With the deadzones atleast we don’t start with values that low, I do see your point though and it is definitely something we will take a look at messing with again before next year.
1 Like
Controller deadband is definitely something that a lot of teams (not just swerve) have wrestled with. I know that when we were looking at new controllers a few years back, our top criteria was low deadband. A distant second, third and fourth were, rumble, reliability and available in different colors (so that we would not confuse the driver and the operator controllers) respectively.
Once you account for the deadband, a lot of those non-linear equations are going to perform quite similarly (to the point where very few drivers will notice). The most noticeable thing to tune is to try to achieve as close to zero “step” as you come out of the deadband as possible. Of course having a smaller deadband helps this. But this was definitely something that the drivers complained about was the robot “jerking” to life as you came out of the deadband when trying to make fine adjustments.
5 Likes
Lots of references about joystick response curves and deadzone/deadband here on CD and on the Internet especially gamers’ sites. WPILib has this statement for its applyDeadband method:
Returns 0.0 if the given value is within the specified range around zero. The remaining range between the deadband and 1.0 is scaled from 0.0 to 1.0.
2 Likes
@GeeTwo made a good point about the slope of the curve at 0, it is beneficial to have some slope here and something I will have our team look at just for that reason alone.
And yeah i think our recent purchases of the “Power A Enhanced Xbox Series S/X” controllers have all tested ok at 6% deadzones, which iirc is what we have in code right now. 3.25m/s (our measured top speed on an average battery) and quadratic .06^2 =.0036 → .0036*3.25 = 0.0117m/s which is a pretty acceptable minimum speed.