Order of coding Odom and PID

Odom first, then PID or the other way around? Am bit confused on how to do that

Also bonus question - Can I use the values I get from odom on absolute position and use that to automatically adjust the speed of the flywheel depending on distance from the goal?

Generally one would do odometry before pid

To answer your bonus question you can convert odometry values into a usable firing salutation for your flywheel however this information usually becomes inaccurate during driver control

Id recommend an active sensor such as a vison or range finder for such an application

4 Likes

[DISCLAIMER: I have not personally done odometry in the past, but I plan on working on it this year. ]

Odom and PID are two separate things. Teams who use odometry often use the values from it for the error portion of the PID*, but the PID controller does not care where it gets it’s inputs from. A constant value works just as well, it is just not as precise or adaptive.

*Odometry is just a type of position tracking, and as such you can’t just input the values from odom into the PID, you need a motion control algorithm (pure purse, RAMSETE, etc; look these up on the forum) to actually use the information the odometry program provides.

If PID or odometry is new to you, I would start with the thing you know, and experiment with the one you don’t. If both are new, try out PID first. If you know both, implement odom and try out motion control algorithms.

As for your bonus question, there is nothing stopping you, so go for it. I think a lot of teams will do this, or something similar.

I do not know what your experience has been with odometry, but with good quality tracking wheels and under-control driving, I would think your position would still be accurate enough.

The v5 distance sensor only has a max range of about 6.5 feet, and the ultrasonic rangefinder has a max range of about 9.5 feet (numbers per their product pages), although I doubt they would be precise enough at that range to be up for the task. In my experience with the vision sensor, I do not think it would be accurate enough for a targeting script, but I would love to be proven wrong.

6 Likes

The inaccuracies come from the other 3 robots bumping into you and knocking you which can throw off the tracking wheels/IMU for both 2 wheel and 3 wheel setups

Ive had pretty good range finding results with the vison sensor +1/-1 inch the main problem ive experienced comes with inconsistent lighting throughing off your color calibration

Could I use a GPS sensor to find out position and adjust the velocity of the shot?
Can you explain more how you use the range finder for this application?

Gps would work during skills but the gps strips arnt usually up during elimination/qualifying matches

With the v5 distance sensor,
Just point it in the in the direction of the goal and you get an accurate reading up to 80 inches

An ultrasonic range finder would work too as it has a slightly higher range

1 Like

As long as you have a method of determining position, it does not matter what you use (ex. GPS sensor or tracking wheel odom). Once you know the robot’s position, you can calculate its distance from the goal and calculate the desired flywheel speed.

You can use kinematics equations to determine this. Luckily, @TheRichDarth made a lovely tool for calculating this here. You can apply the equations in your code to find flywheel RPM based on the distance from the goal.