https://www.youtube.com/watch?v=oH9C43To3Dk
A few co-workers and I at NASA's Marshall Space Flight Center (MSFC) have been working on a small formation flying project over the last 9 months. Our project is to demonstrate formation flying using a decentralized mesh network first by flight testing the concept with small UASes (nearly standard 3DR quads), and then simulating the same system being used on satellites. We had a very successful demo flight last week with 5 quads flying, and I thought now would be a great time to show our results and share our work with the sUAS community.
We've been using 3DR UAS systems for several years now on several projects including an internal NASA search and rescue unmanned system competition and to provide aerial footage of test flights of the Mighty Eagle lunar lander testbed at MSFC.
For this new project, we took the standard quad frame and electronics with Pixhawks as the flight computer and added to that a Beaglebone Black to run our formation logic and a pair of XBee radios to provide the formation communication between our vehicles (which we call nodes). Each node communicates using its two XBees which are each running a separate mesh network for redundancy. The nodes exchange state information that they receive from the Pixhawks (GPS position, etc.) and then use that information to determine where they are in the formation and where they need to go. Since they all share their information, there is no one master or leader of the formation.
We have two primary modes. In the first mode, the vehicles are provided a GPS location and a formation shape which they then fly to and establish a formation. We can change the formation position and shape by sending an update from our ground control station (GCS) using some custom GUIs we developed. In the second mode, we can designate one vehicle as the leader of the formation, and the other nodes will automatically begin following that leader as we move it either via RC or from our GCS.
We've always gotten great help and feedback from this open source community, so we just wanted to return the favor and share the work we've been doing. Here's a video of our latest flight of 5 vehicles. The video has overlays of two of our custom GUIs as well as the audio from our ground control team.
UserCode.pde
Comments
No, they were actually all broadcasting. Each node broadcasts information about itself to all other nodes. All of the nodes are treated equally and can assume any role, so they are all configured the same. We can assign a node a particular role (like leader) via a command from our custom GCS software.
There are certainly several ways you could implement a swarm algorithm, many better than the method we chose. Our main goal was to develop the mesh network, and not specifically to create an ideal swarming algorithm. We just use a swarm as a challenging test to see how well our mesh network works.
Chris
Since you are using point to multipoint, i guess you are setting the leader to broadcast mode, while the others are in unicast. Have i understood it right?
Is the leader set to API mode? That way it can send a frame of data that specifies the location of each drone.
On a different point, wouldn't better coordination be achieved if the swarm algorithm used velocity information apart from just position information?
But this would probably require sending N,E,D,Vn,Ve,Vd from each drone. Another advantage to this would be that you would be sending the output from the UKF/EKF which comes at a much higher frequency(200Hz?) compared to GPS coordinates which get updated at 5Hz.
Srinath,
The vehicles in our network communicate amongst themselves (point to multi-point) and don't require a GCS. Last year we were just using the standard XBee firmware to handle the mesh networking, but this year we've implemented our own software using a TDMA scheme, so that the mesh can operate with any radios (not just the XBees).
Hey Chris
This work is super cool.
Do you route all communication through the GCS? If not how do you create a Xbee mesh network?
Or do you send and receive messages in a round-robbin fashion on all nodes?
We have not attempted to operate with more vehicles. This year we've been working on porting the mesh communication smarts to software, so that we aren't reliant on any particular radio, like the XBee. We've got the new software running in lab and will be starting flight testing soon.
You could certainly communicate with the Pixhawk using MAVLink messages, assuming you can find existing message definitions to use or if you wanted to create your own. Depending on what all you'd want to do, I still think there could be some unique code modifications you might still want to compile into the code.
We use the 3DR radios for independent vehicle commanding like mode changes, arm/disarming, etc. and the mesh for commands that are global to all vehicles like new formation position commands or formation mode commands. But you could definitely consolidate and use just one radio type if that suited your application.
*messages.
Hey Chris,
This is a very cool project. I was wondering if you can send data in the form of mavlink meesages to pixhawk via beaglebone using Telem 1 instead of Serial 4/5? Would this eliminate the need to load compiled code on arducopter? From what I understand you are using 3DR radios to just monitor data from the nodes which can be also done using one of the mesh network.
Thanks !
Thank you for the quick response. That makes sense about custom building, thanks and they look awesome! Have you expanded this software to run larger groups of vehicles?
It was a custom build.
This is a great post! Thanks for sharing! I am looking at doing a similar project. Where did you buy the dual xbee capes from? Or did you custom build? Thanks
-
1
-
2
-
3
-
4
of 4 Next