AME 3623: Project 6: Compasses and Position Control
For this project, you will be writing a control loop that orients the
craft to a desired heading.
- All components of the project are due by Thursday, April 6th
at 9:00 am
- 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:
- extract hovercraft orientation from a magnetometer sensor, and
- use the sensory data to drive the motors in such a way that the
craft will orient toward a goal.
Component 0: Library Installation
One new file has been placed in the lib directory of
your subversion tree (ImuUtils.zip and QuaternionFilters.zip)
The new library provides the following functions (note the changes in
names from the last project):
- imu_setup() initializes the inertial measurement
unit. This setup function makes a reasonable guess about your
magnetometer biases. However, these may or may not work well
for your configuration.
- imu_update() updates the state of the inertial
measurement unit. This function expects to be called regularly
(at 100-200 Hz).
- imu_calibrate_magbias() is a function that will walk
you through the steps of calibrating your compass.
Specifically:
- It will ask you to turn your craft slowly (at a near
constant speed). The function expects that you will
complete four full revolutions in 40 seconds.
- After execution of this function, the magnetometer
biases will be reset. This function also prints out 3
lines of code that you can place into your setup() code. By
doing this, you don't have to call
imu_calibrate_magbias() every time you start your program.
Component 1: Circuit
There are no changes to be made to your circuit. However, you should
make sure that your orientation LEDs are working properly.
Component 2: Compass Software and Configuration
- Implement a new PeriodicAction (called sensor_task)
that executes once per 5 ms
- The associated sensor_step() function should:
- Call imu_update()
- If a character has been received from the serial input,
and that character is 'c', then this function should
call imu_calibrate_magbias()
- Implement a new PeriodicAction (called report_task)
that executes once per 250 ms
- The associated report_step() function should print
out the current state of IMU.yaw
- Test your compass
Component 3: Control Software
Implement the following functions:
- float compute_rotation_error(float theta_goal,
float theta)
returns the error between the current orientation and the goal.
Specifically, we are asking what the orientation of the craft
is relative to a coordinate frame that is defined by the goal.
Return values must range between -180 (exclusive) and 180
(inclusive) degrees. Positive
values correspond to the current orientation being clockwise from
the goal.
- float deadband_and_saturation(float error, float deadband, float
saturation) takes as input an orientation error, a deadband
level and a saturation level, and returns a modified error.
- For an error that is +/- deadband, this function returns a
zero.
- For an error that is larger than saturation, this function
returns saturation - deadband
- For an error between deadband and
saturation, the return value linearly increases
with increasing error.
- and you must deal with the negative side, too.
- Note: this function must be continuous.
- Your control_step() function should remain the same as
in project 5, with the following change:
float ddx = 0.0;
float ddy = 0.0;
float ddtheta = Kp * modified_error;
set_hovercraft_acceleration(ddx, ddy, ddtheta);
where modified_error has already been subjected to the deadband
and saturation
Also, this function should display the current heading error.
- Your goal should be read the first time control_step() is called
and stored for later use.
Component 4: Testing
- Slowly increase Kp until the craft aggressively
tries to maintain the goal orientation.
- At this point, you can place the craft on the floor (or a
table, if you are careful).
- The craft should produce a thrust in the direction that is the
shortest distance to the goal (switching at 180 degrees behind
the goal)
- We do not expect the craft to precisely stop at the goal (and
instead, it will likely oscillate around the goal)
What to Hand In
All components of the project are due by Thursday, April 6th at
9:00 am.
- Demonstration/Code Review: All group
members must be present. The demonstration must be completed
by Tuesday, April 11th.
- Check in the following to your project 6 area of your
subversion tree:
- Personal report: there is no personal report 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 credit.
- 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: Mon Apr 3 17:06:22 2017