Task Breakdown

[Shreya C]

Hello,

Today we created our initial task breakdown for each of the major projects under software. Here's the link to the Google Doc with our breakdown detailed—as you see, we still need a lot of detail from the mechanical subsystems before we can further break down tasks. We're planning on meeting Sunday for 1-2 hours to discuss exact behavior of each subsystem and the resulting software requirements and limitations.

[Louis L]

The link doesn't work.
Also the google doc is not shared.

Can we avoid google docs in the forum unless you absolutely need to have it. If you have a table or just a list of items, just post it in the forum.

[Matt S]

P# = Priority Level

development environment - done
swerve - in progress

   
• basic drive train working - Java: done, C++: In progress
• measure distance traveled - P0 (be able to determine position vector \ for robot) - Java: done, C++: To do
• move in certain direction for certain distance (directed movement) - P1 - Java: done, C++: To do
• turn to face in a certain direction - P1
• PID - traveling certain distance - P2
• brake (defensive position) - P2
• field-centric - P0
• retype code - done
• intro to swerve - done
• change talon library - done

Intake - to do

   
• initial design - P0
• control lifting and lowering
• control speed + direction of intake wheels
• determine current state of intake (raised or lowered)
• detecting presence of a cube

arm - to do

   
• initial design - P0
• PID
• positions (switch, neutral scale, higher scale, lower scale, extension for climbing)
• 
        
  • decide modes
  • determine how to control
  • implement controlling
• automation of opening of arm: fold, lower, unfold (to avoid disqualification) - P1

Claw - to do

   
• initial design - P0

climber - to do

   
• initial design - P0

operating interface - to do

   
• inputs for arm - P1
• inputs for intake - P1
• inputs for claw - P1
• inputs for climber - P1
• button priorities - P3
• safeguards (state machines) - P3
• iterative design w/ drive team - P2
• camera display on driver station - P2

Autonomous - to do

   
• autonomous modes/options (for auto period) - P0
• 
        
  • determine initial configuration on field
  • determine actual mission/task
• mode selection - system sendable chooser ** - P1
• command sequencing (research; breakdown larger tasks to smaller tasks that can be reutilized) - P1
• plate assignment from FMS - P0

sensors - research for implementations of different sensors - to do

   
• IMU/gyro - P1
• ultrasonic - P1*
• encoder/potentiometers - P0

      
• wheel encoder on the swerve drive - done
   
• optical -
• pressure - P1
• PID - P0/1

vision - to do

   
• strategy for uses - P2

external dependencies - to do

   
• communication w/ electrical lead about test bed - P0

operations

   
• absolute encoder alignment

[ohad z]

Need to add:

   
• A way to control the abs encoder values from the driver station to help in cases where we are replacing hardware.
• Setup of Robot Builder file with final motors, sensors and subsystems. Share file among teams
• POC for motor + limit switch + motor stall using current draw

[Shreya C]

P# = Priority Level

development environment - done
robot map - in progress
swerve - in progress

   
• basic drive train working - Java: done, C++: In progress
• measure distance traveled - P0 (be able to determine position vector \ for robot) - Java: done, C++: In progress
• field-centric - P0: To Do
• move in certain direction for certain distance (directed movement) - P1 - Java: done, C++: In progress
• turn to face in a certain direction - P1: In progress
• PID - traveling certain distance - P2: Proof of concept worked out, hardware + software
• brake (defensive position) - P2
• retype code - done
• intro to swerve - done
• change talon library - done

Intake - to do

   
• initial design - P0
• control lifting and lowering - P1: To Do (for Saturday 02/03)
  
  
  
  • Control speed of lifting + lowering using the Bosch motor - P1: To Do
  • Use limit switches to detect start + end of raising & lowering - P1: To Do
• control speed + direction of intake wheels - P1: To Do (for Saturday 02/03)
• determine current state of intake (raised or lowered) - P1: To Do (for Saturday 02/03)
• detecting presence of a cube using limit switches at edges of the cube - P2

arm - to do

   
• initial design - P0
• PID - P0: proof of concept done (software + hardware)
• positions (switch, neutral scale, higher scale, lower scale, extension for climbing) - P1: To Do
• 
        
  • decide modes - P1: To Do
  • determine how to control using limit switches/encoder
    
    
    
    • Use encoder on PG27 to measure how far arm has extended - P1: To Do
    • Control the arm's extension using limit switches - P1: To Do
    • Use encoder on mini CIM to determine angle of arm - P1: To Do
    • Control arm's bending using limit switches - P1: To Do
• automation of opening of arm: fold, lower, unfold (to avoid disqualification) - P1: To Do

Claw - to do

   
• initial design - P0
• Control picking up of cube - P1
  
  
  
  • Control speed of opening of sliding mechanism by programming motor - P1
  • Limit opening + closing using limit switches - P1
  • Detect pressure to determine that cube is secure - P2
• Control pivoting of claw (program motor & limit switches) - P1
• Keep claw level when depositing cube using accelerometer - P1: proof of concept started?

climber - to do

   
• initial design - P0
• Control unwinding of winch by controlling CIM - P1: To Do

operating interface - to do

   
• inputs for arm - P1
• inputs for intake - P1
• inputs for claw - P1
• inputs for climber - P1
• button priorities - P3
• safeguards (state machines) - P3
• iterative design w/ drive team - P2
• camera display on driver station - P2

Autonomous - to do

   
• autonomous modes/options (for auto period) - P0
• 
        
  • determine initial configuration on field
  • determine actual mission/task
• mode selection - system sendable chooser ** - P1
• command sequencing (research; breakdown larger tasks to smaller tasks that can be reutilized) - P1
• plate assignment from FMS - P0

