About Me

My name is Taylor Welker, and I am a Masters Student working as a Research Assistant at the University of Utah.  My advisor is Dr. Tom Henderson in the School of Computing and we are working to help develop an intelligent system for autonomous planning and control of quadcopters.

My role in the research team is to develop the infrastructure for testing this system.  Specifically, I have been over handling hardware related to the quadcopter, as well as for developing both 2D and 3D simulations that can be used to visualize the effectiveness of our methods.

My academic interests are centered around the development of intelligent systems.  Some of my favorite classes so far in my Masters Program include Artificial Intelligence, Machine Learning and Motion Planning.

About the Project

The purpose in creating these Gazebo simulations is to prove the concepts that make up our BRECCIA system.

BRECCIA is an intelligent GIS tool that is designed to assist users in gathering and processing information utilizing autonomous quadcopters.  It contains a database of beliefs, desires and intentions (a BDI framework) and uses it to make decisions on how best to achieve its goals.  If there is uncertainty within the database, it follows a set of plans to try and resolve them.

To read more about our project, please refer to these publications below:

``BRECCIA: A Multi-Agent Data Fusion and Decision Support System for Dynamic Mission Planning,'' David Sacharny, Thomas C. Henderson, Amar Mitiche, Robert Simmons, Taylor Welker and Xiuyi Fan, 2nd Conference on Dynamic Data Driven Application Systems (DDDAS 2017), Cambridge, MA, 7-9 August, 2017.

``BRECCIA: Unified Probabilistic Dynamic Geospatial Intelligence,'' David Sacharny, Thomas C. Henderson, Amar Mitiche, Robert Simmons, Taylor Welker and Xiuyi Fan, IEEE Conference on Intelligent Robots and Systems (IROS 2017 Late Breaking Paper), Vancouver, Canada, 24-28 September, 2017.

``A Probabilistic Logic for Multi-source Heterogeneous Information Fusion,'' Thomas C. Henderson, Robert Simmons, Amar Mitiche, Xuiyi Fan and David Sacharny, IEEE Conference on Multisensor Fusion and Integration, Daegu, South Korea, 15-18 November, 2017.

``BRECCIA: A Novel Multi-source Fusion Framework for Dynamic Geospatial Data Analysis,'' David Sacharny, Thomas C. Henderson, Robert Simmons, Amar Mitiche, Taylor Welker and Xiuyi Fan, IEEE Conference on Multisensor Fusion and Integration, Daegu, South Korea, 15-18 November, 2017.

``Probabilistic Logic for Intelligent Systems,'' Thomas C. Henderson, Robert Simmons, Bernard Serbinowski, Xiuyi Fan, Amar Mitiche, and Michael Cline , International Conference on Intelligent Autonomous Systems, Baden-Baden, Germany, 11-15 June, 2018.

Starting Dronekit-Python

The Command

python ~/dronekit-python/examples/SimMission/SimMission.py --connect 127.0.0.1:14552

Notes

*Be sure to replace "~/dronekit-python/examples/SimMission/SimMission.py" with the filepath to the script you've decided to use.

*Notice how it is connecting to 127.0.0.1:14552, which is one of the ports supplied by Mavproxy (see Starting Mavproxy for details).

*Remember, when Dronekit-Python starts, it searches for an available quadcopter for 30 seconds.  If it can't find one in that time, or loses connection with the quad for that amount of time, it shuts down automatically.  So be sure to have SITL, Mavproxy (and Gazebo if you are using it) running before you start Dronekit-Python.

Starting Mavproxy

The Command

mavproxy.py --master=udp:127.0.0.1:14550 --out=udpout:192.168.0.100:14550 --out=udpout:127.0.0.1:14552 --out=udpout:127.0.0.1:14553


Notes

*I am pretty sure that this represents the default UDP ports that SITL uses if there is one quad in the simulation.  These numbers will change if you try to use more than one.

*For each quadcopter you want to control, you will need another Mavproxy with slightly different UDP ports.

