The documentation has been a great help in getting RoadRunner up an running quickly, but the most annoying part is having to constantly switch between the robot's wifi and the internet so that I can look at the next section. It's not a super huge issue, but it is just a bit aggravating having to switch to a network that has internet access to see the next section and then switch back to the robot's wifi so I can change the constants and whatnot.

I'm not super sure if it is possible or how possible it is, but I would recommend somehow making the page a progressive web app or single page application.

I think having a PWA would probably be easier because all you really need, I think, is a manifest.json file that explains the files that need to be downloaded for offline access. Then, it would also be able to be downloaded as if it were a regular program (although I believe this can be disabled), but most importantly it would enable the entire site to be accessed while offline, so it wouldn't matter if one is on the robot wifi or connected to the internet.

Using a SPA would work as well, but I'm not sure how well it would fit into your current stack. Essentially, from what I know, the page is loaded initially with all of the pages it needs and just displays those pages when needed. So, instead of using multiple pages, it is essentially just one page that has everything it needs in memory. This way, once you load the page initially, you can access the entire website so long as it is in memory.

I would be willing to assist in bringing this into fruition, but again I'm not super duper familiar with the stack.

no
trajectories all maintain trapezoidal motion profiles
they will accelerate from zero back down to zero velocity (edited)
roadrunner does not support asymmetric motion profiles

Step 12 of https://learnroadrunner.com/follower-pid-tuning.html recommends setting kD to 1 to keep pose velocity constant across battery charges. In our team's experience (using feedforward) this caused the robot to severely oscillate and never fully reach the target, and setting it to 0 immediately made it smooth.

There's definitely a potential that we were doing something wrong, but maybe the potential consequences of this should be explained in the step or the instruction notes? Maybe a mention that the numbers you have are just approximate and will be different for different robots would be good too.

Thanks for making such a detailed guide! I think a lot of our robot's success in scrimmages so far has been because of what I've learned from your site.

Needs confirmation

Heno raised that only parallel y and perp x will have effect on kinematics
https://learnroadrunner.com/dead-wheels.html#two-wheel-odometry

• Drive constants auto-generator
• on the FF page

Can dark mode be added or do I not see the option to enable it on the site?
It would be very pleasing on the eyes.

https://www.learnroadrunner.com/dead-wheels.html#set-localizer-in-samplemecanumdrive

In this section it says to set the localizer with the following line:

setLocalizer(new TwoWheelTrackingLocalizer(hardwareMap));

However the constructor for TwoWheelTrackingLocalizer() requires two arguments:

public TwoWheelTrackingLocalizer(HardwareMap hardwareMap, SampleMecanumDrive drive)

One issue I have been seeing quite a lot is where people are using their robot's theoretical maximum velocity and acceleration values for their initial tuning, even when they almost definitely shouldn't be.

This is a problem since there is no clear note that the values given either by the maximum velocity tuner or just calculations are just metrics of the highest values that should be used, rather than the recommended values one should start with.

Views vary as to a good starting point for one's initial tuning of roadrunner, but in my opinion, drive encoder users should start at 30-35 in/sec and dead wheels users 30-40 in/sec, with 180-270 deg/sec for angular. Regardless of what is considered a good starting point, however, I don't believe it is contested that one should not start with values like 50-60 in/sec for their very first tuning, not to mention that almost all autos do not need this high of a speed to complete in time (our 1+5 auto this season only uses 40 for velocity and 43 for acceleration), and any faster movement negatively affects localization performance.

All of this applies to the constraints for angular velocity and angular acceleration as well, where the guide suggests that the values returned by the tuner should be used as the constraints, which again leads to users running much higher constraints than they need or is advisable, negatively affecting localization performance.

What do I think is needed here? I think that first of all, the wording on the velocity PID and feedforward pages, including the other places constraints are mentioned, should be re-written to include a few key points:

• Users probably shouldn't use the maximum theoretical velocity to initially tune roadrunner. The values returned by the maximum angular/regular tuners are metrics of the maximum advisable constraints, not the recommended ones.
• There are very few situations where the maximum possible speed is ever needed. There are often other limiting factors such as mechanism speed that will prevent running faster.
• The faster your drive base moves, the faster your localization will drift in most cases, especially for odometry-based systems. In particular, drive encoder users need to carefully limit their movements and speeds to avoid drift.
• Dead wheels are not immune to drift either, and going slower is almost always better for consistency.

(All of these points apply to the angular constraints as well)

Another great place to put a small warning would be in the Drive Constants file returned by the configuration tool on LRR, above the fields for velocity and acceleration. This will be seen every time a change is made to the constraints by new users and is harder to miss than a note on the website.

