Author Topic: To-Do list  (Read 4442 times)

Louis L

  • Administrator
  • Hero Member
  • *****
  • Posts: 564
To-Do list
« on: January 17, 2016, 09:02:37 PM »
Put stuff here that you think needs to be done. Assign a priority
When an item is done, just mark it with an 'X'

Priority 1 (immediate attention)
  • (done) Take picture of high goal with retro-reflective tape for LabVIEW vision assistant
  • (done) Program/image both router
  • (done) Image new RoboRio
  • Update all software laptops with latest software per Brad's instructions.
Priority 2 (do it soon)
  • (done 1/12/16) Clean Dev1 laptop that's overheating
  • (done) Check log of other 6 laptops to see what their diag log looks like. Are there similar overheating issues?
  • Check the firmware revision on the Talon SRX. FRC Firmware Revision 2.0, dated 1/10/16 is out so our older SRX controllers may need to be updated. We should also check to see if any of Talons have non-FRC firmware.
Priority 3 (do when time allows)

Priority 4 (not important, just nice to have done)
« Last Edit: January 29, 2016, 10:17:02 PM by Louis L »

Rakesh V

  • Guest
Re: To-Do list
« Reply #1 on: January 22, 2016, 08:49:44 PM »
Put stuff here that you think needs to be done. Assign a priority
When an item is done, just mark it with an 'X'

Priority 1 (immediate attention)
  • Take picture of high goal with retro-reflective tape for LabVIEW vision assistant
  • X Program/image both router
  • X Image new RoboRio
Priority 2 (do it soon)
  • (done 1/12/16) Clean Dev1 laptop that's overheating
  • X Check log of other 6 laptops to see what their diag log looks like. Are there similar overheating issues?
Priority 3 (do when time allows)

Priority 4 (not important, just nice to have done)

Louis L

  • Administrator
  • Hero Member
  • *****
  • Posts: 564
Re: To-Do list
« Reply #2 on: January 27, 2016, 12:00:34 AM »
Reminder to sw teams - things we must do.
  • Always know your starting state for all pieces of hardware. This means you either have to read the state of the device you're controlling or you program it to a known starting state. Never assume a starting state.
  • When done, make sure the hardware is in a safe state, regardless of whether we successfully climbed or not. The shooter should be dis-armed (unload the spring if it's cocked). What do we do if there's a ball in the shooter?
  • SW maintains its own internal clock. It will lockout auto-climb until the last 20 seconds.
« Last Edit: January 27, 2016, 08:31:18 PM by Louis L »

Louis L

  • Administrator
  • Hero Member
  • *****
  • Posts: 564
Re: To-Do list
« Reply #3 on: February 09, 2016, 04:00:32 PM »
Java/C++/LabVIEW teams:

This is the home stretch, so let's make a new list and check it twice. The hardware is likely be late so we need to pre-test as much as we can so that once the hardware is available we spend as little time as possible debugging.

Drive-train
  • We need to test this against the defenses. Check for how well it works against defenses, fine control for targetting.
  • Question - which gear ratio do we want to use? (low/regular/high). Drivers need to test this.
Climber
  • Test as much as we can using the test-bed.
  • Good news - this is largely a simple state machine, doing a set of tasks one after another.
  • Bad news - we really need the actual robot to check if it really works.
Intake
  • We should be able to test this with the test bed. Let's do this asap. It's just motors and sensors.
  • Be aware of multiple-button presses (button priority) and allow for easy changes to sensor-to-motor on/off delays in your code. These delays will be fine tuned when we have the real robot.
Vision - used by both Shooter and Autonomous
  • A huge unknown. It's hard to know what will happen without using our robot on the real field.
Shooter
  • (reviewed) For the sake of simplicity, assume that we'll be arming and shooting the Boulder all in one motion. This will make it easier to test on the testbed.
  • (reviewed) But to get under the Low Bar, we need to arm the shooter without a Boulder in the cradle. So in essence we still need the functionality of arming but not shooting. But I still think that having two separate functions is easier to program even if it's not as efficient. We can always change the shooting code later. Let's make sure we have stuff that works for now.
  • Ignore/delete anything having to do with controlling the strength of the shot and swiveling the catapult.
  • Integration with vision is an optional task - it's important for sure but only after the rest is working reliably.
Autonomous
  • (done) We have a number of possibilities and need to narrow this down to a workable set.
  • Testing each requires the real thing, especially when we're dealing with timed motion (how long does it really take to cross the Outer Works?)
  • (done) The planned Strategy meeting this weekend will address this - how many of these auto modes are reasonable? Are there other modes we forgot about?
Stuff to review
  • Make sure to initialize all variables and states.
  • Make sure to initialize / reset / know-for-sure all hardware states
  • Timing lockout to prevent accidental button presses is good. Ex: ignore climbing command until the last 20 second of match.
  • Make sure the robot is safe at end of match. The safety protocol will shut down all motors but we should make sure nothing is in a state that can be dangerous to the drive team removing the robot from the field.
« Last Edit: February 22, 2016, 09:57:40 AM by Louis L »