[Programming] Preliminary Designs

Today, we decided on the general plan of action we are going to try and follow this year. The design includes concepts from both a threaded system and a state machine, as a response to some of the difficulties we experiences earlier.

The architecture contains 2 main parts, a set of Component objects and a controller thread. A controller is a software representation of a physical component. For example, the ball shooter will be a component. A component object will maintain 2 states corresponding to the physical robot; a current state and a target state. A target state is set by a caller, which in this case, is the controller thread. The component uses the current state and target state to determine what to do everytime an update() method is called. The controller thread implements all of the actual logic of the program. In essence, the Component objects are specific to the robot, and the Controller thread is specific to this year's game.

In summary:

Component:

- Represents a physical component

- Maintains 2 states:

  -Current state: Where is the component right now?

  -Target state: Where should the component be?

- Implements an update() method, which determines how to make the current state approach the target state

Controller:

- Is run in its own thread (runs parallel to the main operating loop)

- Implements game logic (e.g., tell the drive to do something)

In addition to these main components, there will be specific static libraries for the components and controller to do what they need to do, e.g., vision (if used) will be a static library.

Current Components:

The current components we thought of so far (which is completley tenative) consists of the following objects:

Drive: Contains the motors to move the robot

Ramp Arm: The arm used to push down the bridge

Shifting Weight: Tenative, if driving/manipulator can include an internally shifiting weight

Sensor Inputs: All the neccesary sensors, such as accelerometer. This will maintain a pool of values, and perform filtering.

Arm/Shooter: Responsible for shooting the balls

Picker-Upper: Picks up balls from the floor. May be combined with Ramp Arm.

Main Operating Loop:

This thread should remain simple, calling the components to update their state. As of right now:

teleop()

   Update all components

   Wait, repeat

   If controller thread not started, start

auto()

   Same as teleop

Methods will also exist for the access of different Components.

Timeline:

A general timeline we are aiming for, starting next week:

2 weeks: Write a majority of the Component classes.

1 week: Static libraries for the controller to use

2 weeks: Finish the libraries, write the controller, and debug with the robot

On the side, Matt and I will be working on vision, and will determine if it will be feasible to use in competition.

Issues Addressed:

This is designed to counteract some of the difficulties we experienced last year. The components of the code are all very small, allowing for parallel development and quicker debugging. A hybrid state-machine and threaded system simplifies some of the complexities we encountered with a pure state machine and avoid multi-threading issues. Different groups can work on seperate components, so we can have "specialists" of a component, which should reduce confusion.