Our programmers are doing well with using Pathfinder. What is the best way to generate paths to drive backwards? We are thinking about virtually flipping front and back, along with left and right. But you still have fyi to deal with gyro and encoders being wrong. I’m sure I’m not the first to try to solve this.
Thanks,
Brian
Flipping left and right as well as adding a negative to the position, vel, accel, jerk, and heading is a workable solution (albeit a band-aid one)
Is it hard to flip the gyro and encoder? In our code it would look like this
pathfinderHeading=myGyro.getheading*-1;
leftTalonWithEncoder.setInverted(TRUE);
We had issues at our last event with the heading starting at 180 when we wanted angle of 0, we arent sure why because we flipped encoders, l, and r. Which seems to be what others are doing.
If I wanted to concatenate two trajectory files into one file. We have separate files since some are backwards paths. If I get the final position (Pf) from the previous file and add that to all positions in the next file, that should be all I need to do, right?
Just about, we got this working the other day.
What we do is do the first path normally going forward, then when we want to go backwards next starting from the same spot the last path ended, you set the first point as the same, then your next points can be whereever you want. For backwards movement, we had to reset the encoders every path because when going backwards your ticks will decrease instead of just going negative, you could also find the offset ticks from where you sarted. Along with that we had to inverse motor power, and switch l and r to give the opposite side power. Lastly we added 180* to our NavX angle because when you make a path that you think is going backwards, the pathfinder just thinks you are facing 180* of where you really are.
We’ve got just-barely-tested java code to do it this year with FalconPathPlanner. PM me if you would like details!
Quick answer we took:
–Mirror waypoints across the origin prior to sending to pathplanner.
–Invert desired motor velocity commands before sending to motors.
If doing gyro compensation, do NOT invert desired heading or gyro - these still work as intended. I think.
In the event that I needed to connect two direction documents into one record. We have separate documents since some are in reverse ways. In the event that I get the last position (Pf) from the past document and add that to all situations in the following record, that ought to be all I have to do, correct?
Yes, though you don’t necessarily need to do this. All paths are self-contained, where a path like (0, 0) to (10, 0) will be ran the same way as (10, 20) to (20, 20).
It can be easier to do paths individually by doing paths that all start at (0, 0) rather than adding coordinates for all subsequent parts, as making minor adjustments for each individual path would be easier to determine mentally. Our team originally tried having a global coordinate system like what PathWeaver does this year, but quickly moved away from this due to having to adjust our paths constantly.