CS 50 Nanocopter Project

Karima Ma and Christine Kim March 8, 2014

Introduction: Baseline

For our culminating project in cs50, we implemented a program in c that allows a user to y a nano-copter, called the Crazyie, through the air. The user controls the motion of the copter with hand gestures read by a Leap Motion detector. These gestures get read by the Leap and sent to the computer running the program, where they are processed as ight directions and sent via radio to the nano-copter. The radio (a usb device) not only sends ight directions to the copter but also reads data logged on the Crazyie such as battery level and altitude and sends that data back to the computer where they can be processed to inform future ight instructions. As an extension to the baseline project, we hacked into the hardware of the Crazyie by adding an ultrasound to the copter. By connecting the ultrasound to the logic board of the Crazyie, we were able to read data on the proximity of the copter to other objects. This allowed us to program the copter to perform intelligent autonomous ight, where the copter is given a signal to takeo from the ground and attempt to move from its starting point to another point some distance ahead. As it ies forward, the copter uses its sensor readings to determine whether it is approaching an obstacle, in which case it ies upwards to clear the obstacle.

Threaded Design

Since our program must simultaneously read hand signals from the Leap device and send those instructions to the copter, we implemented two separate threads that run concurrently. One thread reads hand signals and sends them to the computer while the other takes those instructions and sends them to the Crazyie.

2.1

Leap Thread

The Leap thread reads hand signals from the Leap device. Our program recognizes ve distinct hand signals that tell the Crazyie to y up, down, land, or hover. The Leap thread continuously reads these signals and updates a global variable called current_signal which holds the ight signal that the user wishes to send to the copter. The Leap thread also updates two other global variables: current_roll and current_pitch based on the position of the users hand. For example, if the Leap motion device reads that the hand is towards the left of the Leap device, the Leap thread will interpret that as a user command for the copter to move to the left. In this case, the current_roll variable would be accordingly set to have a negative value so that the copter will y to the left. Conversely, if the Leap reads that the hand is towards the right of device, the Leap thread will interpret that as a user command for the copter to move to the right. In this case, the current_roll variable would be accordingly set to have a positive value so that the copter will y to the right. if the Leap motion device reads that the hand is tilted forwards (ngers pointed down) over the Leap device, the Leap thread will interpret that as a user command for the copter to move forward. In this case, the current_pitch variable would be accordingly set to have a positive value so that the copter will y forward. Conversely if the Leap motion device reads that the hand is tilted backwards (ngers pointed 1

up) over the Leap device, the Leap thread will interpret that as a user command for the copter to move backwards. In this case, the current_pitch variable would be accordingly set to have a negative value so that the copter will y backwards. Please refer to the diagram below for images of the dierent hand signals and their matching ight instructions. In addition to setting the current signal and the ight parameters pitch and roll, the Leap thread also switches the m_setHoverPoint variable in the CCrazyie data struct (discussed below) on or o. This variable will determine whether or not hover mode is turned on or o in the copter control thread by the sendParam function.

2.2

Copter Control Thread

The copter control thread, called main_control, consists of an innite while loop that holds a switch statement where each case corresponds to a dierent ight signal: UP_SIGNAL, DOWN_SIGNAL, HOVER_SIGNAL, LAND_SIGNAL, and GROUNDED_SIGNAL. This thread uses the value that the Leap thread assigns to the global current_signal variable to determine which case to execute. Each case has its own helper function that it executes. These helper functions are correspondingly called: rise, descend, hover, land, and ground. Each of these helper functions in turn calls functions called setRoll, setPitch, and setThrust that set the roll, pitch, and thrust values of the copter to the current_roll and current_pitch values determined by the Leap thread. The current_thrust value is the only ight parameter value that is not set in the Leap thread. We designed our nite state model to set the thrust to pre-set values according the current ight signal. The current_thrust value is therefore appropriately set in the copter control thread. (We will further discuss our nite state model in the FSM section. ) The switch statement lies within a while loop that calls a function called cycle with each iteration in its conditional statement. It is in the cycle function where the ight instructions are actually sent to the copter via radio and where logged data is sent from the copter back to the computer for reading. The cycle function sets the ight parameters by calling sendSetPoint function, which sends packets holding the information called CCRTP packets to the radio. The cycle function also calls the sendParam function, which sends packets to the copter that switch hover mode on or o.

Figure 1: Threaded Design.

Data Structures and Globals

