Hello, world! My name is Christian and I’m a mentor for Team 4206 the Robo Vikes. I didn’t want to release this into the wild until I felt it was good and dang ready.
Introducing Battleaid
Battleaid is an open-source package and guide containing utilities for FRC Java projects. It’s goals are to speed up development, increase competitive caliber, and most importantly provide learning opportunities for students.
This project is in active development, but I’m the only contributor, so progress is slow and methodical. I’m open to other teams contributing to this project.
DISCLAIMER: I don’t own the domain name org.team4206, but I would like to eventually.
This looks really really really cool! I would absolutely love to help contribute on this. Super small question, about the configuration article, what benefit have you guys found in using configuration files over say, NetworkTables?
@mathum I would love for another contributor! You’ll need a GitHub account. Send me an email and we can coordinate to get you setup: [email protected]
Your question is fair. How is Battleaid not just re-inventing the wheel? A couple things:
It uses TOML.
It’s lightweight. The only performance hit is program initialization time.
It increases flexibility that some things in Constants.java would benefit from. CAN IDs are a good example (say you swap a motor and need to quickly update the CAN ID).
It automates work. Definition is once in the code. Assignment is once in the config file. LoadableConfig makes the in between step of initialization transparent.
OK. I see how you could use this for stuff that tunables could not be used for, eg stuff that starts once at initialization and needs to be accurate at initialization. I guess the benefit from this would be you get to skip the build time of your robot code, but in my experience that is usually less than 20 seconds. I do guess it is an approach worth sharing.
One thing though: I think you’ll want to scale the joysticks differently. Many joysticks have “round” limits, i.e. if you push the stick to 45 degrees, you don’t get an output of 1.0 on x and 1.0 on y, you get something less, e.g. here’s a rough response envelope for a Logitech F310:
So if you apply expo “tuning” separately to x and y, you’ll get a very strange response shape.
A quick way to deal with it is to convert to polar coordinates and tune the “r” part, and then convert back.
Thanks for the insight and the diagrams! I am aware of the circular bounds of the joysticks; we have an internal write-up on squaring the circle. I think the fundamental point you are making is that I will have a more consistent curve if I change to polar coordinates instead, which, as your second diagram shows, is true. I will probably roll-out that change in the next version.
As promised, I fixed the implementation of the joystick software to use polar coordinates instead of independently treating X and Y. However, because a single call is relatively expensive (in my opinion, see the code), I decided to to add a periodicity to the computation. The periodicity is customizable but defaults to the same period as CommandScheduler, which is 20ms.
The periodicity for the left and right sticks are not coupled.
re: the periodicity, i agree that doing the tuning twice (once when fetching x, once when fetching y) seems silly, but you could fix that by returning a pair. also note that the “atan” is the slow function (by maybe a factor of 50?), but you don’t really need it, or the sin/cos either. you really just want to scale x and y by the same amount, so you can just multiply them.
Sorry, I’m a bit confused now, why would you not need the atan/cos/sin computations? I don’t know how else you would convert from cartesian coordinates to polar and then back. If there is a better way please enlighten me.
The reason for maintaining the interfaces (i.e. controller.getLeftX()), and thus for not returning a pair of values, is because they match the interfaces used by generated swerve code. (I shadow the coordinates with class fields). This makes using the TunedJoystick as seamless as possible in our codebase. (I don’t want my kids to have to overthink using what I’m giving them)
re atan, I think the key is that your polar tuning only changes r, which means that it’s changing x and y by the same fraction, to keep the angle the same. maybe think of the “similar triangle” formed by the output of the tuning.
