How to code autonomous period

I’m trying to figure out how to code the autonomous period and I watched FRC 5190’s Zero to Trajectory Tracking video. However, that only covered the basic movements of the robot. How would I incorporate vision from let’s say limelight to make the bot line up with the target when it reaches a certain spot?

1 Like

Hi cerealbird! What kind of code do you have right now? It is typically easiest to give advice when I know a little bit more about the context of where you are at, but I can give some general guidance.

  1. If you have a limelight, they have really informative documentation on their website on how to API with their values through WPILib NetworkTables

  2. Depending on what framework you are using (TimedRobot, CommandBased, etc.) there are different ways of doing things so make sure you are using the framework you really want

  3. I would recommend writing utility methods to accomplish those basic movements (drivestraight, turn, etc.) and then using the vision data to generate calls to those methods to move the robot in a specific way

1 Like

I believe limelight has a lot of documentation which goes over that. The way it works is, once you reach your shooting position, you get the position of the target sent by the limelight and put it in a PID loop as the sensor input. You then set your set point for the loop to whatever value gets your robot at the appropriate angle to shoot.

For autonomous, you generally have a few options.

  1. Dead Reckoning - i.e. drive forward for 3 sec
  2. Path Traversal - i.e. PathWeaver or the new Trajectory Generation stuff
  3. Sensor Feedback - i.e. alignment by calculating error from sensors (vision, encoders, etc)

So, to make the transition you’re looking to make, you can run your path/trajectory code, then separate code for alignment once you’re “close enough”

In terms of “how” I would definitely first say that it depends a lot on which framework you guys are using. As for the technical part of actual programming, I would say use flags that track the “stages” of your autonomous code telling you when the distance is reached or when the robot is lined up. But like @Dylan_Watson said, there isn’t a solid path that I can tell you without knowing more about your plan and current code.

This is the GitHub code for our limelight Auto aim in auto our plan is is not to use this but we are using the back wall to line up parallel with the target so we have less aiming and more reliability

This is our proof of concept for teleop autoaim which you will find xoffset aim in which pivots the robot to aim until we are within margin of the target

the full limelight firing in limelight shooter group

we also adjust the wheel speed depending on how far we are from target

You could theoretically call this command whenever you need in your autonomous if you want

This command can not work alone, the limelight has to be reliably visible, if not it just fires at full speed so the plan for us is to use odometry to get the general direction of the target then use limelight to get the final few degrees of aiming

1 Like

I think your repo is private, the link does not work.

Tonight at about 6pm i will ask our chief in programming to make the repo public

Sorry I could not be of much more help

Its openscourced now so you should brake to look at it

Can confirm. I just made that repository public, so feel free to take a look

Thanks for the reply. We’re planning on using pathweaver with the RamseteController
for trajectory generation. We’re just not too sure how to incorporate a limelight control loop into the code.

I think you would use the limelight to estimate distance and angle to the target and generate a trajectory to get you where you need to go based on your current place in 3d space.

Thanks for sharing, you have lots of good stuff there. Off topic, but I poked around and your way of handling your sequencer sparked some ideas as well.

One warning, if you use while loops in your command you risk overrunning the 20ms control loop, especially since you’re waiting for the robot to physically move.

1 Like

Wait a second, your code isn’t updating xoffset or yoffset in the loop. Won’t it just get stuck in there unless you were already right on target? It reminds me of a programming joke:

A programmer was at the grocery store and his wife called him and said, “While you’re at the store, please pick up some eggs.” The programmer never came home.

Also, I don’t imagine moving your drivetrain right-to-left is going to help narrow the Y margin.

Lol, I should have mentioned that yoffset branch is the one that actually works master does not
The other branches spelling bee and the other one don’t work either I will merge yoffset with master when I get a chance tho

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