As mentioned above, our global variables include the current_thrust, current_pitch, and current_roll parameter variables. We also have a global variable called current_signal which holds the user-input signal read from the Leap. The time_of_last_mode_set global variable is used in our FSM to determine when to transition from from the up or down state into the hover state and will be explained in detail below. Finally, the cflieCopter global variable is an instance of the CCrazyie data structure, which holds ight parameters to sent to the copter as well as logged data read from the copter to send back to the computer. The CCrazyie data structure in turn holds two CTOC data structures, one called m_tocParameters, and another called m_tocLogs. Finally, each CTOC data structure holds a list of TOC data structures and a list of LoggingBlock data structures. A TOC element stores things about parameters and logged data such as the ID, type, string group, value, and ag for whether the data is to be logged. A LoggingBlock data structure holds corresponding information about how frequently data should be read from or sent to the copter. When we set the thrust, pitch, and roll values, those values just get stored in the CCrazyie data structure. Then when we pass the CCrazyie data structure to the cycle function, which is called with each iteration of the while loop in the copter control thread, those ight instructions actually sent to the copter via radio. At the same time, the data that we wish to log from the copter such as battery life is also sent back and stored in the CCrazyie data structure.

3.1

Safe Code

Whenever one writes a program that involves concurrent threading and modication of global variables, it is paramount to ensure that dierent functions are not changing global variables in unexpected ways. In our program, we use global variables. However, the design of our code ensures that the two separate

threads are never modifying the same global variables. The Leap thread is solely in charge of updating the current_signal variable, the current_roll and pitch_variables, and the time_of_last_mode_set variable. The copter control thread is solely in charge of updating the current_thrust variable and the CCrazyie data structure. Therefore, our program never runs into a situation where a global variable is modied by a thread in an unpredicted way.

4
4.1

Finite State Machine Design and Decomposition

Limitations of the Example FSM

The simple Finite State Machine (FSM) model discussed in the example design document switched between a Normal and Hover state to control the copter. Beginning in the Normal state, where the copter could move in three-dimensional space, signals from the leap motion would switch the copter into Hover mode, where the copters altitude was maintained at a constant level, or into a Landing state. After testing the sample binary code implementing this simple FSM, we found the copter was extremely dicult to control without signicant practice due to both the copters lack of stable motion and the leaps ultra-sensitive readings.

5
5.1

Pseudo Code
On Frame Function (main function called by the leap thread)

onFrame ( l e a p c o n t r o l l e r r e f c o n t r o l l e r , void u s e r i n f o ) { I f ( c u r r e n t s i g n a l = Hover o r Grounded ) I f ( hand moves down a t f a s t s p e e d ) c u r r e n t s i g n a l = Down t u r n o f f Hover Mode v i a setSendParam ( ) record time of last mode set return I f ( hand moves up a t f a s t s p e e d ) c u r r e n t s i g n a l = Up t u r n o f f Hover Mode v i a setSendParam ( ) record time of last mode set return I f ( two f i s t s above l e a p and no f i n g e r s ) c u r r e n t s i g n a l = Land t u r n o f f Hover Mode v i a setSendParam ( ) return I f ( c u r r e n t s i g n a l = Up , and enough time has p a s s e d s i n c e t i m e o f l a s t m o d e s e t ) c u r r e n t s i g n a l = Hover Turn on Hover Mode v i a SetSendParam ( ) i f Hover mode was o f f I f ( c u r r e n t s i g n a l = Down , and enough time has p a s s e d s i n c e t i m e o f l a s t m o d e s e t ) c u r r e n t s i g n a l = Hover Turn on Hover Mode v i a SetSendParam ( ) i f Hover mode was o f f I f ( c u r r e n t s i g n a l = Hover )

Update c u r r e n t p i t c h a c c o r d i n g t o L e a p s hand . d i r e c t i o n . y r e a d i n g Update c u r r e n t r o l l a c c o r d i n g t o L e a p s hand . p o s i t i o n . x r e a d i n g }

5.2

Main Control Function (the copter control thread)

