February 2024 Meetings Aerial Robotics

Hi all!

Next developer meeting is coming up next week!

Meeting link (UPDATE) meet.google.com/vqa-nwxg-jkt
Also see the community calendar

So this will follow the agenda of what I’ve proposed last developer meeting last month. I’ll update this with the important discussion points and PRs before the meeting itself:

  • 1- Intro and Announcements
  • 2- Work done and current state by subcommittees
  • 3- Immediate plans subprojects
    • 3a- Subcommittee lead share the next plans
    • 3b- Any announcements or discussion points.
  • 4- Discussion points
  • 5- Conclusion
1 Like

Hi all, we had to change the video call meeting link which will be here: https://meet.google.com/vqa-nwxg-jkt

Here the recording of yesterday’s meeting:

And the related files:

Meeting 14 feb 2024 - Slides (90.5 KB)
Meeting 14 feb 2024 - Chat (23.3 KB)
Meeting 14 feb 2024 - Transcript (167.0 KB)

Next meeting is a scientific/presentation meeting on the 28th of February. Next week we will announce the speaker/topic.

Hi all!

The next meeting will set place next week already!

Meeting link meet.google.com/vqa-nwxg-jkt
Also see the community calendar .

We thought it would be a good idea to make this ‘presentation’ meeting a ‘discussion’ meeting instead, focussing on the current REP-147, and messaging standards that currently exist within the major aerial robotics autopilot like Ardupilot and PX4. It would be nice to start making a plan to try to unify this all since there seems to be some discrepancies that remain.

We had a discussion and meeting about this back in August for those that can remember that, so you can see this as the sequel.

I’d like to open up a discussion on how we can use MicroROS for REP-147 when some of the messages are overkill for embedded. I filed an issue on ros-infra/rep: REP-147 mandating covariances in messages is too much data for embedded · Issue #392 · ros-infrastructure/rep · GitHub

PX4 has the current approach of using uORB messages which are perfect for embedded, but those provide no ABI stability within an LTS ROS distribution. They also only work on PX4, which makes autopilot-agnostic development in ROS more burdensome.

Is there a middle ground between the two approaches that allows ROS developers to follow ROS conventions while avoiding wasting resources on embedded?

The lack of common interfaces that make sense for embedded make implementing some of the terrain navigation features in an autopilot-generic way quite difficult.

Relate tickets:

Thanks @RFRIEDM!

Perhaps not about the messages itself, but maybe also an addition to the discussion to protocols as you mentioned microROS, could we also take Zenoh into account? It’s seem more robust for wireless communication, and soon will be the official alternative to DDS, Also it actually already implemented into PX4 Add Zenoh pico support by PetervdPerk-NXP · Pull Request #22017 · PX4/PX4-Autopilot (github.com) and we internally at Bitcraze start to experiment with it.

Perhaps at the start of the discussion, let’s settle on the scope of what we will talk about this hour on Wednesday, if it will be about the content of the messages itself or the ‘delivery system’ or that it needs to be interwined in order to have a fruitful discussion.

Just a ping and reminder that today’s meeting will also not use that meeting link we’ve been using before this month. So please use https://meet.google.com/vqa-nwxg-jkt

Also, we got thread open now on indoor navigation so make sure to check that out and comment on it.

  • Great insights from @tfoote on the origins of REP-147 and alternative processes we could take an iterative adoption approach rather than a big design effort and certification standard
  • @mrpollo had valuable lessons learned on how the MAVLink governance model and work can be re-used
  • @Jaeyoung-Lim had a well-received proposal on how to make measurable progress on this effort by solving small problems
  • @dagar had great information on how companies are using uORB in products now and how they deal with the message instability in PX4
  • @botmayank raised some great questions about how MAVlink addresses some of the issues of product-specific customizations
  • As, always @KimMcG did an excellent job hosting

Thank you all for attending.

As promised, I opened up a new ROS discourse thread to seek thoughts on which use case we want to solve a problem. Please suggest alternatives or vote on an existing one. See below:

Thanks @RFRIEDM for the summary!

For anyone who missed the meeting, this is the recording:

Here are the files:
Meeting 28 feb 2024 -Transcript and summary (207.3 KB)
Meeting 28 feb 2024 - Slides (352.5 KB)

I tried something new with the transcripts. I’ve added the chat content now in the same document, and I’ve auto-generated and edited a bulletpoint list of the summary that would make it clearer what the main points were that we discussed. The main 'todos that came out of this discussion were:

  • Slim down Rep 147 or replace it and iterate through incremental changes.
  • Proposal to create compliance test suite for certifying autopilots against the standard.
  • Communicate together with MAVlink developers what would be the best messages to focus on.

Hope it got the gist but the transcript document has more detail of course.

Next meeting will be a developer meeting on the 13th of March so I’ll share the announcement next week.