I can remember a decade ago having to clean my car’s windshield each time I filled up at the gas station. Now-a-days in both the US and Germany I find it a rarity - my wipers can generally get the one or two splats. You’ll notice a bit more on the country roads vs interstate/autobahn but such an alarming difference overall.
I've been trying to get my organization to use ODM, but finding it difficult. The problem is analogous to the issues that Gimp has to Photoshop or Linux to Windows -- ease of use. Additionally, even if you properly configure the software the quality still is not comparable to the big proprietary players in the photogrammetry field: Bentley Systems; Pix4D; Drone Deploy.
A major reason for the quality issues is that the major drone manufacturers work directly with the proprietary photogrammetry software providers in the field to optimize the algorithms to their drones. These drone manufacturers then promote these proprietary solutions. This puts ODM at a disadvantage as there is no short-term financial incentive for manufacturers to promote ODM.
Like other fields, the proprietary photogrammetry industry is increasing moving to implementing their solutions exclusively in the cloud. This is forcing folks to give up their data and building a data moat - a problem for my organization.
I hope ODM keeps developing and becomes as ubiquitous as linux. Its quality is getting close for my organization to consider its implementation. Keep up the great work!
Thanks for championing ODM! :) It's true that proprietary systems have had a lead in development for a long time, but especially of late the software has gotten really good. If you haven't tried the software in a while, I'd recommend updating and giving it another try.
The quality issue is an interesting one; I remember having a discussion with a client that was considering transitioning away from Bentley's ContextCapture (CC) and they mentioned that CC was generating much denser point clouds compared to ODM. CC tends to generate very good looking point cloud models, except its algorithms extract points from a mesh interpolation approach, so sometimes you end up with points where geometrically there shouldn't be any. Sure they look good, but is that "good" quality?
> A major reason for the quality issues is that the major drone manufacturers work directly with the proprietary photogrammetry software providers in the field to optimize the algorithms to their drones.
Would you care to elaborate? My belief is that all the photogrammetry engine wants is that the drone manufacturer does as few processing as possible on the images, in order to not alter the geometry. I don't see what kind of algorithms coming from the drone manufacturer would help, and therefore I don't see how that's a problem for ODM.
Direct knowledge of the lens distortion model and complete control of the image generation, with perfect knowledge and use of the associated metadata tags, can certainly give an engine a leg up in some cases. One example I can think of is the Parrot Sequoia which is a camera that works OK-ish in ODM, but works flawlessly with Pix4D (which is owned by Parrot).
But none of that is private data, right? It feels like "tuning". Surely one could characterise Sequoia to improve the camera model, and I doubt they encrypt the exif data, do they? Also Sequoia is a bit of a special example here, that most likely has been carefully tuned by Pix4D. But DJI most probably does nothing for Pix4D that ODM couldn't access.
Not criticising ODM (I love OpenSfM and ODM), on the contrary: I feel like those are not fundamental limitations of ODM, and one could put the work of improving support for specific cameras without the need for proprietary information available only to Parrot employees.
EXIF data is not encrypted, but often times is not documented (or documented well). DJI has many differences between models (even between firmware versions). They also sell DJI Terra, which is their own photogrammetry solution.
The point being that you are correct, these are not limitations of ODM, but in some cases it does give vendors a head start (a leg up) in implementing good support for certain cameras, especially multispectral cameras like the Sequoia.
There are moments a pilot has seconds to react and disengage autopilot.
Example: Traffic Resolution advisories require a 5 second reaction time and 2.5 seconds for any follow-on reactions. This reaction time includes the time to disengage autopilot and also put the aircraft into a climb-or-dive. Studies show that a situationally aware pilot takes at least 2 seconds to start the reaction, and another second to achieve the proper climb/descent. There are other times on e.g. approach, or ground collision warnings with even narrower margins for disengaging autopilot.
Pilots generally know when they need to be hyper-aware with autopilot and so do competent Tesla drivers. If there are issues with the name "autopilot" for Tesla, the same argument needs to be made for aircraft manufacturers.
"Example: Traffic Resolution advisories require a 5 second reaction time"
When the Autopilot swerves into a concrete wall for no reason, you will have 0.5 seconds left to live. Rwacting in the last 0.1 secons bwf9re collision will not save you - you must react in like 200ms.
It is physically impossible to react in time to some autopilot mistakes, stop defending this idiocy.
Surely you can see how you might have less than a second to react if Autopilot swerves into the oncoming traffik? I can't search all tesla accidents by 'least time to react'
> If there are issues with the name "autopilot" for Tesla, the same argument needs to be made for aircraft manufacturers.
Pilots require extensive training (an re-training). The must meet certain criteria to even fly certain types of plains. And they have to go through additional training if they have to switch planes (going from Airbus to Boeing for example).
So, if we're making "teh same argument" for Tesla, then Tesla needs all that to call its system an autopilot.
5 seconds (or the 2 seconds that pilots require) is a lot more time than you’re afforded to take action while driving a Tesla in autopilot. And when driving the Tesla you often won’t get a clear warning signaling that you have to take over and do something - it can fail silently and swerve straight into an obstacle.
The difference is that you can’t be a pilot with even as little physical impairment as a crooked nose and it takes extensive years to get a license, while every rich 18 years old can sleep behind a tesla’s wheel…
A sailboat autopilot is even simpler. The simplest ones maintain compass direction, but don’t compensate for drift due to water currents or side winds, or for the difference between magnetic and true north.
An IMO important difference with pilots is that pilots are professionals that get trained and periodically retrained on how specific planes and their autopilots work.
Tesla drivers, on the other hand, hear Tesla’s at times optimistic marketing, and may just learn how to switch autopilot on and off without understanding when to use it and when not to use it.
Here is Harold Abelson discussing the topic in ~1986. His introduction to “Computer Science” has stuck with me for years. Interesting to see the lineage of the statement, it must have stuck with him as it has for me, when he first heard it.
You are correct in your common sense test, the article is not correct.
Check out the Concorde wiki[1] It states ~4.4K lbs for taxi which passes the common sense test. Taxi time is generaly planned as 15 minutes, so ~10K lbs/hr which is more than what a Boeing 767 burns at cruise - quite a lot! For comparison Concorde super sonic cruise fuel burn was 40K-55K lbs/hr.
For another reference Boeing 767s typically plan to burn 2K lbs of fuel for start-up/taxi/takeoff run.
Thank you for doing the research to find the numbers for this.
I think it's worth adding, as is reflected by your B767 ground movement figure that all jet engines are very inefficient at low power outputs, not just the Concorde's/supersonic aircraft. This is as a large amount of energy is needed to create sufficient compression to allow them to function.
Finding ways to minimize the amount of time spent in these states has been the industry's approach to date.
Boeing rudder issues in the 1990s? How about the 2010s? A KC-135R(Boeing 707 variant) in 2013 crashed of the same issues as the article.[1] The KC-135R is essentially a modified 707 retooled with 737 engines and a beefed up vertical stabilizer to account for the increased power of the engines. This modification of the KC-135R occurred in the 90s and has been plagued with rudder problems ever since. The accident in 2013 was attributed to pilot error, because there are procedures to turn off the PCU if the rudder goes haywire... but why not just fix the problem outright?
Apple has started to implement service workers in the latest Safari, but it still lacks behind the other browsers - I suspect they are worried it will provide a disincentive for applications to be hosted on the app store.
My biggest draw to PWAs was the ease of which I could deploy an intranet app on portable devices with spotty connectivity. This works fine with the appcache, which is what I currently use, but service workers require SSL and self-signed certificates are a no-go. This adds to the complexity of using service workers in a simple intranet hosted PWA. Also, back to Safari's poor implementation of service workers, the amount of time a PWA will reside in the browser is unspecified. I can only imagine the the headaches it will cause if the PWA drops randomly. So I'm avoiding service workers in my PWAs for now.
When appcache deprecates (it's slated to), maybe it will be time for me to go native if I am going to have to add complexity regardless.
> the result will be having to live with regulation and oversight like every other industry.
The only other industry I think could be comparable to this, from a privacy standpoint, would be the banking industry. They are largely flying under the radar during all of this, any hypothesis why? Is it because their regulation and oversight is working like you are alluding to? Or is it because the banking industry has not been caught...yet?