m a i n c o n t r o l ( void param ) { While ( c y c l e ( c o p t e r ) ) Switch ( c u r r e n t s i g n a l ) case No S i g n a l : break ; case Up S i g n a l : s e t c u r r e n t t h r u s t t o u p t h r u s t and t a k e b a t t e r y l e v e l i n t o c o n s i d e r a t i o n r i s e ( ) helper function break ; case Down S i g n a l : s e t c u r r e n t t h r u s t to lower thrust descend ( ) h e l p e r f u n c t i o n break ; case Hover S i g n a l : s e t c u r r e n t t h r u s t to h o v e r t h r u s t for maintaining a l t i t u d e hover ( ) h e l p e r f u n c t i o n break ; case Land S i g n a l : i f c u r r e n t t h r u s t i s above 2 0 0 0 0 : r e d u c e c u r r e n t t h r u s t by a s m a l l l a n d i n g d e l t a land ( ) h e l p e r f u n c t i o n o t h e r w i s e c u r r e n t t h r u s t i s below 2 0 0 0 0 : switch c u r r e n t s i g n a l t o Grounded S i g n a l break ; case Grounded S i g n a l : s e t c u r r e n t t h r u s t to grounded thrust ground ( ) h e l p e r f u n c t i o n break ; }

5.3

Extension: Improving FSM for easier User Interaction

We designed an FSM model to allow more control over the copters movement. The improved FSM was incorporated into our baseline demonstration. The copters default ying mode is set to Hover, giving the user better control over pitch and roll at a current altitude, preventing unwanted jumps up or sudden drops due to the leaps sensitivity. Therefore, our copter ys around the room at a constricted plane in twodimensional space. To y at a higher or lower altitude, the leap looks for explicit Up and Down signals, which turns o Hover mode and changes the copters altitude without any forward/backward/left/right movements. After the change in altitude, the copter returns to Hover mode and is free to change pitch and roll.

Figure 2: Our FSM mostly operates in a Hover mode. Changes in altitude are initiated on the leap and switch the copter into Up or Down states followed where it stays for a short timeout period. Within Hover mode, the user can change pitch and roll with the leap, change altitude with Up / Down state switches, or Land the copter. Much like the Pre-Normal and Pre-Hover states in the sample FSM, we have a timeout period in the Up state or Down states to allow for the time it takes the copter to reach a new altitude. Up and Down movements cannot be interrupted and Landing is only possible if the copter is in Hover state.

Figure 3: Comparison of the two FSMs control over the copters height: In the simple example FSM, we can see the unpredictable height in (1) Normal Mode and its maintained altitude in (2) Hover Mode. Switch back to (3) Normal Mode, then (4) Hover Mode, and again to (5) Normal Mode which is required to land the copter. In our improved FSM, changes in altitude are purposeful and predictable. (1) A rise in altitude is initiated by a leap signal and after the copter returns to its default (2) Hover Mode. To achieve an even higher altitude, initiate an (3) Up motion again. Copter returns to (4) Hover Mode, a (5) Down signal reduces the altitude, and once that is completed, copter resumes (6) Hover Mode. With the extended FSM design we eectively reduce the dimension cardinality in the copters default ying state by one, increasing the users control over the copters movements but reducing the copters possible movement. We strongly feel that this is an improvement on the sample FSM and is more intuitive for a beginner user.

5.4

State Switches in the FSM

States As depicted in Figure 2, each square represents a state. There are 5 states in our FSM: (1) Hover: Pitch and Roll are constantly updated with readings from the positions of the hand in the leap. Thrust is frozen so the copters current altitude is maintained. This is the only state where Hover Mode (via SendParam function in CCie.ccp) is on. (2) Up: Copter rises by switching to a higher Thrust. Pitch and Roll are frozen so the copter only changes direction in height. (3) Down: Copter descends by switching to a lower Thrust. Pitch and Roll are frozen so the copter only changes direction in height. (4) Land: Copter descends by reducing its current Thrust by a small delta value until it reaches a low threshold Thrust. Pitch and Roll are frozen so the copter only changes direction in height. (5) Ground: Thrust, Pitch, and Roll are all set to 0. Switches 7

