AME 3623: Project 8: Lateral Velocity Control

For the last two projects, you have focused on PD control of orientation. For this project, we focus on derivative control of lateral directions. Specifically, your FSM will specify desired velocities along the X and Y directions and your control_step() will work to achieve these velocities.

All components of the project are due by Friday, April 19th at 11:59 pm
Groups are the same as for project 1.
Discussion within groups is fine.
Discussion across groups may not be about the specifics of the solution (general programming/circuit issues are fine to discuss).

At the end of this project, you should be able to:

integrate lateral velocities as sensed by the cameras into the control loop (implementing a velocity control law).

Component 1: Hardware

There are no new hardware components for this project. However, we are assuming that orientation control is working well and that you have your cameras working properly. Please verify that that the cameras are still working before starting on this project.

Component 2: Software

Implement the following functionality:

Add the following global variables:

       float velocity_filtered[3];  // x_dot, y_dot, theta_dot
       float velocity_goal[2];      // x_dot, y_dot

Create a new camera_task that executes every 5ms. This task will:
- Query the cameras.
- Compute the distances traveled in the hovercraft coordinate frame during the last 5ms. (this is done by your compute_motion() function)
- Compute a low-pass filtered estimate of the hovercraft velocity. One dimension is computed as follows:
```
	    fvx = fvx * (1 - dt / tau) + dx / tau;
```
  where fvx is a filtered velocity, dt = .005 s, dx is the distance traveled by the hovercraft in the last dt, and tau is a filtering time constant (for now, choose .05 s).
- Note: don't forget to import both your camera initialization, camera query and compute_motion() code from project 3.
- Since you only need the distance traveled in the last 5ms, don't forget to zero out adx and ady at each step.
In control_step():
- Keep your torque term.
- Update your fx and fy terms as follows:
```
	    fx = KLv * (velocity_goal[0] - velocity_filtered[0]);
```
- Note: although we are computing filtered_velocity[2] for completeness, we are not using it for this project.
- Remember that your units of velocity_filtered (and hence velocity_goal are in terms of meters).
Update your finite state machine to implement the following sequence:
- Wait for switch to be pressed.
- Short duration: ramp up central fan with velocity_goals = 0. Continually set orientation goal to current orientation.
- 15 sec: hover with velocities_goals = 0
- 10 sec: Set velocity goals to something interesting (e.g., .1, 0; a forward movement)
- 10 sec: hover with velocities_goals = 0
- 10 sec: Set velocity goals to something in an orthogonal direction (e.g., 0, .1; a leftward movement)
- 10 sec: hover with velocities_goals = 0
- Short duration: ramp down the central fan
The orientation LEDs should continue to display the current heading error.
The LED bar should continue to reflect orientation rate.
Tune your KLv parameter so that your hovercraft moves at approximately the desired speed in the indicated directions.

Component 3: Looking Forward

For project 9, we will be using the distance sensors. We recommend that you mount one pointed forward and the other pointed to either the left or right. They should be mounted to the top ring (not to the bottom ring).

What to Hand In

All components of the project are due by Friday, April 19th at 11:59 pm.

Demonstration/Code Review: All group members must be present. The demonstration must be completed by Tuesday, April 23rd.
Check in the following to your project 8 area of your subversion tree:
- Documented code: See the project 1 specification for detailed documentation requirements.
Personal report: There is no personal report due for this project.

Grading

Personal programming credit:

Each person must accumulate at least three personal programming credits over the course of the semester. This project offers one.
To receive credit, you must be the primary designer, implementer and debugger of the component. This does not mean that your other group members should not be looking over your shoulder. But: you must do the "driving."

Group grade distribution:

35%: Project implementation
30%: Demonstration of working project (to either of the TA or the instructor)
35%: Documentation

Group Grading Rubric

Grades for individuals will be based on the group grade, but weighted by the assessed contributions of the group members to the non-personal programming items.

andrewhfagg -- gmail.com

Last modified: Thu Apr 18 22:30:07 2019