Having started as a crazy idea for just a small side project, the optical flow sensor quickly hacked together (we conduct our research on other topics) by a group of PhDs is now adopted by more and more systems. And because its an useful tool for research (not so much a research contribution), it made even a short paper. Optical flow is a pretty old and basic technique, but quite robust if the camera runs at very high rate - and the main success factor making the AR.Drone so robust and easy to fly.
Aside from the easy integration into different systems, the main benefit of a standalone design is the extremely low latency of the velocity output. In our latest Firmware version currently in testing the camera sensor runs at 450 Hz, which makes the output despite the relatively basic algorithm extremely robust. And it means we can bump the maximum speed to ~3 m/s per meter altitude, or in other words: Allow a maximum speed of 30 m/s at 10 m altitude and still allow a smooth precision landing at 3 m/s at 1 m altitude.
Because the ground distance noise feeds into the velocity noise, the next big step will be the integration of laser based altitude estimates - and with the Lidar-Lite having a really low price tag, it will be an ideal combination. The ultrasound ranging was in fact so far the biggest limitation and with this removed, we think an optical flow sensor should become the default in addition to GPS today - its a great complimentary technology to improve robustness and accuracy.
And by becoming a default, the costs of making the module will come down to a level where its a no-brainer to get one. Besides our own system a number of autopilot systems have been successfully interfaced (AutoQuad, MikroKopter and lately ArduCopter).
This video shows a scenario called urban canyon, where the multi path reflections of the environment and the blocked sky view by buildings make GPS reception extremely challenging and much less accurate than on an open field:
And of course there are many more cool videos on Youtube - I just couldn't embed all of them here.
Comments
Excuse me.I really need your help.Thanks.
I have a question.After I plug px4flow on pixhawk, pixhawk can read data, but when I o
pen POSCTL pixhawk prompt REJECT POSCTL, frequently, the flow and the timeout. You can tell me how to solve?----I 'm a Chinese,I learning English now,so may express not too clear.Thank you.
A practical question: are all the videos without GPS?
If so, what modifications are necessary to APM. Is it as easy as just taking that "GPS lock" pre-arming check out?
Thanks.
Lorenz, it happens one of the companies we distribute products for has a readily available machine vision camera with the Aptina sensor: http://epixinc.com/products/sv_wga.htm
Epix has small form factor frame grabber boards for UAV's and other limited space applications.
Once the EMVA 1288 system is up and running, I will order one of these cameras and test it against EMVA 1288 standards.
Added note, I do have designs and products for UAV Sense & Avoid imaging. One is a camera lens made by Optec, SpA(www.opetc.eu) with a wide FOV, 95% light transmission across the visible band(380-680nm), and no vignetting, one is 16mm the other 12mm.
The others are very high dynamic range imaging sensors and cameras, that have true 120db+ capabilities. We also have very low light CMOS & EMCCD sensors. Prism Array Multi-Spectral imaging cameras. SWIR + LWIR imaging systems with Fusion Technology for very low light(NO Intensifier Tubes or Ring Lights). Cameras with embedded computers(Windows & Linux) that can control the camera, zoom, motorized focus & iris, plus dual FOV with onboard image processing, storage, wireless interfaces and network capabilities.
I have plenty of information on all of this, send me an email: kdbusto@vegatecgroup.com
Thank you for your help, we will be in contact momentarily.
@Rob I don't know anything about your relationship to 3DR, but the PX4 project has no "customers" nor "paperwork" and the communication is in general through the public mailing lists. Please use the mailing list to contact the development community on this project and you are warmly invited to provide feedback, criticism or in the best case patches there. If you have specific technical concerns its best to file an issue.
@Rob Its always great if someone shares positive and apt comments. How come we missed your pull requests improving the software?
We're also a bit confused by your engineering approach. If its so bad, why did you still build on it? I would recommend you to not build on work of others you do not believe in. And its really surprising your team has problems tracking upstream changes despite of a powerful version control system (GIT) in place.
As a closing remark, you seem to have missed the concept of open source: It means that someone offers a solution you can use or build on. It doesn't mean they need to fix your problem. Often enough you find quite open minded people in these groups though that still love to help others even they're not obliged to. Somehow you seem however not to have really tried - there are zero open issues here:
https://github.com/px4/flow/issues
I've recently started working on a driver to make the px4flow sensor's data available within ArduCopter or ArduPlane. That code is here. There's definitely a growing number of people interested in getting it working and PaulR who wrote the EKF that's in plane (and will be out soon with AC3.2) seems keen to use this sensor. This won't make AC3.2 but hopefully AC3.3 (or maybe a patch release). It'll be pixhawk only I think 'cuz the APM2 just can't do an EKF.
Great discussion on PX4 flow, we had our tech team try to decipher this mess, the code is very much patched together and stitched by some of the worst fixes I have personally witnessed. That said it is also hard to gain any support from anyone that can give you real answers or duplicate their work. Another tip, don't update the firmware when you've made your changes or you'll be sorry.
I was about to ask whether LIDAR-Lite could replace the Sonar, now you put up this blog post. Nice.
The other limitation (and reason why I don't have a PX4FLOW) is the price tag. Would be good if there's a chance to bring it down.
If you have seen this blogpost: http://diydrones.com/profiles/blogs/design-of-a-multi-rotor-vtol-ua..., they have - as far as I understand - used PX4FLOW for precision landing. If those two applications, optical flow and pattern recognition for precision landing - could be run on a single PX4FLOW (not necessarily at the same time) this would be great.
-
1
-
2
of 2 Next