Software Sub-system

Apr 29, 2012

Final software design

We implemented and tested the final control software, with its state machine shown in the figure below. We chose to eliminate some of the previously implemented error-handling cases but also implemented some more depending on the necessity.

As shown in the figure, the errors handling include the following:

Low Battery Power: use LEDs to notify users and halt the system, release the spring after informing the user if necessary

Communication Failure: use LEDs to notify users and halt the system

Flex Sensor Poor Connection: use LEDs to notify users and then instruct the software to ignore the problematic sensors before returning to Wait state

Release Failure: use LEDs to notify users and halt the system

March 21, 2012

Second prototype software design

We implemented the second prototype software design to cooperate with the electronic and mechanical side of the project. The control software utilizes the concept of state machines and consists of eight states (shown in the below figure):

    WAIT: the initial state of the program

    CHARGE: the state in which the robot charges the springs

    RELEASE: the state in which the robot releases the springs

    Two states for rotation (MOVE_LEFT and MOVE_RIGTH): the rotation states in which the robot performs rotations

    Two states for planar motion (MOVE_FROWARD and MOVE_BACKWARD): the planar motion states in which the robot performs planar motions

    ERROR: the error-handling state in which the robot reports errors and tries to handle some of the errors

Meanwhile, we also considered a number of situations where the system might end up being in an error status. We currently implemented six errors handling cases explicitly and three cases implicitly.

Six explicit error handling cases include:

1. The spring-charging motor runs for too long and the sensor value of rotary encoder passes the safety threshold;

2. The spring-charging motor runs for too long, causing the timer to pass the safety threshold;

3. XBee communication fails when reading a different type of encoded packages or the reading process itself generates errors;

4. The spring-charging motor runs backwards during charging;

5. At least one spring is not fully released according to the sensor value of the flex sensors;

6. The difference between the degrees of charging of the two springs becomes too large.

And the implicit error handling cases include:

1. The system returns to State WAIT if it is currently in another state and finds that the XBee communication is lost;

2. The system remains in the same state when the user presses multiple buttons including the button that is associated to the current state (e.g. the system remains in the MOVE_LEFT state if both move-left and move-right buttons are being pressed);

3. The system disallows itself to charge or release the spring two consecutive times without entering the other state in between (i.e. the system disallows entering State CHARGE again after the springs are fully charged but not released).

Demonstration of second prototype software implementation

Since the shipment of the PCB did not arrive before the demonstration, we presented the working of all software functionalities using a custom made breadboard circuit. The figure below illustrates the demonstration circuit which includes the following sensors to assist working of the software:

1. Two 22” Flex Sensors – The flex sensors will measure the bending angle of the fiberglass springs. The motor stops rotating when the springs reach the threshold angle (when the wheels of the robot touch ground).

2. One Digital Rotary Encoders – Rotary encoder measures the rotation of the motor and assists the system with error handling issues. If the motor behaves abnormally, it will directly affect the spring clutch which can lead to mechanical failures of the system.

November 19, 2012

First prototype software design

Today we demonstrated the "pre-prototype" design of the RooBot. In terms of the software design, the basic structure of its perception algorithm is a state machine. It contains the following five states: Wait state that waits for jumping commands sent from the remote controller, Charge state in which the DC motor rotates to charge the fiberglass spring, Release state in which the servo motor runs to toggle the spring clutch switch to release the spring, Error state that handles all the errors and Sleep state that is entered if the robot receives no jumping commands after a certain number of attempts.

The relationships among different states are illustrated in the figure below. Waitstate - the initial state - Charge state and Release state comprise the three main states. The typical flow is Wait -> Charge -> Release -> Wait. Errors can happen atCharge state and will be handled in the Error state. The Error state should be able to traverse to Wait state, although it is not implemented right now. Meanwhile, no response in a long time may result in entering Sleep state, which puts the system into sleep. It is designed to be able to be awakened and travel back to Wait state although it is not implemented, either. The dash line indicates the decision making box is optional and can be removed.

October 23, 2012

Initial software design

The team came up with Perception algorithm for the RooBot system. Figure 1 below describes the implementation method of the perception algorithm for the system. 

Figure 1: Perception algorithm in Software model

Below is a list of sensors used in the RooBot system:

1.Wireless Controller

a) Potentiometer - User inputs the jumping power of the toy

b) Launch button - Set launch command

c) Rotation buttons (“Left” OR “Right”) on the controller

2.Jumping System

a) Force sensor - Acknowledge correct launch and landing

b) IMU - Measure roll, pitch and yaw of the system (before & after launch)

c) Two Rotary Encoders (Hall-effect sensors) - Measure rotation of motors for feedback control of motors (implement PID control for preciseness)

d) Temperature sensor - Health monitoring (measures over heating of the system and acknowledges the health state)

Figure 2 illustrates the flow diagram of the perception algorithm. This helps us in understanding the control of the system at a higher level.

Figure 2: Flowchart of perception algorithm

(Click on the figure to view a larger image)