RE: Gantt Chart Link —11/8

Feedback:

1. The first part of Gannt chart is decent. You can just start working on your project accordingly.
2. The sencond part of the Gantt chart is obviously missing probably due to the limited understanding of the task. I suggest that you revise it while you are working on the first part. and notify me through email when you are done.

Gantt Chart Link —11/8

Gantt Chart — 11/8

Since so far we are both doing the same things, we are not assigned separate tasks.

The Air Force Collaboratory: Mind of a Quadrotor

The Air Force Collaboratory launched a quadrotor project two years ago. The goal is to develop an autonomous quadrotor that can think and make decision by itself like a human.

The program has mostly closed already. However, there are some general information and discussion on the website, which may be of interest to you. Please click the link and browse through the site for further info.

Presentation 1 Link

Presentation 1

RE: Initial Planning & Coordination

Project Description

• We are aiming to create a system by which a drone can autonomously fly in an indoor environment and deliver packages between specified locations.
• Though this has essentially already been done by others, this project could potentially help implement this system in ElRo and further the practical knowledge and experience of our group members.
• You can still improve the performance of the vision-based navigation by improving the algorithms.

Communication

• Team: Owen G., Theo C. We communicate by texting and google docs.
• Group: Our group is fairly independent. Though the drone take-down teams are related to ours in that we share the same equipment, we shouldn’t really need to communicate very much (if needed, email should suffice).

• You can copy Theo's comments here for the Prior Work/Resource Inventory.

Tech Analysis

• Navigate Linux
• Run AR Drone SDK examples
• Edit AR Drone SDK examples
• Navigate AR Drone SDK
• Use OpenCV
• Incorporate OpenCV in AR Drone SDK

Competence

• What we already know:
• Minor experience in C
• What we don’t already know:
• Experience in Linux
• Experience with the AR Drone
• Experience with the SDK
• Running examples
• Editing examples
• Experience with OpenCV
• Further knowledge of C programming

Safety

• Flying the drone offers a safety hazard; we need open, unoccupied spaces to test the flight of the drone.

Equipment, Materials, Budget

• Parrot AR Drone (already purchased)
• AR Drone SDK (free)
• OpenCV (free)
• Computer with Linux OS (free)

Schedule

• This week we want to focus on having everything working as it was when the previous group finished. We want to run the SDK examples sdk_demo and navigation, as well as run the OpenCV application created by last year’s group on both of our computers. If we run into any problems, we want to resolve them by the end of this week.
• We also, at the same time, want to work on our gantt chart. However, if it was not intended that we jump into the project yet, we can just try to finish the gantt chart before starting.
• The first task will be done by both of us, and the second (gantt chart) will be edited by both of us, but I will share the gantt chart.

• Research project planning is more like an iterative process, especially for beginners. The more you jump into the project, the more solid your planning will be. So, go ahead!

Initial Planning and Coordination

Project Description

• We are aiming to create a system by which a drone can autonomously fly in an indoor environment and deliver packages between specified locations.
• Though this has essentially already been done by others, this project could potentially help implement this system in ElRo and further the practical knowledge and experience of our group members.

Communication

• Team: Owen G., Theo C. We communicate by texting and google docs.
• Group: Our group is fairly independent. Though the drone take-down teams are related to ours in that we share the same equipment, we shouldn’t really need to communicate very much (if needed, email should suffice).

Tech Analysis

• Navigate Linux
• Run AR Drone SDK examples
• Edit AR Drone SDK examples
• Navigate AR Drone SDK
• Use OpenCV
• Incorporate OpenCV in AR Drone SDK

Competence

• What we already know:
• Minor experience in C
• What we don’t already know:
• Experience in Linux
• Experience with the AR Drone
• Experience with the SDK
• Running examples
• Editing examples
• Experience with OpenCV
• Further knowledge of C programming

Safety

• Flying the drone offers a safety hazard; we need open, unoccupied spaces to test the flight of the drone.

Equipment, Materials, Budget

• Parrot AR Drone (already purchased)
• AR Drone SDK (free)
• OpenCV (free)
• Computer with Linux OS (free)

Schedule

• This week we want to focus on having everything working as it was when the previous group finished. We want to run the SDK examples sdk_demo and navigation, as well as run the OpenCV application created by last year’s group on both of our computers. If we run into any problems, we want to resolve them by the end of this week.
• We also, at the same time, want to work on our gantt chart. However, if it was not intended that we jump into the project yet, we can just try to finish the gantt chart before starting.
• The first task will be done by both of us, and the second (gantt chart) will be edited by both of us, but I will share the gantt chart.

Resources:

