Robot quits during trajectory finding

We were trying to do our own code but that wasn’t working. We then tried the template but to no avail. The robot keeps quiting.
GitHub here:

What error are you getting? Can you copy/paste it with the message and stack trace?

It’s probably not the cause of your crash, but I do see one error in the method where you update odometry. You are giving only the right position to the update method. You need to give the right and left sides separately, otherwise the position of the robot cannot be tracked accurately, especially while you’re turning.

I didn’t catch that. I’ll try; log file plus Rio log.


Your repo only has your subsystem and the error is being thrown from RobotContainer. In any case, it looks like it’s failing to generate the trajectory when you call TrajectoryGenerator.generateTrajectory(). In my experience, “Something went wrong” is a (terribly worded) error that occurs when the generator can’t make sense of your trajectory. Maybe it can’t figure out how to drive the path within the constraints, or the waypoints are too close together.
I’d suggest trying different waypoints and verifying your constraints and trajectory config. Take a look at the Troubleshooting doc

https://www.twilio.com/blog/how-to-read-and-understand-a-java-stacktrace

What’s on RobotContainer.java, line 108? What conditions cause the code to hit there?

I understand the file is usually autogenerated. This could imply that the solution is not in editing the file, but in changing the inputs to how it is generated.

I’ll have to check but it didn’t throw the error when I used integers. When I changed to doubles (we didn’t have space) it started throwing errors.

I think I’m misunderstanding you (doubles have same as or more bits than ints), but fair enough. Let us know when you’ve dug into the code.

From the stacktrace, I’d say it’s the getAutonomousCommand() method, and it has a call to TrajectoryGenerator.generateTrajectory() that’s throwing “Something went wrong”.

1 Like

Yeah, the only thing i changed from the template “ramsetecontroller” were the interior way points. It was like (1,1) (-2,1) and then ended at 3 meters and no rotation. I changed it to (0.5,0.5)(-1.0,0.5) and end at 1.5 meters.

In other words, no space to run a path with integer waypoints.

Running out of physical space

Thanks, I understand “no-space” now. I usually call that “not enough precision”, but the meaning makes sense now.

I should read my own tutorial more thoroughly. I do think some of the messages are getting interleaved.

None the less: here’s what I believe to be the culprit line of code.

It looks like your trajectory managed to hit the case where the current state’s acceleration and velocity were smaller than a very small limit…


Here’s Line 108

And I don’t know why you call it not enough precision… I’m literally confined to a 2x2 space in between tables in our lab. I actually don’t have room to move around very much.

Also I think that may be the problem. I didn’t create a left encoder distance so I passed both the params the right distance. It should have been able to calculate the velocity even if I gave the same number left and right, though.

My thought process (specifically on why one switches from integer to floating point representations of waypoints):

Integers can only express waypoints in single-unit (meter, in your case) precision. No half meters, just single full meters.

Floating point numbers increase the precision to be able to describe fractional meter waypoints.

Hence, to me, I see the change of variable type as driven by a need for additional precision in describing where waypoints are at. That need for precision is driven indirectly by the desire to constrain the robot to a smaller physical space.

To explain the counter: If you had said “I have a path defined with integers that ends at (100,0) and need to reduce the size by half”, I’d think you could still do it with integers. It’s the fact you’re going from (3,0) and reducing by half that would require floating point.

Glad you have a suspected issue! I can’t speak a ton to the internals of the wpilib Path libraries, but most pathplanners have some “gotchas” when it comes to ensuring paths and configs define physically plausible maneuvers, and not all are great about annunciation exactly what the issue is.

If you could share your RobotContainer.java, that would be helpful. The only thing I could think of is if there was something up with your config. Side note: I was having some trouble with running RamseteCommand in WPILib after upgrading from 2020.1.2 to 2020.2.2 and although I haven’t had a chance to physically test it, it seems like it at least fixed the problem I was having in the simulator, so a full uninstall followed by a reinstall is always something you can try.

It’s the template but with .25 for the values

This is a problem with the voltage constraint, if you remove the DifferentialDriveVoltageConstraint your trajectory should generate without crashing.
The problem happens when a trajectory turns sharply at the start, so maybe you’ll have luck trying out different trajectories.
It should hopefully be fixed in the next wpilib release.

1 Like

So litteraly just remove .withconstraint()
?