These are just my thoughts for changes to solve one of the issues I've seen from people seeking assistance so far this season, whether it be from velocity tuning issues caused by constraints being too high or otherwise. At this point in RoadRunner's life, there are many more newer and perhaps less experienced teams who are attempting to tune their drive bases, and as such it may be a good idea to start distributing some of the advice previously given through community platforms (Reddit, Discord) to this guide, since it is clear it that this is a very common problem.

This image that was sourced from FRC team 1712 references a proportional velocity gain. This is not something present in roadrunner. Should we modify this graphic not to include that step? it would be as simple as cropping the top.

Isn't the value for Forward Offset in the three wheel odometry section supposed to be the distance from the center of rotation vs the distance from the left and right wheels?

"Generally you want to tune things one at a time
And tuning road runner comes down to three parts:
Tuning the localizer
Tuning the movement
Tuning the follower"

Via TheConverseEngineer#7565 on the FTC Discord
https://discord.com/channels/225450307654647808/1018999812852547594/1019003174301999167

You want something like https://gist.github.com/henopied/4f1a8bf2f287eaa6ac52c549e034b672 to prevent the localizer from eating encoder readings. Setting the pose estimate resets the localizer, including the last encoder positions. It needs an extra iteration to set those positions and start computing deltas again.

• the second biggest road runner debugging tip is slow down and see if your problem is solved
• if increasing kp doesn't do anything but create oscillations, ease up on your constraints
• the biggest step to becoming an effective rr debugger is understanding that localization is (pretty much) independent of feedforward

Some encoders need to be flipped

Unfortunately, I cannot contribute directly to this since I am not familiar with the program you are using to generate your site (tailwind?). However, I can point out that the edit links are linking to the root repository, but they should actually be linking to the /docs/ folder. Just thought I'd point it out 👍

Add the rev ultraplanetary motors to the drive constants generator.

Due to drift/whatever, we may be inches off where we want to be over the 30 seconds of autonomous. We would like to explore doing re-localization using April Tags.

Options - i.e., looking for the best way to do this...

1. Use a marker. Call a function to read AT. Use that Pose2d our function found to (re)set the current robot location. Problem - I don't think you can do this during a running trajectory sequence. ???
2. Run traj sequence A. Stop. Read AT. Create and build a new trajectory sequence starting from the Pose2D per AT. Great! But takes quite a while to build a trajectory.
3. Other ways?

Thanks!

https://discord.com/channels/225450307654647808/225451520911605765/1065294649356472330

We want to move the robot forward to pick up an element/game piece and then stop when a switch is activated (indicating the part is in contact) ...and then move onto another trajectory. Can you stop a trajectory in the middle when a switch is hit?

In the Three Wheel Odometry section there is nothing that indicates you should set the pose of all three wheels.

https://learnroadrunner.com/dead-wheels.html#three-wheel-odometry

In particular, the Java snippet here would be a useful addition...

Image stolen from https://acme-robotics.gitbook.io/road-runner/tour/kinematics

If one does not do that, and only specifies lateral and forward distance, but not the Y-axis values then the robot will drift when running the lateral distance tuner, and display other, generally undesirable traits.

In your documentation it says to add the X and Y multipliers in the getWheelPositions(), but in your example it show it in the getWheelPositions() and the getWheelVelocities(). Which is right ?

When doing the final tuning, if one is using a tank drive, then the PID values for tuning are different and there is no documentation for these values in either the original road runner quickstart source, or the quite awesome learnroadrunner documentation.

    public static PIDCoefficients AXIAL_PID = new PIDCoefficients(0, 0, 0);
    public static PIDCoefficients CROSS_TRACK_PID = new PIDCoefficients(0, 0, 0);
    public static PIDCoefficients HEADING_PID = new PIDCoefficients(0, 0, 0);

I was installing Road Runner onto our project using the "Method 2: Installing RR on Your Project" instructions present learnroadrunner.com, but I ran into an issue with "com.fasterxml.jackson" packages not being able to be imported in several files. This was becuase implementation 'com.fasterxml.jackson.core:jackson-databind:2.12.7' should have been added as one of the dependencies in the build.gradle file for TeamCode. However, this was not specified from the instructions. Rather, it only said to add 'org.apache.commons:commons-math3:3.6.1' and 'com.acmerobotics.roadrunner:core:0.5.5'. The quickstart repository has the jackson-databind dependency, so there is some mismatch between the documentation and the quickstart repository.

While running the code exactly as is provided on https://learnroadrunner.com/trajectories.html#set-pose-estimate for trajectories, I get an EmptyPathSegmentException. The only solution is to remove the traj1.end() argument but then the trajectory isn't the desired one.

Is there a timeline on when a similar product to this for version 1.0.x would be created?

vector embedding w/gpt3?