Lab 8：Stunt!

Objective

The objective of this lab is to achieve a fast stunt on the robot. The performance has to be steady which will be proved in video evidence to work at least three times. I chose to do Task B drift, as this gives me a illusion that my robot is like a F1 car can do some turns that I do not dare to achieve when driving.

switch mode switch mode

To enable robot to do a series of things step by step, I incorporated a switch-mode to have it do each thing step by step: APPROACH enables robot to approach the wall to distance as close as 1 ft which is similiar to lab 5 and sets the goal of final orientation as 180 degrees from the initial orientation. To ensure that the switching happens only the robot at the appropriate position, switching of modes is inside the if statement for position check.
TURN ALIGH was evolved from a function of make a turn and a function of orientation alignment like lab 6. I was experimenting with two modes doing these functions following each other. However, the control of turning 180 degrees uses the orientation adjustment code snippet inevitably which is a bit redunant to the second function. Therefore, one mode should be able to achieve the goal successfully.
EXIT STRAIGHT only do the time check that it finished the orientation adjustment and approximately 2 seconds later and then stop the forward motion.

function(angle action) function(orientation control)

However, when it got implemented in the run, it occurred that robot cannot precsely identify the target orientation of 180 degrees from original orientation.Below are graphs from collected data points: Distance(mm), Speed with P control, and angle (degrees) VS time(s).

Watch the video of car failing to return back... smaller ODR rate smaller ODR rate smaller ODR rate

The biggest hint from error graph is that the angle graph which I can see that robot keeps rotating regardless the existence of target orientation. Error did not converge to zero. It is possible that angle gets weird or cannot handle well when it comes to 180/-180 degrees even with the current handling with angle which makes angle error always within 180 from fresh orientation. Another potential reason that angle got messed up is because I set the target orientation is 180 degrees from the original which confused with discontinutity of angle range.

If I have more time working with it, I would want to try a way to only take account of how much angle it accumulated turning, potentially abandoning the direction of turning if possible. It would be more realistic that taking off the oscillation in the angle graph, which basically measuring turning towards one direction ONLY.

Reference

Thanks to TA Jack Long for discussion about clearer structure of switching modes.
I used chatGpt for debugging and brainstorming potential error happening.