Switching between states is a result of inputs from the Leap Motion or automatic timeouts. Switches from automatic timeouts are designed so that the Up State and Down State have a standardized time to allow the copter to rise or descend an adequate amount before returning to Hover State. This logic also allows the copter to stay in the Landing state long enough so that the Current Thrust is decreased by some delta rather than immediately setting it to Ground States 0 value, avoiding a sudden drop and ensuring a more gradual landing. Switches from the leap allow the user to change the altitude of the copter. When driving in the Hover State, a leap signal can initiate a change to the Down or Up State in order to change the altitude for a period of time, then return to Hover State. The leap can signal a switch from the Ground State to Up State (using the same signal for Hover ? Up) which starts the copter. Automatic Timeout Switches: (1) Up to Hover: When an Up leap motion signal sends the copter to Up State, the start_time is recorded using the standard currentTime C function. We remain in Up State until currentTime minus start_time is larger than our Timeout constant (time in ms). Once we exceed our Timeout constant, the switch from Up to Hover is forced. (2) Down to Hover: Same process as the above switch. (3) Land to Ground: In the Land State, the copters thrust is updated as it decreases by a delta constant, land_delta. We update Current Thrust to be Current Thrust land_delta until it reaches a Low Threshold Thrust. At that point, setting the Current Thrust to 0 will not result in a dramatic drop in the copters altitude since it has been steadily decreasing by the land_delta. Thus, this is the point at which we switch from Land State to Ground State. Leap Motion Switches: (1) Hover to Up: If in Hover State, the user can switch to the Up State with a Leap Motion signal. User raises their hand vertically at a moderately fast speed. We check that the hand.position.y is hand.velocity.y are above preset thresholds. (2) Hover to Down: Similar to above, except the user moves their hand down at a fast speed so hand.position.y should be below a preset threshold. (3) Hover to Land: If in Hover State, the user can land their copter by holding two sts above the Leap Motion. We check that the number of hands in the frame is 2 and that the number of ngers is less than 1.

6
6.1

Extension: Intelligent Autonomous Flight

Ultrasound Proximity Sensor

We obtained an LV-MaxSonar-EZ0 ultrasound proximity sensor, which logs the sensors proximity to objects in front of it. For our extension, we attached this sensor to our nanocopter and programmed it for intelligent autonomous ight. Our copter is programmed to rise to a preset altitude, y forward several feet, then land. If an obstacle is detected at any point during this path, the copter evades the obstacle by increasing its altitude until it senses the obstacle is beneath it and cleared. The copter utilizes proximity readings to decide whether to move forward or evade during its attempt to execute its path forward.

6.2

Obtaining Proximity Readings

In order to use these vProx readings, we had to deal with hardware and software changes. On the hardware end, TA Tianlong assisted with the soldering of the sensor (three wires solder onto pins 20, 19, and 14). The proximity sensor was positioned to stand slightly upwards with the eye pointing forwards. The slightly upwards position accounts for the tilt that the copter has when it moves forward since the sensor is only accurate when it is exactly parallel to the ground during ight. On the software side, new rmware was installed. Once the rmware is ashed via BitCrazys CrazyFlie Client, we enabled reading of a parameter called vProx, which is a measure of the sensors proximity to objects directly in front of it. vProx is a oat ranging from 6.0000 (object touching the sensors eye) to 512.0000 (very far away from the sensor).

Firmware binary for the LV-MaxSonar-EZ0 is available at https://cfusting@bitbucket.org/cfusting/crazyiermware-proximity-sensor.

6.3

FSM for Obstacle Detection

We designed a Finite State Machine for the copter to rise, move forward a given amount feet, and land. There are only two input signals for the FSM (one to Start and another to Land). All decisions to move forward or evade are made by the copter based on proximity vProx readings, thus its ight is autonomous. These decisions are made after the copter Starts/Rises until the copter Lands, and during this time there is logic to switch between states of Evasion, Progression, and Conrmation.

Figure 4: Simple FSM for our autonomous intelligent ight. States As depicted in Figure 3, each square represents a state. There are 5 states in our FSM: (1) Rise: Copter rises by switching to a higher Thrust. Pitch and Roll are frozen so the copter only changes direction in height. This is a user input-initiated state that starts the autonomous ying. (2) Progress: Copter moves forward with positive pitch. Hover mode is on and the current altitude is maintained. No movements left or right. (3) Evade: Copter rises to try and clear a detected obstacle by increasing altitude so it can y over it. The copter also moves slightly backwards to counteract the residual forward movement from previous Progress State movement. (4) Conrmation: Copter maintains altitude and hovers in place with no forward/backwards/left/right movement. Several vProx readings are taken to conrm that an obstacle is in front of the sensor. See discussion below for more on Conrmation State. (5) Grounded: Thrust, Pitch, and Roll are all set to 0. Copter begins and ends at this state. (6) Landing (Not Pictured): Please refer to discussion of Landing State in our baseline FSM. There is an intermediate Landing state before the copter is truly Grounded so that there is a gradual decrease in Thrust 9

