EADDDAS

Look ma, no hands!

Anonymous — Fri, 26 Jun 2015 06:02:49 +0000

Look ma, no hands! Anonymous (not verified) Fri, 06/26/2015 - 00:02

Now that the EA-DDDAS framework has been put through the paces, we're planning two days of flight testing that allow the system operate fully autonomously. This means that the high-level planner and trajectory optimization layer will be left to their own devices to communicate, generate energy-aware trajectories, and send seamlessly stitched trajectories to the aircraft in real-time. The goal is to have no user intervention once the system has been launched and a goal has been set. We're planning to use the decommissioned Reese airfield to conduct flights upwards to 1.75 km away from the ground station using stationed observers who are always in communication with the pilot in command.

One of the recent challenges faced in the field was the ability (or lack thereof) to continuously send new trajectories to the PixHawk autopilot without causing the aircraft to RTL (return to loiter). Since the planners are generating paths ahead of the aircraft position, a method was needed to feed the trajectories to the aircraft with the correct timing. An additional constraint was the number of waypoints that are manageable on-board the aircraft. Since we use a 900 MHz radio link for long distance command and control, data rates are slow and packets are often lost during transfer. We found that a 100 waypoint plan is workable with the given data rates we see over the 900 link. With this in mind, we designed a circular buffer mission plan algorithm that allows trajectories to be continuously updated to the aircraft. Using a partial write command, we update certain ranges in the 100 waypoint plan. If a plan goes beyond the 100 waypoint limit, the plan is broken into two plans that wrap around back to the 1st waypoint using a DO_JUMP command. While this works well, it introduces another issue. If plans are being generated too quickly for the aircraft to follow, a queue will develop. To prevent this queue from over-writing points that the aircraft still needs to fly, the MISSION_CURRENT MavLink message is checked to see where the aircraft is in the circular buffer. This provides the necessary logic to delay the next waypoint write so only old waypoints are overwritten!

Sorry for the lack of generated optimal trajectory pictures so far, we haven't had a chance to dig through all of the logged data. Once we're back in CO, we'll be sure to have some results up ASAP.

Off

Traditional

White

Successful System Test!

Anonymous — Tue, 23 Jun 2015 19:29:50 +0000

Successful System Test! Anonymous (not verified) Tue, 06/23/2015 - 13:29

We've flown a full system test with data flow originating from the dual-doppler radar synthesis, feeding the energy-aware path planner resulting in plans sent accordingly to the PixHawk autopilot on-board the Tempest aircraft. Several different radar and atmospheric planner configurations were tested today to see how the aircraft performance varied with the different types of wind data. Data is currently being processed but some more of the interesting trajectories will be posted later this week. For now, check out a POV video of our Tempest aircraft (the loop was NOT an energy-optimal path!)

