Team 5225A In The Zone Code Release (yes you read that right)

#1

Hello world,

It’s been a while since we released our position tracking document back in October. In the meantime we’ve received a lot of feedback from the VEX community; one thing that we’ve heard a few times, especially, is that while teams understand our reasons for not releasing our entire codebase at the time, they are really interested in seeing at least some of our code, so that they can get a more concrete understanding of what we’re talking about. So, we’re going to do that today; attached is a link to our (now public) GitHub repository from that season. Our goal is not to release a ready-for-use library that you can directly use on your robot. Rather, it is to provide an educational resource to the community. We hope you all find it interesting; feel free to ask any question you may have in this thread, by email, by Discord, etc.

There are a few things that I’d like to make clear about this code. In particular, there are a lot of things not great about the way this code is structured. Some of these are workarounds for ROBOTC’s limitations, some are due to us not realizing there was a better way, and some are me not commenting anything for no apparent reason. Feel free to take inspiration from our code but don’t take this release as us endorsing bad code practices :smile:

Without further ado: https://github.com/nickmertin/5225A-2017-2018

38 Likes
Three Encoder Skid Steer Model
Student-Centered Policy Document
#2

All I can say is Thanks. It is great when teams decide to share their work with the rest of the community.

6 Likes
#3

Wow thats awesome of yall to do Nick.

5 Likes
#4

dayum. thanks so much. quick question for a vex newbie : I see all the files and stuff, but how do you actually input them into robotc and such. Thanks!

2 Likes
#5

For another time, I’d recommend learning how to use the Git version control system. For now, if you want to get a copy of the code, click “Clone or download”, then “Download ZIP”. Once you extract all of the files (or at least all of src), src/main.c is the file you want to open in ROBOTC. To look at any of the other files, find the #include line and right-click; there will be an option to view that file.

3 Likes
#6

God has joined the server.

On a more serious note, this is really epic on what you guys did. Great job to you guys.

4 Likes
#7

… Thank you for releasing this. This is gonna be an interesting season.

4 Likes
#8

awesome! I’m going to have to give this a thorough read.
for fun you should’ve made the title read (yes you that read right)

5 Likes
#9

All you had to say was “the code’s out” and everyone knows what’s up.

4 Likes
#10

I’ve been asked about the curves for drive throttle and turn. No, red and blue don’t refer to alliances, they refer to the two curves on this graph, which I shared with the drivers. The LCD interface allowed them to choose between the curves and tune the parameter on-field if they wished.

7 Likes
#11

And just like that, Vex Autons just leveled up for everyone! Thank you for this code release, it will really help this year.

3 Likes
#12

I’ve been asked about how to tune the input constants for position tracking. It’s very difficult to come up with precise enough values by physically measuring; wheel surfaces squish and aren’t flat, and wheels have a finite thickness which means that their separation isn’t an infinitely precise value. These facts make the wheels difficult to model.

Here’s what we did to tune our constants:

  1. Approximate the constants by measuring
  2. Push the robot forward a known distance, and use this to tune the wheel radius (or diameter) constant
  3. Turn the robot a known amount (i.e. some multiple of 360), and use this to tune the wheel distance constants

Note that we just assumed that the distance-to-left and distance-to-right constants were the same, because that was the intention of our design; if your tracking wheel system is symmetric as well, you can assume this too. Also note the order that we tuned the constants in; measuring distance travelled without rotation depends only on the wheel radius, while measuring rotation depends on both the wheel radius and the wheel position.

For tuning constants, the key value that you need to calculate is the ratio between what you expected to get (i.e. the distance or angle that you know the robot moved) versus what the tracking system reported. Test, calculate the ratio, adjust the constant based on the ratio, and repeat.

For the wheel radius, adjust the constant by multiplying by the ratio \frac{expected}{actual}; for the wheel distance, multiply by the ratio \frac{actual}{expected}. This inversion is due to how the constants effect the interpretation of the data: increasing the wheel radius constant will make the robot appear to have driven further, while increasing the wheel distance constant will make the robot appear to have turned less.

After a handful of iterations you’ll converge on a value that works well.

14 Likes
#13

Thank you for such a great code release!

Is this the same code that your tracking document talks about: Team 5225 Introduction to Position Tracking Document ?

Will this work with V5? Because your tracking mechanism was using V4:

2 Likes
#14

Just a little something, people usually don’t like to revive old threads.

Also, you would have to convert the code to c/c++ b/c the 5225a code (I’m pretty sure) was written in robotc.

#15

Correct, the algorithm described in the position tracking document was used in that code (the actual code for the tracking algorithm is in src/auto.c if you’re interested). @qwerty2 is correct that it is written in RobotC, and as we explicitly said, we’re not expecting anyone to be able to copy/paste the code and use it. Instead, we released the code so that anyone who’s interested can use it as reference and see how the features we made and used in competition were actually implemented.

Note: I think it’s fine to ask on this thread, because this is a question that’s directly about this code release.

5 Likes