Home

This document may help with understanding the code and the direction it will take long term.

Currently, all of the library code coexist with FRC, with some features commented out. It can build both from WPI tool chain compiler and VS2017 compiler, and is completely decoupled from OSG. This is the first time this has ever happened, while in the past it was two separate code bases and we had to manually transfer the code from the simulation to the robot. Also this is the first time it has been built in 64bit, so all of the pointer issues have been addressed.

TODO (point to design here)

One thing about the design is that it really makes use of inheritance, and over the years I've come to a realization of inheritance. That is that it forces objects to be tightly coupled together. So if used on a small scale this is fine, but in a large scale, aggregation and lambda's are starting to be the way to go. Lamda's were not available until 2015 once we switched from cRIO to roboRIO, and it took some extra time for us at work to have enough release branches to start allowing for c++11 features. When attempting to prune code for FRC2019, it became clear how tightly coupled the objects were, where I needed to put the whole environment on to be able to use particular objects.

My first goal is to work with the code here on this repository: The goal is to be able to build with WPI tool chain and VS2017 using the same code. I'll have to work-out how to make the robot and drive hot-swapable within the WPI build environment. I'll then enable the other features such as robot control, and the InOut code etc... so I can deploy the code to Curivator. After this I'll evaluate how to decouple the objects, by removing the inheritance and using lambda's instead of virtual methods.

There is a lot to be said about long term plans for the simulation side of things. A lot depends on what is available, and this may impact a new streamlined technique to do setpoint code. Simulation can go beyond helping for controls, it can also help for dynamics on virtualized prototyping for mechanical design. So I may look into something along these lines, first looking at auto desk. One thing I need to evaluate is if I want to change how localization works. I'll have a better idea of this as we move forward on the Curivator project. Basically localization is where the code keeps track of where the robot is on a virtualized world, and use sensors to ensure the virtual and real world are aligned. We intend to have Curivator be able to navigate down the halls at work and look for samples on the floor and pick them up, and then return to home all autonomously. In moving forward... decoupling the objects will make it possible to change how to implement localization. Localization is extremely useful in FRC to navigate a robot down a path to achieve goals to pickup objects or what have you.

Note: this is a live document... it will change to reflect the current state of the code.