rather than a violent drop. We have not pictured it in Figure 3 for simplicity. Switches Like our baseline FSM, switching between states can be a result of inputs from the Leap Motion or automatic timeouts. However, most of the decisions are made as a result of calculated decisions. Like the baseline FSM, switches from automatic timeouts are designed so that the Rising Start State has a standardized time to allow the copter to increase its altitude an adequate amount before starting its autonomous ight. This logic also allows the copter to stay in the Landing state long enough as discussed in our baseline FSM. Switches from calculated decisions are designed so that the copter either progresses or evades an obstacle based on vProx readings. We do not guide or assist the copter with the Leap Motion to avoid collisions. Switches from the leap do not guide the copters autonomous obstacle detection. Instead, they are simple inputs to initiate the copter and land the copter when we are done. Automatic Timeout Switches: (1) Rise to Progress: When a Rise leap motion signal sends the copter to Rise State, the start_time is recorded using the standard CurrentTime( ) C function. We remain in Rise State until CurrentTime( ) start_time is larger than our Timeout constant (time in ms). Once we exceed our Timeout constant, the switch from Rise to Progress is forced. (2) Rise to Conrm: Same process as the above switch. Note: Choosing between the switch to Conrm or Progress is initiated after an automatic timeout. The decision to either enter Conrm or Progress is made based on the current vProx reading. If the vProx reading is above and Danger Zone Threshold, the copter switches to Progress. However, if the vProx reading is less than Danger Zone Threshold, the low reading might indicate an obstacle in which case the copter switches to Conrm. Calculated Decision Switches: (1) Progress to Progress: If the copter is currently in Progress State and the vProx reading is above the Danger Zone Threshold, we assume no obstacles are nearby and re-enter the Progress State. (2) Progress to Conrm: If the copter is currently in Progress State but the vProx reading is below the Danger Zone Threshold, we might have an obstacle nearby and we enter a Conrm State. (3) Conrm to Progress: In a Conrm State, if the copter concludes that no obstacles are nearby, we return to Progress State (more on Conrm in the next section). (4) Conrm to Evade: In a Conrm State, if the copter concludes that there are obstacles nearby, we enter the Evade State (more on Conrm in the next section). (5) Evade to Evade: If the copter is currently in Evade State and the vProx reading is below the Danger Zone Threshold, we still have obstacles nearby and re-enter the Evade State. (6) Evade to Progress: If the copter is currently in Evade State but the vProx reading is above the Danger Zone Threshold, we do not have an obstacle nearby and we can now go to Progress. Leap Motion Switches: (1) Grounded to Rise: To start the copter, the user can switch to the Rise State with a Leap Motion signal. User raises their hand vertically at a moderately fast speed. We check that the hand.position.y is hand.velocity.y are above preset thresholds. (2) Progress / Conrm / Evade to (Landing) to Grounded: At any point during autonomous ight, if the user wishes to end the copters path they can initiate a Land by holding two sts above the Leap Motion. Like the baseline FSM, we check that the number of hands in the frame is 2 and that the number of ngers is less than 1.

6.4

Conrm State: Compensating for Volatile Readings

The Ultrasound proximity sensor is extremely sensitive and volatile. vProx readings range from 6.0000 to 512.0000 and are measured every 20 ms. There are often spikes in readings, and for an object with a true vProx reading at 80.0000 away, the sensor might read: 80.0000 81.0000 82.0000 10

80.0000 150.0000 151.0000 18.0000 80.0000 81.0000 80.0000 Notice, each number is recorded every 20 ms and there is an erroneous reading in the middle. This becomes an issue when we are deciding whether to Progress or Evade based on one vProx reading. To compensate for the frequent errors in the proximity sensor, we do not measure one vProx reading and compare it to our Danger Zone Threshold. Instead we read three vProx readings every 100 ms and take the minimum out of the three to base our Progress or Evade calculated decision. The copter spends time in this Conrmation State to allow time to take the three readings 100 ms apart. As a result, we sample multiple vProx readings and make a more educated decision about whether or not an obstacle is in front of the copter. By taking the minimum, we err on the side of caution and possibly enter Evade State when it is indeed safe to Progress. However, we successfully ensure that the copter will not go to Progress when it really should be in Evade from a nearby obstacle.

7
7.1

Pseudo Code
On Frame Function

onFrame ( l e a p c o n t r o l l e r r e f c o n t r o l l e r , void u s e r i n f o ) { I f ( c u r r e n t s i g n a l = Grounded , and hand moves up a t f a s t s p e e d ) c u r r e n t s i g n a l = Rise / Start record start time I f ( c u r r e n t s i g n a l = R i s e / S t a r t and enough time has p a s s e d s i n c e s t a r t t i m e ) I f ( vProx i s w i t h i n d a n g e r z o n e ) switch c u r r e n t s i g n a l t o Confirm o t h e r w i s e vProx i s not i n d a n g e r z o n e switch c u r r e n t s i g n a l t o P r o g r e s s I f ( c u r r e n t s i g n a l = P r o g r e s s , Evade , o r Confirm and Leap d e t e c t s two f i s t s ) s e t c u r r e n t t h r u s t to lower landing thrust s e t c u r r e n t s i g n a l t o Landing }

