• Welcome to Redshift Project Depot.

Post-WPI discussion summary

Started by Louis L, March 26, 2018, 12:58:45 PM

Previous topic - Next topic

Louis L

This posting is obviously late but it's important to document everything.

I took a picture of the workroom whiteboard and transcribed it here. The flow of the discussion is reflected in the grouping of the items below.

First we discussed what went right and wrong. The focus is of course on what went wrong since that's what we wanted to fix between WPI and RIDE.

  • arm is slow, cycle time too is long. We can't process enough Cubes in a match.
  • intake and claw alignment issues.
  • exposed, easily damaged, and inoperative limit switches
  • gyro drift means arm does not know how to get to the same place over time.
  • intake alignment is questionable; does not work as needed.
  • auto is not reliable.
  • extension is a PITA
  • lead screw hub broke.
  • software did not monitor all motors. We burned out a motor that was stalling.
  • bad swerve drive? We replaced one swerve unit but it later tested fine. A cable from the unit to the RoboRio was later found to be loose. Did the symptoms match the cable problem?
  • we had problems with the arm pot - is the unit bad or is it just bad wiring?
  • grabber alignment to cube - not reliable
  • tower is shaky. When things get tall, things get tipsy. It's just physics.
  • swerve reset when not driving. This is normally not an issue on flat ground. But the game's angled flooring near the Scale can cause enough movement of the robot to affect the game.
  • arm positioning not optimal
Now that we have a list of problems, we tried to summarize the root cause that lead to these problems from a design point of view.

  • lack of consistency and repeatability
  • lack of overall speed
  • intake has only 2 wheels so Cubes can get stuck in odd positions.
  • any one failure breaks everything - too fragile
  • too much automation, no recovery when something goes wrong
  • too susceptible to misalignment (little margin for error)
  • lacks robustness
  • two isolated subsystem to get Cube - intake and grabber
  • too many exposed delicate items - limit switches, intake assembly, electrical board
  • intake not optimal, can not handle 11 inch Cube side.
  • too much wiring, too much everything
  • no climber
Finally we need to identify what led to a poor design so we don't do it again in the future.

  • Linear motion is generally a bad thing on our robots. They tend not to be as easy to create, deploy or use.
  • We employed too many band-aids to make things work. Needing a band-aid is often a sign that there's an underlying design problem that needs to be addressed.
  • We built subsystems but did not integrate them during the design phase.
  • There was a lack of communication between members of the team.