In previous years we haven’t really done much for the autonomous period of the game, so this year we are planning on using Path Weaver to move the robot to the scoring tower and are looking into using some different sensors to increase the data that we can use for navigation.
We attempted to follow this tutorial for setting it up on the WPILib website. When we put the code into Visual Studio Code, however, the project would no longer build even though there were no errors. Getting Path Weaver working will be the big project after exams.
A new thing that we are planning on using this year is a limelight. (There is reflective tape around the shooting target that makes a square on the limelight camera). Then we should be able to use the camera during autonomous period and throughout the game for increased accuracy versus lining the robot up manually. We have been looking through WPILib for different things that we can implement with the robot. There is so much that we can do, it is just a matter of figuring out how to do it and taking the time.
The 2020 FRC game is out now, with this video giving a pretty good explanation of the game mechanics, as well as showing what the new field looks like. Put simply, each team can score points by getting balls from the field and placing them in a tower, with additional ones given for hanging the robot in the air from a bar at the end of the match. Even more points can be scored by leveling the same bar with an additional robot.
So we have been meeting every day of the week after school, excitedly preparing. We were generally split into three teams. One group building a prototype robot, another working on the business aspects of the project, and some on the coding portions.
We’ve been using Visual Studio Code (the preferred IDE used to be Eclipse) and have been diving into Java to try and learn how to automate portions of our robot.
The WPILib API has some methods for using speed controllers (Spark Max motor controllers), but we haven’t yet figured out the appropriate way to turn them a certain number of rotations with our current hardware. A potential method surfaced in the Rev Robotics API with some mentions on how to measure total rotations, but it wasn’t immediately obvious on how to actually set the motor to move only one.
We’ve also looked at moving them a certain distance by setting a maximum duration that they would be powered for. While we’ve attempted this in the past during the autonomous period at the beginning of the game, the biggest problem with this approach is the potential for network packet loss or wattage differences during game play. It doesn’t seem like anything very specific, like picking up a ball, lifting it to a certain height, and placing it in a bucket could be accomplished using this method.
Currently when driving manually we have to be very careful and precise, whereas if the appropriate program is setup, a series of events could be accomplished with the press of a single button. So we are still actively working on learning to code and are experimenting with various approaches.
It took a while, but after realizing that the site was going a little slow we researched a few ways to increase the performance.
It turns out that after converting the images to WebP and setting up the appropriate fallback tags so that browsers that do not support this next generation format still render, the performance tests jumped way up from their much lower score.