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
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!
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.
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.
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:
Approximate the constants by measuring
Push the robot forward a known distance, and use this to tune the wheel radius (or diameter) constant
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.
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). @64540A 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.