[video:https://www.youtube.com/watch?v=W5pUZ4PWlMk]

Off

Traditional

White

End of Week 1

Anonymous — Mon, 22 Jun 2015 03:35:18 +0000

End of Week 1 Anonymous (not verified) Sun, 06/21/2015 - 21:35

Sorry for the lack of updates, things have been very busy here in Lubbock. We've run into a bunch of unforseen challenges along the way, but it wouldn't be an engineering field deployment if everything went perfectly the first time! Since our first week of the deployment has come to a close, we can recap our successes and what lies ahead for week 2.

For the first week, we successfully:

1. Collected and synced dual-doppler synthesis data

2. Ran this data through an Online Atmospheric Planner algorithm

3. Transferred this data to a MongoDB operating in the field

4. Connected a high-level graph planner with the trajectory optimization layer

5. Submitted energy-optimal paths to the aircraft in real-time (and flew them in AUTO mode)

6. Fixed a whole lot of bugs!

While the system still hasn't been run in its entirety, we are excited that the 2nd week will be more testing and less troubleshooting. Monday will contain another attempt to link every component of the EA-DDDAS and submit some loitering trajectories to the aircraft. These will be compared to simple "flat" circular trajectories to evaluate the efficacy of flying energy-optimal trajectories.

The Tempest has been flying great thanks to our excellent and dedicated flight crew. Spirits remain high as we are excited and optimistic about the flight tests that lay ahead.

That's all for now, I'll try to update more frequently this week to give a day-by-day breakdown of our progress.

Off

Traditional

White

Deployment Update

Anonymous — Wed, 17 Jun 2015 18:28:21 +0000

Deployment Update Anonymous (not verified) Wed, 06/17/2015 - 12:28

The EA-DDDAS systems are being tested and steadily coming online. We successfully received Ka-doppler data, advanced the wind field through an online forecast system, and recorded the wind field to a MongoDB system operating in the field. This database is accessed in real-time by the trajectory optimization layer as well as the lattice planner. With a new set of forecasts being generated every three minutes, there's a lot of data to capture and index!

The Tempest/PixHawk platform has completed a successful flight test this morning and tested some key network and antenna tracker systems. If all goes well, tomorrow should be the first complete field test of the EA-DDDAS flight system. The recent tropical storm Bill that made landfall yesterday has spoiled a bit of the intereting wind shear pattern we are hoping to fly in. Fortunately, this calm will air will move on as the storm progress north towards Oklahoma. To give you an idea of the stillness, the radar reported a max East wind speed of 5 m/s at 100 meters altitude.

The next few days of testing should be pretty exciting: generating energy-aware trajectories using real-time wind field data and sending them to the aircraft to fly! Fingers are crossed for a favorable wind shear that we can play in.

More news to follow tomorrow after flight testing!

Off

Traditional

White

FAA grants RECUV COA for Texas and Oklahoma panhandles for severe weather research

Anonymous — Thu, 28 May 2015 23:12:01 +0000

FAA grants RECUV COA for Texas and Oklahoma panhandles for severe weather research Anonymous (not verified) Thu, 05/28/2015 - 17:12

RECUV has received permission from the Federal Aviation Administration to start flying the Tempest UAS over parts of Texas and Oklahoma this spring in the heart of Tornado Alley to conduct weather research. The new “southern COA” complements the 48,000-square-mile “northern COA” previously granted by the FAA that covers portions of Colorado, Kansas, Nebraska and Wyoming. The northern and southern COA’s together cover an area about the size of Colorado. The Tempest is an Unmanned Aircraft System (UAS) with a wingspan of more than 10 feet developed at CU-�鶹ӰԺ to better understand the origin and development of severe storms by flying to their edges and measuring air pressure, temperature, relative humidity and wind velocities.

Off

Traditional

White

MAVLink Protocol: Waypoints

Anonymous — Mon, 25 May 2015 23:42:01 +0000

MAVLink Protocol: Waypoints Anonymous (not verified) Mon, 05/25/2015 - 17:42

During the EA-DDDAS deployment this summer we'll be flying a Tempest with a PixHawk autopilot on-board. The PixHawk uses the well-known MAVLink protocol released by Lorenz Meier over at ETH Zürich. The protocol was designed to be language and (mostly) hardware agnostic which is great for portability but this means there isn't much existing framework to write your own simple programs to interface with the PixHawk. While the recently refreshed DroneKit released by 3DR includes a Python implementation (DroneAPI), it only runs as a MAVProxy module. This can be an issue if the code is running on a small supervisory computer like a Raspberry Pi because MAVProxy isn't terribly efficient. We prefer to use MAVProxy as a learning tool that provides a starting point to implementing our own PyMAVLink solution.

We've been developing a Python class for EA-DDDAS that implements a basic waypoint send functionality. Through mavutil.py and mavwp.py, the PyMAVLink library provides the required commands to form and send waypoints. Before diving into some code, it's important to understand how MAVLink accepts a set of waypoints. The sender intializes the request by sending a WAYPOINT_COUNT(N) message to the PixHawk. N represents the number of waypoints that will be sent. The PixHawk responds in turn by asking for the first waypoint through a MISSION_REQUEST(WP) message where WP is the waypoint index it's going to wait for. This process goes back and forth until the PixHawk receives the Nth waypoint and sends an ACK command to tell everyone involved that the transaction is finished.

Here is what it looks like in Python (connected to the ArduPilot SITL):

The code assumes you have a three tuples called "lat", "lon", and "alt" which are "N" long.

Sending waypoints with PyMAVLink

from pymavlink import mavutil, mavwp
master = mavutil.mavlink_connection('udp:localhost:14551')
master.wait_heartbeat(blocking=True)
wp = mavwp.MAVWPLoader()
seq = 1
frame = mavutil.mavlink.MAV_FRAME_GLOBAL_RELATIVE_ALT
radius = 10
for i in range(N):
wp.add(mavutil.mavlink.MAVLink_mission_item_message(master.target_system,
master.target_component,
seq,
frame,
mavutil.mavlink.MAV_CMD_NAV_WAYPOINT,
0, 0, 0, radius, 0, 0,
lat[i],lon[i],alt[i]))
seq += 1

master.waypoint_clear_all_send()
master.waypoint_count_send(wp.count())

for i in range(wp.count()):
           msg = master.recv_match(type=['MISSION_REQUEST'],blocking=True)
           master.mav.send(wp.wp(msg.seq))
           print 'Sending waypoint {0}'.format(msg.seq)

The basic procedure is as follows:

1. Establish a UDP connection to the aircraft

2. Listen for a heartbeat to make sure we're receiving MAVLink messages

3. Create a waypoint (wp) object and populate it with lat,lon,altitudes

4. Send a clear all waypoints command to the PixHawk

5. Send a MISSION_COUNT(N) to the PixHawk

6. Listen for MISSION_REQUEST messages and sent the appropriate waypoint

7. Repeat step 6 until complete

Whew! PyMAVLink is a great library, but it's still not the easiest to use. Something to note is that MAVLink has two released versions of the protocol: 0.9 and 1.0. This code assumes v1.0 and uses the "MISSION_REQUEST" message. In v0.9, this would be "WAYPOINT_REQUEST".

Cheers for now!

Off

Traditional

White

Introducing the Trajectory Optimization Layer

Anonymous — Thu, 14 May 2015 20:28:33 +0000

Introducing the Trajectory Optimization Layer Anonymous (not verified) Thu, 05/14/2015 - 14:28

The Trajectory Optimization Layer (TOL) is a middleware component of the EA-DDDAS aircraft control system. It resides below the extended time-horizon path planner and above the aircraft path following controller. It's primary responsibility is generating energy-aware optimal flight trajectories in real-time using measured data of the wind environment.

By harnessing the wind energy already present in the storm environment, these energy-aware trajectories could extend the range and endurance of sUAS, especially in severe weather applications. The TOL is one of the primary EA-DDDAS components being tested this summer in Lubbock, TX.

At the moment, the TOL is capable of generating and stitching together several guidance trajectories (point A to point B flight) and sending this optimized path to the Pixhawk autopilot on-board the aircraft via a network link. Given a latitude, longitude, and altitude goal, the TOL logic hashes up the path to the goal into several smaller chunks which are then optimized individually and seamlessly stitched together. The goal of this software is to handle any goal provided to it (within a reasonable distance) and provide the aircraft with a single stitched trajectory to that goal. The code can also output KML and JSON versions of the trajectory so it can be viewed in Google Earth as the code runs (see picture).

Upcoming work includes developing a python wrapper for loitering-class trajectories (staying in or around a pre-designated region), testing the TOL within a software-in-the-loop system, and decreasing optimization times by pre-allocating wind data from the MongoDB server.

Stay tuned!

Off

Traditional

White

Welcome to RECUV Field Notes

Anonymous — Fri, 10 Apr 2015 22:17:30 +0000

Welcome to RECUV Field Notes Anonymous (not verified) Fri, 04/10/2015 - 16:17

This is where we will be providing the latest news and updates on our EA-DDDAS field deployments this June in Lubbock, TX. Check back closer to June for news!

Off

Traditional

White