Hacker News Reader

Comment by fest | Hacker News Reader

The best (feature-wise) open-source quadcopter platforms are:

  * PX4,
  * ArduCopter (actually uses parts of PX4),
  * PaparazziUAV.

These pack a lot of functionality: really advanced sensor fusion algorithms, position hold, waypoint/mission functionality, API for external control. At least PX4 has (working) integration with physics simulator (very useful for testing).

All of them are great starting points if you want to develop additional useful functionality (e.g. package drop, autonomous mapping/patrol)- implementing even the bare minimum pitch/roll/yaw stabilization functionality takes a lot of effort.

The easier way to enter this domain is using an on-board/companion computer (typically RaspberryPi/Odroid) to control the autopilot using high-level commands (e.g. fly to these coordinates, activate that output etc).

Background: I have spent ~2 years working on (sadly) unreleased products in this domain.

View on HN

I'm intrigued, are you able to say what kind of product did you work on?

Who's doing these kind of products? I've done some things with the PX4 and I love it, the guys doing it are super smart. I've worked on some indoors navigation stuff but I wasn't very experienced at the time and the project turned into a mess.

Sorry, I don't think I can give you a lot of details. Let's say that one of my previous employers did a project which was supposed to be indoor quadcopter for consumers.

Regarding PX4- completely agree. People working on it definitely have high standards for software engineering practices and sense of responsibility. ArduPilot guys are also doing very good job, especially regarding state estimation (sensor fusion).

Indoor navigation is sadly not fully solved problem, at least for open-source solutions. I have not tried it, but IMO the best option at the moment seems to be Qualcomm's drone platform, as that has high-resolution, wide angle camera and enough processing oomph for image processing.

PX4Flow did work on some surfaces, but did not work too well on highly repetitive textures (e.g. office carpets). The image sensor, although is very good (global shutter, large, sensitive pixels) had limited resolution and even more limited was processor doing image processing.

The fusion of flow data was also quite unstable for ArduCopter and PX4 (they both shared the state estimation code at that point). Some of the problems were implementation issues (e.g. a few bad measurements caused the rest of (now valid) measurements to be ignored) but some were fundamental ones. The algorithms in use relied on constant distance between camera and objects on scene (required for calculating velocity in uniform units) which was unrealistic assumption indoors (e.g. flying near walls, over tables, etc).

My experience mirrors yours, but I only worked on this for @ 5 months give or take and didn't really have a big tech team to back me up.

The Qualcomm platform, as far as my understanding goes, still uses the PX4Flow. I don't know what packages they have for vision but it uses ROS so I assumed it had some ROS package powering it.

Px4Flow on its own is insufficient, but I was under the impression that it is able to calculate velocity even with variable distance camera-to-surface, they do have the ultrasonic sensor there and apparently, adding a lidar greatly improves performance.

Qualcomm platform has different camera and is directly connected to SoC, so I doubt they share anything with PX4Flow.

PX4Flow can calculate velocity when camera-to-surface distance varies, no doubt about it. The problem is when single frame contains features at various distances (e.g. lidar/sonar measures distance to ground, but half of the frame also sees table which is a lot higher).

Would it not be dangerous to use a non modified Raspberry Pi due to the lack of real time programming? or are you suggesting to use another board in conjunction with the sbc.

Yes, he means using it in combination with a real time flight dynamics computer.

Something small like an arduino can be used for attitude control, heading hold, etc., which is itself directed by a mission computer (the RPi) which can manage more complex, higher level behaviours.

Reply on news.ycombinator.com