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
Riccardo,
On the BBB side we're just using the pyserial Python library to send/receive whatever data we need over the UART to the Pixhawk. We added a CRC to ensure data integrity, but that isn't absolutely required of couse. On the Pixhawk, most of our custom code is in a file called UserCode.pde, which is already in the source code and specifically intended as a place for users to add any custom code they want. You can look at the APM developer site for more info on modifying the Ardupilot code (http://dev.ardupilot.com).
I attached our UserCode.pde to my original blog post to show what we are doing. You may notice a lot of reference to "SLIP" in the code, which stands for Serial Line Internet Protocol. It's just the messaging scheme we chose to format our serial messages. The file is somewhat poorly commented, but hopefully you can get an idea of what is going on.
dear chris,
Thanks for the info. can you tell me more about how to communicate between the PX4 and the BBB? could you show me the code for both sides? would i be able to transfer new waypoints from the BBB to the PX4 easily?
Thanks a lot for the quick response,
Riccardo,
Sounds like an interesting project. Like you are describing, we also use the BBB for all of our unique logic and leave the flight control to the Ardupilot. Interfacing the BBB to Ardupilot is reasonably simple. One thing I would suggest though to maybe make it easier for you is to consider using a Pixhawk instead of the APM. The Pixhawk has unused UART connections available that you can use to communicate to/from the BBB. The APM does not, although I believe it has an I2C connection that you could probably use.
In terms of software, you'll need to download the Ardupilot source code, make any changes you need to it, and then compile it yourself. At a minimum you'll need to put in code to send data over whatever serial connection you choose. The Ardupilot code is C++ code, and it is reasonably simple to follow and understand. On the BBB side all of our code is Python, so I can probably point you in the right direction if you have any issues from that side of the interface.
If you have any more questions, let me know. Good luck on your project!
Dear Chris,
We are a team of students from the university of Southampton. We are making an autonomous surface vessel capable of crossing the atlantic. We are at a good stage with the hullform and superstructure design and we are now going into electronics.
We now think that the best solution, in order to have satellite communications and AIS object avoidance, is to have a Beaglebone Black connected to an Ardupilot. The APM would do the lower level computations of manoeuvring the vessel, where the BBB would be connected to the other systems and would do higher levels calculations (i.e. object avoidance, etc..). We believe that this system is ideal as we can use the Ardupilot library and just program the remaining parts in ROS and Python for the BBB (which would then communicate with the APM, over Mavlink and serial ports, to give new way points in case of avoiding something).
Can you tell me more about the BBB and APM interface? Also how hard do you think it is to change the Ardurover code to recieve info from BBB? (considering that i only know how to program in Python and a little bit in ROS.
I'd start here: http://dev.ardupilot.com/
Is there any guide from where I can learn how to start working on Ardupilot.
I am also planning to work similar project
Cool! Thanks for the info.
I have already a great impractical use for this technology. Old school video games in real life! Get like 12 more of these thing on the network, lay on your back, and play snake. Have a quad take off every time you add one to the chain. I'm sure that's the main reason you started this project in the first place ;)
Daniel
Yes, that is correct. We usually run test flights with two laptops, one monitoring the vehicle telemetry from the 3DR radios and the other monitoring the two XBee channels. It's just a lot of data for one person to monitor at the same time, but we do occasionally have all the radios (XBee and 3DR) hooked up to a single laptop.
Very interesting. So you have two mesh networks setup with xBee radios running at two different frequencies; lets call them channels. Then you also have a 3DR radio running on its own channel for each node which is talking to a GSC. Do I have that right? So do you just have 7 com ports open on your GCS(5 telemetry nodes, 2 mesh networks)?
Daniel,
Currently we don't plan to have more than 8 nodes, but I don't think that is the absolute peak the system could support. It would be limited by the network congestion on the XBee networks, but I believe it could support many more than 8.
As far as using 3DR radios, it would definitely be possible. We currently use the 3DR radios for standard vehicle telemetry along side our XBee networks, but I think with some work and maybe a more limited set of telemtry you could use just the 3DR radios for both purposes. Right now our limited factor actually is congestion on the 900 MHz band used by the 3DR radios. As we add more vehicles, the signal quality of the telemetry radios degrades because they start talking over each other.
We did experiment initially with the XBee mesh support (DigiMesh and ZigBee mesh), but it used a lot more bandwidth on the XBee networks and we didn't need it for this application, so we ended up just using the standard XBee protocol.
-
1
-
2
-
3
-
4
of 4 Next