Our swerve has run into a weird problem recently. That’s our swerve will drive at a normal speed for a short time and then its speed becomes very slow. l have pushed my controller to the max input, but the swerve still moves at a very slow speed. l have checked my code, everything goes well before l add the slewratelimiter function. Has anyone met the similar situation before?
Can you share a link to your source code?
1 Like
Are you limiting your chassis speeds or your individual wheel speeds?
Probably not. Since it drives normally at first. And after some time, it drives slowly.
did you check the battery? perhaps it might be a brownout issue
1 Like
Yes, l have checked the battery and it’s around 12V
I would like to second the request for a code link. We really can’t know what is going on without that.
2 Likes
What do you have to do to get it back to driving normally? Turn off robot and wait an hour? Restart the robot code? Reboot the roboRIO? Let something cool down? etc.?
There might be a mechanical problem such as the swerve module binding. My team built a swerve and it bound up often. (There isn’t enough grease in the world to get them to work right so we bought SDS modules.)
Does the robot still drive in the correct direction just slowly or does it appear that not all modules are behaving badly at the same time and the robot goes in crazy ways?
If it is a code problem, then using GitHub (Git) is a valuable technique. You can share the code that we all want to help you with and you can compare versions/track your changes on your PC with VSCode (or on the GitHub server) to make sure only what you intended to change was changed. My cat looks like she is sleeping but every once in awhile a paw comes up and she helps me code! A file comparator and VSCode history are my go-to tools a lot!
edit:
There isn’t much to go wrong with the WPILIB slew rate limiter. Is that the one you are using?
Just don’t violate the one restriction:
Because filters have “memory”, each input stream requires its own filter object. Do not attempt to use the same filter object for multiple input streams.
Slew Rate Limiter — FIRST Robotics Competition documentation.
How many places do you code the calculate method? You probably need a new object (with its variable) for each place you want to use slew rate limiter.
After l redeploy the robot code, it gets back.
In the past test, the swerve works well, so l don’t think it has a mechanism problem. But l do suspect that it may be a can problem since our can wiring is really a mess.
It still drives in the correct direction just slowly.
l am sorry that our code is private now, but l can send you the related part in message. And yes, l compared the version last night and deleted the slewratelimiter function and the voltagecompensation.
l use it just in three places and you can see it from your message. Thanks!
Thanks, l will take a video when l have access to the robot. However, l remember that when the robot is put on blocks, all modules go well and it doesn’t have the slow speed problem.
Can kS,kV,kA be the problem? Since l use the feedforward to drive my swerve when l have this slow speed problem. However, the ks,kv,ka were the one with only a swerve drive and it doesn’t have the upper mechanism. But now, we have the upper mechanism on it and the robot is really heavy, and l didn’t tested the new ks,kv,ka. Can it be the problem?
If you took out the slew rate limiter code, did the robot return to driving at the correct speed?
I went over your code for the single class quickly and nothing obvious to me was wrong but I’m not a Command-based expert and some of the related code is not shown to me.
Are you getting the loop overrun error messages starting when the slow driving happens.
To verify that the motor set commands are too low I suggest displaying those on the console or maybe dashboard, etc. Also display the joystick values. Make sure nothing is changing the constants that limit your speed.
I’m assuming that it’s the robot moving slowly but still is responding without lag to the joystick movement input.
It’s past my bedtime so I can’t respond anymore now. I think there is about a 12 hour difference and I won’t be available in my tomorrow morning either.
Print out lots of values to verify all functions and have all code available for inspection is the best simple advice I can give to get more help for you.
Thanks! l will further debug it when l have access to my robot!
Another question is how long does it take before the slowness begins? Is it the same period of time every time it starts? Is it every time you restart the code?
I assume you are using this copyright code from WPILib:
/**
- Filters the input to limit its slew rate.
- @param input The input value whose slew rate is to be limited.
- @return The filtered value, which will not change faster than the slew rate.
*/
public double calculate(double input) {
double currentTime = Timer.getFPGATimestamp();
double elapsedTime = currentTime - m_prevTime;
m_prevVal +=
MathUtil.clamp(input - m_prevVal, -m_rateLimit * elapsedTime, m_rateLimit * elapsedTime);
m_prevTime = currentTime;
return m_prevVal;
}
It does accumulate the value and I didn’t grind through scenarios for any possible “glitches” in behaving with different rapidity of movements but it seems okay to me.
I’d concentrate on verifying the values with lots of prints to show if the joystick is misbehaving (horrible wrong values) or maybe your personal library has a problem.
private double inputTransform(double input) {
return MathUtils.singedSquare(MathUtils.applyDeadband(input));
}
You need to drill down to isolate the problem and console prints are the easiest way to do that. (You can learn about the debug capability and the simulator but those take some time to learn and a console print is instantaneous.)
Does restart the code mean enable, disable and then enable? If so, after the swerve drives at a slow speed, it will always drive in a slow speed. However, if l deploy the same code to the swerve again, it will drive at a normal speed again and after some time, it will drive at a slow speed. And l don’t know the exact period of time ,but l guess it is no more than a few minutes.
So, if the value can be accumulated, then when will it be cleaned? If not, doesn’t it really affect the driving?
Maybe you are right, l just find this part of code strange. This signedSquare is from team 1706’s [MathUtil.java]( 2022-Main/MathUtils.java at main · rr1706/2022-Main (github.com)). l find that if the input is squared, it may output a really small value if my input is like 0.3 or 0.4. But l remember that when l push the controller to the max value, it will still drive in a slow speed.
Apparently teams use that slew rate limiter (the WPILib version which is essentially similar) and there aren’t any issues reported for the algorithm (someone did want a getter added to the class).
I think I understand your expectations and I think if you take out that + sign you get what you want.
Give it a try and let us know the result.
This routine is okay except they misspelled the name - it should be signedSquare as you correctly typed it. It gives to finer control at low speed and retains the ability to go fast. There are many different response curves and this is a popular, easy one to implement.
The current WPILib slew method is a little different than the one I previously found. You can open the class code for the one in your code and copy it into your own file or copy this and remove the + sign.
Only the very first instant there is essentially no limiter but the next iteration gets the treatment so I wouldn’t worry about that first 0.02 seconds. My team considered using the slew limiter but ran out of time to try it.
nice catch, we will fix that 
There are more than one way to calculate and limit slew and I was hoping that you would see that the WPILib slew limit is correct for the method that adds the limited, allowed delta slew to the previous position. You should have seen that removing the + sign just gives the allowed delta slew for one iteration and doesn’t build on what the previous position was. You’re stuck on a very small number.
So it is unlikely (impossible?) that the WPILib slew limiter is your problem and we still need to print a lot of values to isolate where things are going wrong.
You should get your own drivers’ experience but from my drivers’ experience the slew rate limiter is not desired by them - they want to control the speed not the algorithm. Slightly limiting the rate of increasing speed isn’t too bad but it is especially irritating to have the robot keep going when the joystick was released; causes bumping into things usually at fairly high speeds. You can code that asymmetric slew limit but it wasn’t worth it for us. We did do that many years ago with CIM motors and D-Link radios since they didn’t play nice together on rapid direction changes.
Changing the stick response curve can be useful in place of slew limit such as using the signedSquare method that you do as discussed previously.
Can you state (or restate) why you are using slewratelimiter? It sounds as though this is only for the drive motors, not for steering, correct? It’s invariably helpful to have more context and solid information for these questions…
Hi, after yesterday’s debuging. l found the the translation and rotation value are all normal. And the speed and percentoutput which l send to the falcon and 775 are all normal. And l find that when l use velocity closed loop to control my falcon, it will drive at a really low speed. But when l use feedforward to calculate the percentoutput and then send it to the falcon, it drives at normal speed. However, l remembered that when we only have a swerve drive with nothing above it, the velocity closed loop can also make the swerve drive at a normal speed. And since then, l didn’t change the P,I,D and other value of the falcon drive. That’s strange.