*"--master" is the udp port that Mavproxy is listening to, and the "--out" port are where it sends that information to.  The first "--out" statement is reserved for a special purpose (I think it has something to do with the ip address being starting with 192 rather than the local machine's 127), so we use the second two "--out" statements when starting Dronekit-Python

Starting Ardupilot

The Command

python ~/ardupilot/Tools/autotest/sim_vehicle.py -v ArduCopter -f gazebo-iris --console -L $LOCATION -m --mav10 -I0

Note on GPS initialization

This should start SITL and link it to an available iris quadcopter in Gazebo.  You just have to replace '~' with the filepath to where you downloaded the ardupilot folder from GitHub, and $LOCATION with a certain codename.

GPS is critical to navigating our quadcopter in the simulation.  Therefore, we need to choose a single  GPS source to work from, and sync SITL and Gazebo's coordinate systems so that they both believe that the quadcopter is at the same location. In our simulation, we decided to use the GPS tied to SITL rather than another external one that could be installed into the Gazebo simulation (like 'hector').

We then need to override Gazebo's default behavior (to make the origin represent 0 latitude and 0 longitude).  To do this, we will add a line to ardupilot/Tools/autotest/locations.txt.  This file contains a list of names with corresponding lat, lon, alt specifications.  Create a new name at the bottom of the file, and give it the desired GPS location that you want the origin of your Gazebo simulation to represent.  Then, using the command above, replace $LOCATION with the name you chose for that location.  This will make sure SITL and Gazebo are on the same page with their coordinate systems.

Other Notes

*The "-I0" tells SITL which quadcopter we are starting.  For example, if we have two quadcopters in our simulation, then you would need two of these statements, one ending in -I0, and the other ending in -I1.  The IDs of these quadcopters are 0 and 1 respectively.  There is a spacing of "10" in between UDP ports that these quadcopters will use with each new quadcopter.  For example, if I0 uses a UDP port of 14550, then I1 would use a UDP port of 14560 and I2 would use 14570 see Starting Mavproxy for more details on this topic.

*If you are starting SITL fresh or after a "wipe" (the -w flag), it may have to reload all of its parameters. In this case it can take a little time (30 seconds or so) to initialize.

Starting Gazebo

The Command

GAZEBO_RESOURCE_PATH="$GAZEBO_RESOURCE_PATH:/usr/share/gazebo-9/worlds" gazebo --verbose /usr/share/gazebo-9/worlds/$WORLD_FILE

Notes

*The "GAZEBO_RESOURCE_PATH" stuff just tells gazebo to look in "/usr/share/gazebo-9/worlds" in addition to wherever else it looks for resources when building the world.

*In case this wasn't clear in this format, this command is all one line.  The first part (up to 'worlds" ') is for adding the folder to the Resource path, while "gazebo --verbose" onward is actually starting gazebo and loading it with the world specified after it.

*You will have to modify the filepaths to fit your installation, as well as replacing $WORLD_FILE with the name of your .world file.

*If you want to use an example, I would recommend iris_irlock_demo.world.  This should come with your gazebo install and can be found in your worlds folder.

Dronekit-Python

Installation Tutorial

http://python.dronekit.io/develop/installation.html

Purpose

Dronekit-Python is a library of Python code that allows you to send commands to the simulated quadcopter using a Python Script (as opposed to Ardupilot's clunkier command line interface).  This will allow you to write your own Python code to manipulate the behavior of the quad how you see fit. 

For example, I use 3 different scripts depending on the situation: one to allow the user to have manual control over the quad, one to allow the quad to follow a mission in AUTO mode, and one similar to the second, but uses GUIDED mode so that it can change its mission at any time throughout the simulation (but this last one is a topic for another post).

Things to Note

*Be sure to use the examples that come with the Dronekit-Python repository.  These can be modified to fit your needs and can you teach you how to do things like takeoff or navigate to a new position.

*Dronekit-Python's connect function has a default timeout of 30 seconds.  If it cannot find the UDP port corresponding to an available quadcopter (either real or simulated), it will close the program.  If your SITL program has to initialize many parameters, then you might have to consider adding sleep statements or delays to ensure that SITL has enough time to get started before launching Dronekit-Python.

*AUTO mode does not allow anything to dynamically alter the mission stored in the quadcopter.  The quad must first land and disarm its motors before saving a new mission into the quadcopter.  From there, it can take off, and enter AUTO mode again.  This is the advantage of "GUIDED" mode over "AUTO": you can take control of the quad at any point and tell it to do something different.

*The weakness to "GUIDED" mode is that it takes constant input and cannot simply take in a mission file and complete it autonomously like in "AUTO" mode.  In our project, we want to be able to have the quadcopter complete a mission automatically, but also be able to change its mission if the BRECCIA server prompts it to, even while it is in the air.  That is why I designed a dynamic planner in Python.  This planner can receive new missions from our BRECCIA server (which uses Java), and then parse these mission files, sending them to the quadcopter one after the other while it is in "GUIDED" mode.

*Dronekit-Python can only affect the quadcopter's state.  It cannot change the environment (things like wind speed or direction).