aembot / frc_2018 Goto Github PK

Giving equal power to both motors will not necessarily result in equal rotation speed. this will apply everywhere.

We want to figure out how long the robot travels after releasing throttle. This will apply to autonomous.

If @DarthWunka finishes new drive by when this is being worked on create a baby mode for his drive (if not create an issue for that before marking this issue as complete).

Without requiring Internet.

Add all specified values to shuffleboard (or smartDashboard) and make a nice, easy-to-read layout. Create a new branch for this. It is stated where you can find chunks of code for each bullet point. Also test where shuffleboard stuff should be created to show up initially (and updated later in some instances).

Necessary on shuffleboard:

• Camera feed (already on board, may be commented out, in master branch)

• Auto selection sendable choosers (already on board, in master/clean-up and iterative branches, needs to be tested)

• Drive encoder strike integer (in iterative branch)

• PID values (for turning and driving, in any branch and in summer repo)

• Baby mode sendable chooser (in master/clean-up, needs to be tested)

Nice to have on shuffleboard

• Display real-time graphs

• Preferences (PID values and other values)

Leave space for the FRC Driver Station to sit on top or bottom. Save any viable layouts. Check this frequently as more requirements may be added. See @LizzyMilford for more information

Refrain from switching branches unless you know it's safe.
[UPDATE] I'll have this fixed by Saturday. As of 12:02 AM February 9th, it is safe to pull from master. Other branches need to be configured still.

If there is no way to easily record a few values from NetworkTable into a file, implement a simple moving average algorithm for the speed of each encoder inside the command itself and record that value. ONLY COLLECT DATA WITH THE ROBOT ON THE GROUND, ADD WEIGHT IF NECESSARY. Alex has the spreadsheet.

All the branches that aren't used for developing robot code should be merged into one, specifically:
Gamerverise-patch-1
bennyk
stealth

Test and see if the baby mode and auto selection features work with the shuffleboard. See @LizzyMilford for more information

And delete enums classes and folder in utilities

Look at the UltrasonicSensor class in hardware (very old, do not know if it was ever tested). Add any necessary/desired code; there must be a value filter to remove occasional unreasonable data that comes from the sensor. Will eventually test with the sensor. Do not start this without talking to @LizzyMilford as it is complex and low on the priority list.

There is an issue with what files should be on the git ignore and what files should be kept in the repo. 254 for example has the src folder and build.properties and build.xml

[OLD]
This repository is missing some build files and so when people switch to the branch, IntelliJ kinda breaks and doesn't know what libraries or what files are source files etc. When looking at frc-2017, there is build.xml, build.properties, and sysProps.xml in the parent directory. A good start to solving the issues would be to add the missing files to git, but I'm not sure whether there should be more stuff in gitignore so that stuff needs to be handled.

I'll update this issue when I have a final solution.

1. Change the file path in Logger class to print logs to a thumb drive. Test with a robot and a thumb drive. Check that no logs are going onto the RoboRio.
2. Test printing Rio storage as a percent on the shuffleboard. Check for accuracy.

OPTIONAL: if no thumb drive inserted, backup data on Rio. Test the log puller batch file to pull files off of Rio. If interested, see if the batch file can automatically run every 2 weeks or Rio storage 50% full.

See @LizzyMilford for more information

Uhh.. could we like, maybe, uhh, like call our, like, Elevator subsystem class ElevatorSystem.java instead of, you know, what it is now, which is Elevator.java. Standardization and such and such. I don't even care.