MalformedSplineExeption

Technical Programming
#1

We were following this guide for trajectory tracking. Initially we ran into some problems with a very jittery robot. It was trying to correct its heading too aggressively. It wasn’t the same jittery motion as some other teams posted as we were looking for help. I assume their problem might be not feeding the motor safety so it would just shut down the motors periodically. We sort of fixed the problem by playing around with the ramseteB value and the zeta value. We lowered B to 0.1 and increased zeta to 0.8. And it would run a meter straight fairly accurately. Once we were happy with the result we wanted to try a complex path. we tried to run a U-turn.

    List.of(
            new Pose2d(),
            new Pose2d(2, 0, new Rotation2d()),
            new Pose2d(2, -1, new Rotation2d(-90)),
            new Pose2d(0, -1, new Rotation2d(-180)));

Some iteration of the code above ran, but when it came to the turning it would slow down and simply stop running. We tried to do it differently and then we started getting the MalformedSplineException. We gave up on the U-turn test and tried to do the s-curve motion from that tutorial.

Trajectory exampleTrajectory = TrajectoryGenerator.generateTrajectory(
        // Start at the origin facing the +X direction
        new Pose2d(0, 0, new Rotation2d(0)),
        // Pass through these two interior waypoints, making an 's' curve path
        List.of(
            new Translation2d(1, 1),
            new Translation2d(2, -1)
        ),
        // End 3 meters straight ahead of where we started, facing forward
        new Pose2d(3, 0, new Rotation2d(0)),
        // Pass config
        config
    );

And we got the same error. I think its because we tried to simplify that getAutonomousCommand() method so we can pass in a trajectory in the method call, but I don’t know. you can view our code here.

#2

Apart from the trajectory issue (I’ll update this post when I get time to look at the code), I recommend you make all your units are in meters. Velocity in meters/s, distance in meters, acceleration in meters/s/s. If that is the case, you won’t have to touch the default Ramsete Controller values of 2.0, and 0.7 respectively. If the robot was jittery from the optimal P gain of robot characterization, then reduce that for both the pid controllers to 1, and start working up from there manually until you see the jitter again, and then reduce it by 10%. Test with a straight spline that doesn’t give you the exception for now.

1 Like
#3

I used the units class to convert to meters, I don’t know why we had to change the b and zeta value. I have this nagging feeling it might be the encoder edge conversion. When we ran 1m and then 2m it was pretty spot on. Like an inch or 2 off at most. But I have the actual tick count on display on shuffleboard and it keeps saying it’s 6-10 inches off.

#4

Make sure you use Rotation2d.fromDegrees() instead of just calling the constructor which I believe takes radians.

#5

Oh, that makes sense, when I used Rotation2d.fromDegrees() it didn’t throw me an error. But it was just slowed down and started turning super slow. And I made sure turning left would get a positive gyro reading.

#6

If we are using different units, should we change the Ramsete gains by the ratio of meters to those units, or is there some other process?

#7

When we used the characterization tool we set everything to meters so would it matter?

#8

As far as I know, it is highly recommended to use meters everywhere in the Java library. The Java API even assumes that everything is already in meters, so I recommend either using the Units class to convert from your unit to meters, or directly inputting everything in meters. (If you’re using c++, inline functions automatically convert the values for you I believe).

This means that when characterizing your robot, your wheel diameter must be in meters as well. If it wasn’t I recommend going back and re-doing it with meters absolutely everywhere. This solved 90% of the issues for us when we were initially getting it set up.

1 Like
#9

We may end up doing the same. Historically we’ve used the inch as our primary unit, given that the robot and the field are defined in US Customary Measurement units… but a working RAMSETE system might be worth the conversion.

#10

the problem is everything is in meters. I used the units class to convert either inches to meters, or feet to meters. As well as well as putting the wheel diameter in meters for the characterization tool. However I do have a question on which preset and controllers I should use. Should I use WPILIB 2020 or Talons preset since they are giving two different values.

#11

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.