Was it because it happed be the platform of choice for a (masters/phd/consultancy) project or did you take a specific aerial robotics course? Was it difficult to get into it, and what was missing that could have made it easier?
Hope you’ll share your experience so we can gain some insight on what can be improved!
I got started because it happened to be the platform of choice for my PhD, which was about tiny pocket drone swarms. It was figuring things out fragmental and painful trail and error (luckily possible with tiny drones), No ROS, so I couldn’t really relay on my MSc experience in wheeled robots, so starting out with Paparazzi UAV.
I did a bit into my PhD participated in the course called ‘Autonomous Flight of Micro Air Vehicles’ at the TU Delft given by my professor Guido de Croon but unfortunately that course didn’t exist when I just started out. Would have been a great start though!
For me it was because we needed something more powerful than a usual flight control.
I’m not developing myself but managing a team that is working on a project using ROS2 for drone Mission control.
I had a bachelor student who did a drone collision avoidance as ROS module based on just the MavLink UTM_GLOBAL_POSITION message.
Part of that was a Mission Plan file conversion in ROS (converting QGroundcontrol Plan file into Mission).
We also use automotive 77GHz radar on our drone that delivers pointcloud data into ROS2.
A Partner company is working on integration UWB into ROS2.
Our goal is to have a multirotor drone flying full autonomous mission based on ROS2 navigation by mid of next year.
One of the biggest challenges i see is to have a standard ruleset for collision avoidance. Because if two or more drones are on collision it needs to be predictable what the other airspace user will do next.
Well, technically I am still “getting started” in Aerial Robotics… but I’ll still share my story.
My first real encounter with aerial robotics was in an engineering school project involving small UAVs.
It was a tough task to learn simultaneously ROS (1 at the time), the multi-copter world and mission-level stuff like OpenCV for camera treatment and intelligence.
My journey continues with an on-going PhD on communication among a fleet of aerial vehicles. As I plan to do real-world experiments, I need to keep improving my hands-on skills with aerial robots !
As for the “what was difficult” question, I would say that the many version changes and incompatibility between different versions of software made it hard / impossible to reuse bits of code found online. Admittedly, it is a necessary flaw looking at how fast the robotics area is evolving.
that is absolutely fine that you are still in the learning process! that means that your learning experience is still the freshest and it is probably the most up to date to what the current state is with tutorials and education.
A question about your last section: is it the fact that it is unclear which versions to use that makes it difficult (a documentation issue)? Or the fact that there is just no good backwards compatibility (implementation issue)?
It is really the latter. But it is not restricted to aerial robotics, just the ROS environment in general.
Most of the time, when I find open-source code (relative to a research paper for example), and I would like to run it on my computer, I either have the wrong version of ROS, Gazebo, some ROS package, etc.
A good example is the switch between catkin and colcon. I spent hours trying to understand what changes were needed to compile a catkin project with colcon (I learned CMake in the process, which is a good thing in the end ). On the documentation side, many things could be improved. For example, I lost a lot of hours trying to understand something that was not consistent with the documentation (this was on the PX4 Autopilot), before finding the solution in the PRs of the GitHub repository. Good practice is to push the change in code and its associate change in documentation the same day, this is not always respected (I love and thank the people behind the PX4 autopilot project, you people rock !).
Note that even though I raise the issue, I know that this is a very broad problem, not only with open-source projects. Also backwards compatibility is not always desirable nor possible… and I can’t stress enough that open-source contributing is a benevolent activity ; I cannot criticize the hard work of contributors, behind myself a user !
I am originally from Ethiopia and I started as a drone pilot. I relocated to the States for my masters now and I will be working on developing simulator and different projects in a lab and I will use Ardupilot (Sitl). But I am always inclined and interested to work on ROS
BTW I’ve also send out a post on linkedin about getting more suggestions and has spread out a lot! A lot of extra suggestions that I can put on the list as well:
). On the documentation side, many things could be improved. For example, I lost a lot of hours trying to understand something that was not consistent with the documentation (this was on the PX4 Autopilot), before finding the solution in the PRs of the GitHub repository. Good practice is to push the change in code and its associate change in documentation the same day, this is not always respected (I love and thank the people behind the PX4 autopilot project, you people rock !).