FRC 2017 Recap

Team Updates

Great year for the team, our best finish ever at WPI district taking second on the alliance with teams 1519 and 190. Here are my programming notes for the year.

Sensors & Autonomous

Sensor feedback is not optional. All systems MUST have appropriate sensors in order to properly code autonomous mode. This includes encoders or counters for all motors, rangefinders for distance sensing, gyros for steering, and limit switches where appropriate. The new IMU worked great for steering in auto mode this year, but really requires drive motors to be coded with PID motor control.

The magnetic encoders on the drive wheels were great, but only two of four worked, then we lost those when we replaced all four drive motors at WPI. ALL drive motors on ALL platforms (test bed, etc) should be fitted for these magnetic encoders.

The counter on the shooter wheel worked great until it came loose (taped on), then the code kicked in trying to compensate and over-powered the shooter.

Vision

Continues to be just beyond our grasp. A major issue with vision processing in general is that it bogs down the Rio's CPU and should really be done by a separate processor. However, this is meaningless if we can't actually get vision tracking code working to steer the robot in autonomous mode. Good off-season project for software team. Partial vision code is in the final 2017 github commit, but commented out since it wasn't working.

PID

Again, this should not be optional, but it's been a tricky thing to work out. We had a fair amount of success using the feedback from the IMU gyros and a PI (no D) algorithm to handle the auto driving for the left & center gear modes, but there's significant room for improvement. Right side gear never worked due to those pesky real-world issues like weight distribution & friction.

GitHub

Worked like a charm this year, but mostly because there wasn't more than one programming working on the code at any given time. Some git notes:

Git Shell Color Scheme

  • Cyan means the branch matches its remote
  • Green means the branch is ahead of its remote (green light to push)
  • Red means the branch is behind its remote
  • Yellow means the branch is both ahead of and behind its remote

Merging & Syncing

When a fork is AHEAD of the master, you need a git push
When a fork is BEHIND the master, you need a git pull upstream master
Lastly, git status will tell you where you stand