You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We discovered this during IAP and had students remove the trapezoidal velocity filter. Command shaping should be done in the node that generates the command so that the node can properly model it.
I disagree. The VESC should have a max_acceleration that it can handle and it should obey it regardless of whether the user specifies it or not. Otherwise, bad behavior happens. For example, I've seen the VESC give up during braking and allow a car to coast into a wall at full speed because the VESC driver did not obey its own limits.
If the user wants to model the acceleration using Odom or a mathematical model, that's ok. But that should not be a prereq for having repeatable braking behavior.
Is vesc is commanded to zero velocity and "gives up", then that issue should be directly diagnosed and addressed rather than creating a command shaper to mask the underelying problem.
I found similar problem. When the car is running at about 15mph, I have problem to stop immediately. It will slow down but continue rolling. What configure should I change?
Because stopping right now is really slow. Probably because the RPMs are hitting some max.
Alternatively, apply different gain on accel and deccel.
The text was updated successfully, but these errors were encountered: