Team 3015 Ranger Robotics: Auto-Nav Challenge Update (21.5s)

Managed to shave off enough time to get the high score back for now. Can’t wait to see what’s possible when everyone else submits!

21 Likes

This is FAST!

6 Likes

RIP non-swerve teams.

18 Likes

Rip all the teams that see this and think they “need” swerve once we are back to in-person comps.

8 Likes

Swerve is a lot more achievable than it’s ever been. We have the Thrifty Swerve still in boxes, and will be playing with it in the off season and will consider using it if we can get it to work perfectly by, say, November, and then abuse it a bunch to make sure we’re very happy with it.

And if we can’t get it to work perfectly in the off-season and then abuse it a bunch, we’ll go with a Falcon kitbot.

5 Likes

9 Likes

Why did you guys get rid of the orbiting technique around the markers. Did pure translation end up being faster? I was looking at 2910’s and your videos as a reference and in theory, I thought orbiting would minimize your turning radius. Did this prove to not be effective for some reason/why did you switch back to just translation? Thanks for the videos. Amazing work.

1 Like

You’re correct in that orbiting would have minimized the turning radius but after we sped up our velocity and acceleration the robot just couldn’t consistently rotate and maintain those speeds. As we increase the robot’s linear velocity, there is less time between waypoints for the robot to rotate to the desired heading, meaning we would need to turn faster. But as we turn faster, the maximum linear velocity of the robot is decreased. So basically, in order to maintain an orbit around the markers, we would have had to limit the velocity of the robot which would negate the gains from a tighter turn radius. We made the decision to just full send the robot as fast as possible and mostly ignore rotation.

1 Like

Oh right because of drive wheel normalization. Yes, this was one of my caveats from the beginning that kept me from doing the orbit. I always thought pure translation was fastest for that reason before.

1 Like

Yeah. Orbiting used to be faster for us only because we had available headroom in our max velocity to allow for it. After actually finding the limit of the robot and pushing towards that it was unfortunately not possible anymore.

1 Like

Cool, well thank you for the excellent proof of concept! definitely helped me come to some more conclusions and resolve some uncertainties on what’s fastest. Great job on your challenges!

1 Like

We had the exact same findings for our drivetrain. We were working on orbiting around the markers, but ended up backing away due to running out of linear velocity/acceleration to hold the path and rotate at the same time. Removing the attempt to orbit markers, and pushing the acceleration/linear velocity harder helped us drop AutoNav from around 27 seconds to 23. Optimizing our Galactic Search was also about finding the exact right balance of rotation vs. linear translation of the chassis without exceeding linear velocity max of any individual wheel.

1 Like

Yeah. I believe for your galactic search, you want to have a controlled rate for your heading control that makes it so that your robot arrives at the desired heading at the exact moment you need it to be at that heading. it will prevent the rotation from just suddenly snapping to that heading and unnecessarily robbing from your max linear speed.

TLDR onwards; sorry in advance

@mjansen4857 just a quick follow-up question about your path generator: what is the most efficient output file type for Java (or would it be the Java array for whatever reason? I would imagine this being the slowest right?). And do you have any examples of the most efficient ways to read those files? (i.e. is it better to load the file in the code and read the numbers on the fly while executing the trajectory, or should you read the entire file during the robot initialization and store it in some HolonomicTrajectory object? If it is the latter, could you provide some insight or is there already code for reading the file and parsing it into this object?). Sorry for so many questions. It just seems like really good code.

1 Like

We output it as a CSV file into the robot code deploy directory and then read these files during initialization. This is handled by a class made to feel similar to the WPIlib trajectory stuff (such as sampling a point at a given time) but can handle swerve rotation better and load these files. We don’t really care about efficiency since its done at initialization but I think CSV is a better option since it’s more organized than a class full of massive arrays.

Here’s the method in the SwervePath class that creates a path object from a given CSV file:

public static SwervePath fromCSV(String filename) {
        SwervePath traj = new SwervePath();

        try (BufferedReader br = new BufferedReader(new FileReader(new File(Filesystem.getDeployDirectory(), "paths/" + filename + ".csv")))) {
            String line = "";
            while ((line = br.readLine()) != null) {
                String[] point = line.split(",");

                double pos = Double.parseDouble(point[0]);
                double vel = Double.parseDouble(point[1]);
                double acc = Double.parseDouble(point[2]);
                double heading = Double.parseDouble(point[3]);
                double rotation = Double.parseDouble(point[4]);

                traj.states.add(new State(pos, Rotation2d.fromDegrees(heading), vel, acc, Rotation2d.fromDegrees(rotation), (traj.numStates() + 1) * TIME_STEP));
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return traj;
    }

The SwervePath class basically just stores a list of States (all of the info from one line in the CSV file) and can interpolate between data points to give our goal at any point in time.