sensors - research for implementations of different sensors - to do

   
• IMU/gyro - P1
• ultrasonic - P1*
• encoder/potentiometers - P0

      
• wheel encoder on the swerve drive - done
   
• optical -
• pressure - P1
• PID - P0/1: Done (proof of concept in hardware + software)

vision - to do

   
• strategy for uses - P2

external dependencies - to do

   
• communication w/ electrical lead about test bed - P0

operations

   
• absolute encoder alignment
• control abs encoder values from driver station
• POC for motor + limit switch + motor stall

[ohad z]

Once we are starting to work on the new chassis we would need to change the hardware definitions (CAN and AIN/DIN/etc) from the existing (last years) to the new hardware mappings. This would mean that the existing chassis would stop working  with the new code. We can remap the existing chassis to match the new values to be able to keep it running for as long as we can. The reason to keep the existing chassis running is to have the swerve code - including distance, angle, autonomous - continue to be developed and debugged on it.

[Louis L]

Once we are starting to work on the new chassis we would need to change the hardware definitions (CAN and AIN/DIN/etc) from the existing (last years) to the new hardware mappings. This would mean that the existing chassis would stop working  with the new code. We can remap the existing chassis to match the new values to be able to keep it running for as long as we can. The reason to keep the existing chassis running is to have the swerve code - including distance, angle, autonomous - continue to be developed and debugged on it.

The current chassis (Satis) swerve drive components are all at the same harwdare definitions as on the new chassis. When the definitions for the new chassis were made, I copied the drive portion definitions to the new chassis so we wouldn't have to make any changes.

So we can continue to use the old chassis with the new code. It'll work just fine.

[ohad z]

Cool. The plywood chassis was also updated to match the planned hardware map for the new chassis.
Software now should be portable between all three platforms.

[Louis L]

Shreya - I haven't given you a  LabVIEW software breakdown / schedule. Here's where we're at.

   
• swerve drive proof-of-concept done. This is where we got stuck last year so it was important we passed this in order to get the go-ahead to continue.
• RobotCentric works.
• Robot/FieldCentric switching is coded but needs testing. This would be good to test to validate UI portion of code.
• I've re-architected the way UI commands are handled to hopefully better spread out the work for the new students. This will allow more parallelism. My goal is to have them write code as best as they can, then I will integrate each module into the greater code base and make fixes as needed.
• There are now 4 subsystem threads - Arm, Climber, Intake and Gripper. Harshith wrote the Intake thread and I integrated it last night. Basic UI command parting is done. 5 of the 16 commands are implemented but not tested.
• Related to this - the UI commands have been defined after the group meeting last week. Matt and I discussed adding a 17th command. I also wrote a document to break down each command so that we practice good embedded software practices.
• Camera is working.

Near term goals - to be finished by end-of-day Sunday:

   
• all 4 subsystem threads coded. Some optimization may remain but at least they should functional.
• majority of remaining commands (11 or 12 of them) coded to use these threads.

Roadblocks

   
• Attendance.
• Interruptions for my time. Since the team is learning, I'm the gateway. My time doing other things limits what the team can do to move forward.

[ohad z]

Task list and status of the Arm mechanism software:
1. Validate geometry assumptions: This was done with Ed, and it looks like the Final arm assembly will be partially extended in the cube pickup position and would need to be retracted before it can move to other positions. Software would need to accommodate retracting to not violate rules (prior to arm changes, it was going to be fully retracted at pickup). This task is done
2. Basic commands (command building blocks to control individual pieces of the arm/extension/claw): Commands are placed in commands.arm package. Command implementation in progress. Commands left to implement include the gripper commands
3. Extension mode programming: Math and strategies for arm extension have been discussed. Arm extension strategies implementation is done, testing for strategies is done.
4. Manual operation of arm: This would included the fine tuning of the arm manually up and down including the extension controls, using the joystick. This is done
5. PID controls for arm stall current: this will apply PID logic to the arm up/down motor to keep arm from sagging. Implementation is done though not yet verified in real life
6. Gyro programming: This would add mode to the claw movement to put it in horizontal position. Not done
7. Gripper modes: TBD. Not done
8. Stall current detection: Add stall current detection to motors as necessary. Not done
9. Change Software PID to hardware PID for arm and extension to accommodate new wiring of POT. This is not done

External dependencies and unknowns:
- PID testing to see if arm can be kept in place (if this is not working as expected user control through stick is planned)

[Vanshika C]

Task list and status of the Arm mechanism software:
1. Validate geometry assumptions: This was done with Ed, and it looks like the Final arm assembly will be partially extended in the cube pickup position and would need to be retracted before it can move to other positions. Software would need to accommodate retracting to not violate rules (prior to arm changes, it was going to be fully retracted at pickup). This task is done
2. Basic commands (command building blocks to control individual pieces of the arm/extension/claw): done, not tested
3. Extension mode programming: Math and strategies for arm extension have been discussed. Arm extension strategies implementation is done, testing for strategies is done.
4. Manual operation of arm: This would included the fine tuning of the arm manually up and down including the extension controls, using the joystick. This is done
5. PID controls for arm stall current: this will apply PID logic to the arm up/down motor to keep arm from sagging. Implementation is done though not yet verified in real life
6. Gyro programming: This would add mode to the claw movement to put it in horizontal position. Done, not tested.
7. Claw modes: done
8. Stall current detection: Add stall current detection to motors as necessary. Not done
9. Change Software PID to hardware PID for arm and extension to accommodate new wiring of POT. done

External dependencies and unknowns:
- PID testing to see if arm can be kept in place (if this is not working as expected user control through stick is planned)

[Matt S]

Next thing that we need to do for testing purposes is to allow most of the constants used throughout program to be modified through smart dashboard.  This will help us by being able to change constants like speed and PID on the fly, as well as to not damage robot components.