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.

Do something useful with diagrams

Right now, HYPERLib automatically generates diagrams for the OI and for wiring on every build. We should be able to do something useful with this information, like putting it on a website that the whole team (or at least electrical/pit crew/drive team) knows about. Of the two, I would say the OI Map is more interesting/important, since it changes more frequently, and because the technology involved in the solution would be more useful to learn.

Wiring Diagrams

On every commit to master, an updated diagram should be uploaded to some website that pit crew and electrical know about. This will probably be triggered via TravisCI. Ask James or Chris about how to do this. The most important part of this task is to communicate clearly with other parts of the team, so

OI Map

Develop a plugin for the dashboard that displays this info for drivers. This would mean publishing data about how the controls are layed out over NetworkTables, and writing a plugin for the dashboard to take advantage of it. This involves learning about how to work with the OI class (ask James!), how to work with NetworkTables (also ask James, or Google), and how to write a plugin for the dashboard (nobody's done it yet, but that's because nobody has tried).

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