At the same time, I’m doubtful that software bugs in the proprietary code are related to the vast majority of these failures people describe. The only legitimate issues I’ve seen are caused by sensors (either the foot sensor itself, or improper mounting usually related to grip tape) or water damage.
A Onewheel attempts to self balance. To accelerate, you lean the direction you want to go. As your speed increases, the board starts tilting the nose up to signal it’s reaching its limit. Powering the motor requires energy, and self-balancing requires additional energy beyond that, so a safe amount of headroom needs to be reserved to accommodate for variations in terrain and rider movements.
When the noise starts tilting up, there’s nothing to stop the rider from leaning forward more, which also signals to accelerate. This is called “pushing through pushback” and it’s required to go more than ~16-18 mph.
Imagine the extreme case where you quickly lift your rear foot off the board. Obviously it’s going to stop suddenly, and you’ll fly through the air and smash into the ground. Every nosedive is exactly this scenario, just slightly less extreme.
Once I grasped this simple concept it became obvious that every fall was my own fault. This is why I recommend new riders practice balancing with the board powered off. If you can’t easily do that, you have no business pushing through pushback.
The boards being “fixed” by this recall are getting a new feature that makes the board vibrate at high speeds. This is done by modulating the motor, it requires no new transducer. The only “failure” is of the rider being oblivious to the signal the board is sending.
Source: own a V1, Plus, and GT; ridden thousands of miles on my own and other’s boards; ran a meetup and met a huge variety of rider types; once raced in the GoPro Games; crashed hundreds of times including the obligatory bone-breaking incident resulting in surgery
tl;dr: Future Motion is anti-consumer, haptic feedback is overdue, but there’s nothing inherently wrong with the Onewheel. Every nosedive is ultimately due to rider error.
This is orthogonal to riders accepting they’re participating in a fun but very dangerous board sport.
They assume they are shipping bugs and in some cases they are intentionally shipping bugs to make deadlines. It’s scary for a business to decide to make those bugs public even though most of us know the end result is better product quality and higher social capital.
I am sure they are, but companies making products that relate to human safety simply should not do this.
> even though most of us know the end result is better product quality and higher social capital.
I agree. I guess I wish there was more education about this in our higher institutions and I suppose at conferences. They should be asking questions about what is best for their business and we should be sharing stories of how open source can work in big business.
I suspect a lot of the fear of open source is driven by the uncertainty of how big the "easier" in this sentence is.
On the competitors side, what if it's currently taking up 90% of your competitor's time just to understand what you're doing and make a rough not-quite-as-good imitation, whereas if it was open source that time drops to 5% leaving them much more scope to improve on top?
Plus, there's fear about security too. Sure nobody should rely on security by obscurity, but that doesn't mean it can't be a helpful thing and what if hackers spend more time reviewing the code you release than friendly bug finders do? I personally have no idea if there's any data on whether OSS has better, the same, or worse track record on average for being hacked, or if there've been studies on how often hacks happen with or without source code being available, etc. but regardless of the actual odds, it feels like the business equivalent of leaving your house's front door open 24/7, so it can be an emotional argument as much as anything.
And like you said, the current default expectation is closed source as default, so the decision makers find safety in making the choice that feels less risky unless they can be sure it will bring big enough positives to be worth it.
That assumes that the problem is buggy code, isn't it? What if it is buggy hardware? What if it is the electronics that is glitching out?