— On simultaneous localization and mapping:
http://www.nickd.nl/dl/thesis_Nick_Dijkshoorn.pdf 
— On using openCV within the SDK to stream video from the drone to a computer: 
http://petrkout.com/linux/parrot-ardrone-2-0-video-streaming-through-opencv-in-linux
— On using the special ROS to code the drone:
http://robohub.org/up-and-flying-with-the-ar-drone-and-ros-getting-started/
— A tutorial for programming the AR.Drone (communication syntax):
http://www.robotappstore.com/Knowledge-Base/Programming-ARDrone/101.html
— More info on the drone-computer communication
https://www.objc.io/issues/8-quadcopter/communicating-with-the-quadcopter/
https://abstract.cs.washington.edu/~shwetak/classes/ee472/assignments/lab4/drone_api.pdf
— Processing to communicate using UDP in oscP5 library
http://www.sojamo.de/libraries/oscp5/
— Processing to communicate using AR Drone library
http://kougaku-navi.net/ARDroneForP5/index_en.html
— Float to binary conversion
http://kipirvine.com/asm/workbook/floating_tut.htm
— SDK Understanding
http://gauth.fr/2011/09/introduction-to-the-ar-drone-sdk/
http://www.warp1337.com/content/ardrone-20-install-sdk-and-fly-2-minutes-ubuntu-linux-1210
http://www.ardrone-flyers.com/forum/viewtopic.php?t=83

Resource from Last Year

Team Progress Report Blog: http://advstem1.blogspot.com/
Project Resource including Gantt Chart: http://stem14-15.blogspot.com/2015/02/project-resource-drone-delivery-system.html

Missing Initial Planning and Coordination

Your team has missed the deadline of posting "Initial Planning and Coordination". Please make it up ASAP.

More Notes: Process Ideas

Method

• The client gives a compiled list of commands to follow. The commands could be directions.
• directions are of two types (each corresponding to yaw changes):
• Left   (Ø°)
• Right (Ø°)
• at each corner is a tag (preliminarily a color, later a unique tag to match)
• the direction indicates which tag to seek next
• TEST: wall tags vs. floor tags?
• wall tags are simpler to find (only frontal camera)
• floor tags are more adaptable (not every corner ends with a wall)

AR.Drone Programming Protocols

• In case the packet contains more than one command, the new line byte \r 0x0A is used to separate the commands.
• Strings are encoded as 8-bit ASCII characters
• The maximum length of the command is 1024 characters
• 30 MS delay must be passed between the commands
• Commands should be no more than 2 seconds apart (continuous commands is better)
• The client must use the host AT command port to communicate 
• See developer guide, sec.6 for more on AT command syntax
• The IP address of the drone is 192.168.1.1 and there are three ports we can use to connect over UDP:
• Navigation Data Port = 5554
• On-Board Video Port = 5555
• AT Command Port = 5556

• AT*FTRIM = #<LF>                                                                
• Command for horizontal calibration (flat trim)
• #=1 
• LF = return character
• AT*REF = #,0001000101010100000000†§00000000<LF>   
• Argument 1 is sent as an integer (written here is its derivative binary form).
• §(1=change)(0=stay|stopEmergency)
• †(1=upUntilLifted)(0=downUntilLanded) 
• AT*PCMD = #,€,R,P,G,Y<LF>
• €(1=readCommands)(0=hover)
• R(-1,1 = roll)
• P(-1,1 = pitch)
• G(-1,1 = gaz)
• Y(-1,1 = yaw)
• -1,1 = float corresponds to %age of preset power range, in the format of its equivalent integer.
• AT*LED = #,@,F,D<LF>
• @ = predefined animation tag number (int 0-20)
• F = frequency (delay between commands)
• D = duration (number of times)

Resources

— A tutorial for programming the AR.Drone (communication syntax):

http://www.robotappstore.com/Knowledge-Base/Programming-ARDrone/101.html

— More info on the drone-computer communication

https://www.objc.io/issues/8-quadcopter/communicating-with-the-quadcopter/

https://abstract.cs.washington.edu/~shwetak/classes/ee472/assignments/lab4/drone_api.pdf

— Processing to communicate using UDP in oscP5 library (I would prefer something like
     this, as I am familiar with Processing)

http://www.sojamo.de/libraries/oscp5/

— Processing to communicate using created AR Drone library (if previous resource's option
    doesn't work)

http://kougaku-navi.net/ARDroneForP5/index_en.html

— Float to binary conversion (for commands, float > binary > integer is a necessary conversion)

http://kipirvine.com/asm/workbook/floating_tut.htm

To Research Next

• Receiving drone's navdata
• Receiving drone's video
• Image matching
• Color-searching