Towards ROS-native drones

General
1

I’m happy to announce alpha support for the PX4 flight stack for Erle-Brain 2 and PXFmini products (both used to build flying robots). Altogether, this comes to support a path towards drones that speak ROS natively.

I wrote a short article here justifying why this is necessary.

Feedback is welcome. There’s a limited amount of resources allocated to this project. Those interested in contributing can do so by contacting us.

3 Likes
2

Really cool project!
Is this dependent on ROS2?

3

Yes @kgk, the idea is to build on top of ROS 2.0.

4

What was your main motivation for targeting the px4 flight stack? Are you expecting to come across many issues with the RT OS and timing when integrating it with the ROS network?

5

HI @pryre,

Motivation is summarized at Towards ROS-native drones. Announcing alpha support for the PX4… | by Víctor Mayoral Vilches | HackerNoon.com | Medium.

There will indeed be a few aspects to take into account with regard maximum latencies but I don’t expect this to be a critical issue. We’ve got experience running real-time tasks in Linux (e.g.: autopilots ) and as pointed out in the article itself, the ported PX4 flight stack already uses a pub/sub middleware that complies with the timing in a good way.

It’s relevant to note though that with this project will be targeting ROS 2.0 thereby configuring DDS appropriately will be necessary.

If you’re concerned about real-time compliance with ROS, I’d encourage you to have a look at the RTROS talk presented this year at ROSCon 2016 when available (my understanding is that slides and videos will be available pretty soon). We’ve been following a similar approach in our OS images.

Nevertheless, thanks for bring up these concerns. Testing Xenomai and PREEMPT_RT configurations would be a great way of getting involved with the project.

6

That’s good to hear! I only ask as we’ve been having a lot of trouble recently regarding some of the mavros implementation and timing issues (whether it’s px4 side or mavros side we are unsure of).

Would you see it better to target smaller scale projects? Or another way of putting it… Would it be easier and more reliable to implement a similar system to the px4 flight stack based targeting a single type of drone? Rather than have to aim for support across the multi-fixedwing-vtol codebase the px4 stack is currently aiming to achieve?

There are benefits to the unified codebase approach, but it seems like there is a lot of openings for potential issues.

Also (unless I missed it in the previously linked post) how do you plan on working around missing features in the flight stack? I am under the impression you will build directly off of the px4 source, so would you be planning on implementing all features as requested, and leaving any firmware incompleteness to on that side? Or would it be more aimed at supporting the currently available features, and keeping up to date with what is achievable with the firmware?

7

Hi @pryre, I don’t think that that’ll solve your issues. APM flight stack generates a different binary for each vehicle and still suffers from those same issues when mavros is not configured appropriately. As pointed out in our article, getting the Flight stack + mavros + ROS combination to comply with your needs (specially timing-wise) is not a straightforward task. We’ve been hired to do so a few times and we believe there’s a better path ahead by integrating ROS at the core of the autopilot itself.

For now this project plans to port the pub/sub inner architecture of the PX4 flight stack to ROS. As for missing features and firmware incompleteness i can’t comment at this point. Depending on the success of this first phase and its popularity, we’ll evaluate if we (or jointly with others) can put more resources into those aspects.

In fact, it’ll be pretty useful for us to take user’s feedback into account when planning for further resource allocation. @pryre could you list those aspects that you and your team are currently missing in the PX4+mavros+ROS setup?