Skip to content

Project Ideas

Jump to bottom
James Hagborg edited this page Jan 9, 2018 · 4 revisions

During the build season, programmers often have down-time, when the code for the robot is outlined, but a physical robot is still weeks away. This is a great time for students to experiment with new ideas. These could either enhance our abilities, or make the programming/testing workflow more efficient. More importantly, students can learn a lot from digging deeper into a particular part of the code. Here are some ideas for projects to work on.

Generic Subsystems

Nearly every year, we have some sort of lifter or arm, that needs to move to a set of fixed positions. This consists of a motor and an encoder. For example, in Recycle Rush, we had both a tote lifter and container lifter that worked this way. In Stronghold, we had a shooter that could tilt up and down, as well as a bar that could tilt up and down. The 2018 game will likely have something like this, either for manipulating power cubes or for climbing. It would be nice if we had a generic class we could extend for such subsystems.

Work on this project could procede as follows:

  1. Look through previous years code, to see what features are common to multiple years' robots. Decide on what use-cases your class should cover (e.g. should you be able to use a potentiometer instead of an encoder?), and what features it should provide.
  2. Based on what you decided in step 1, write down a list of public/protecteced methods that your class will provide.
  3. Create a new branch in hyperLib and write an implementation for your class.
  4. Test your class with previous years' robots. The 2016 bot is already set up to use HYPERLib, so you can modify that code directly. For the 2015 bot, you should just clone the quickstart project and work from there.
  5. If any problems arose in step 4, consider redesigning your class to make it easier to use.
  6. If everything works well, show an adult, and we can merge your code into the master branch of hyperLib.

Better Preferences System

This is a more advanced project, that would probably involve working closely with an adult. In fact, it's actually two projects, but work on one will probably affect the other.

Store preferences in one place

Right now, preferences get stored in a few places:

  1. In the code, we store default values for all preferences.
  2. On the robot, the file preferences.ini stores the current values of preferences.
  3. At various times, we make backup files of the preferences file, and store this in various places.
  4. Occasionally, we will manually go back in the code and set the default values to the actual values.

This workflow is less than optimal, to say the least. To see why, check out the desktop on laptop #3 or #4. It's completely covered in files like preferences.ini-backup-7--before-competition. Really, preferences should be stored with the code. This solves three problems at once:

  1. We can use Git to track changes to preferences, so there's no need to do so many manual backups.
  2. Changing out the roboRIO should be seamless, since the preferences should be deployed along with the code.
  3. There's no need to specify defaults in the code, since the preferences are already stored with the code. At compile/deploy time, we can have a script check that all the preferences are there.

A solution to this would mostly involve writing scripts to run at deploy time, to reconcile changes that happened on the robot and to the code, since the last deploy. We would need to think about how to keep track of which values changed where, and how to decide which values to keep.

To check everything is consistent at build time, we might need to change how we use preferences in the code, to make things easier for a compile-time script to check. Otherwise, we can check at run-time. Of course, catching errors earlier is always nice, especially when time with the robot is scarce.

Hierarchical Prefernces

Last year, we had a lot of preferences. Many of them have names like GearDrive VisionMove P. Really, we want this to be something like GearDrive/VisionMove/P, where preferences can be stored in a system of sub-preferences. Both HYPERLib and NetworkTables are already set up to do this. The main thing that needs to change is that we need a better UI to edit preferences. This could be just a change in workflow (try using OutlineViewer!), or it could involve coding a plugin for the dashboard. Having the knowledge of how to code a dashboard plugin would be very useful, even if it's not needed here.

Clone this wiki locally