7.2

Main Control Function

m a i n c o n t r o l ( void param ) { While ( c y c l e ( c o p t e r ) ) r e a d vProx r e a d i n g Switch ( c u r r e n t s i g n a l ) Case S t a r t S i g n a l : s e t c u r r e n t t h r u s t to up thrust d i s a b l e c u r r e n t p i t c h ( s e t i t t o 0 , o r t r i m p i t c h v a l u e f o r no movement ) d i s a b l e c u r r e n t r o l l ( s e t i t t o 0 , o r t r i m r o l l v a l u e f o r no movement )

11

break ; case P r o g r e s s S i g n a l : s e t c u r r e n t t h r u s t to h o v e r t h r u s t s e t c u r r e n t p i t c h to forward pitch disable current roll I f ( vProx i s w i t h i n d a n g e r z o n e ) switch c u r r e n t s i g n a l t o Confirm record start time s e t c u r r e n t t h r u s t to hover thrust disable current pitch disable current roll

o t h e r w i s e vProx i s not i n d a n g e r z o n e keep c u r r e n t s i g n a l i n P r o g r e s s break ; case Evade S i g n a l : s e t c u r r e n t t h r u s t to up thrust s e t c u r r e n t p i t c h to c o u n t e r p o s i t i v e p i t c h disable current roll I f ( vProx i s w i t h i n d a n g e r z o n e ) keep c u r r e n t s i g n a l i n Evade o t h e r w i s e vProx i s not i n d a n g e r z o n e switch c u r r e n t s i g n a l t o P r o g r e s s break ; case Confirm S i g n a l : i f 100 ms s i n c e s t a r t t i m e has p a s s e d r e c o r d vProx2 i f 200 ms s i n c e s t a r t t i m e has p a s s e d r e c o r d vProx3 t a k e t h e min o f vProx1 , vProx2 , and vProx3 switch c u r r e n t s i g n a l t o Evade i f t h e min i s w i t h i n d a n g e r z o n e switch c u r r e n t s i g n a l t o P r o g r e s s i f not w i t h i n d a n g e r z o n e i f not 200 ms s i n c e s t a r t t i m e then c u r r e n t s i g n a l i s s t i l l i n Confirm s t a t e break ; case Land S i g n a l : i f c u r r e n t t h r u s t i s above 2 0 0 0 0 : r e d u c e c u r r e n t t h r u s t by a s m a l l l a n d i n g d e l t a land ( ) h e l p e r f u n c t i o n o t h e r w i s e c u r r e n t t h r u s t i s below 2 0 0 0 0 : switch c u r r e n t s i g n a l t o Grounded S i g n a l break ; case Grounded S i g n a l :

12

s e t c u r r e n t t h r u s t , c u r r e n t p i t c h , and c u r r e n t r o l l t o 0 break ; }

Conclusion

From our personal experience, the most challenging part about this assignment was actually not the coding but rather getting acquainted with the hardware involved, installing all the necessary dependencies, and familiarizing ourselves with the libraries and APIs that allow software development for the Crazyie. In typical programming assignments everything about the way the program functions is understood since the student is responsible for coding the program in its entirety. This project taught us a new set of skills: how to hack into a blackbox and understand enough about its inner mechanisms to use it for our specic purposes. We also learned a lot about how one can hack hardware by adding components to expand its capabilities. Weve demonstrated this by adding an ultrasound sensor to the Crazyie which allowed it to perform intelligent autonomous ight. The second biggest challenge was programming our copter to y with the additional weight of the sensor. Since the sensor weighs 5 grams, we had to perform many tests to adjust the thrust values so that the copter would hover, rise, and descend in a controlled manner. The weight of the sensor also caused the copter to lose battery life very quickly. We also noticed that due to the weight of the sensor, the copter had a harder time stabilizing unlike copters without sensors attached. Thus, upon rising from the ground, the copter must spend some time hovering back and forth in the air to stabilize itself with the added weight before it can perform controlled ight. Another fun extension that we could do given more time and resources would be to attach a sensor that is able to detect objects all around the copter and not just those directly in front of it. This would essentially give the copter 360 degrees of vision and allow the copter to move in any direction autonomously without colliding into objects.

13