General > General Technical Chat
Is Arduino killing the electronic hobby?
2N3055:
--- Quote from: RoGeorge on June 24, 2021, 05:01:33 pm ---
--- Quote from: george.b on June 20, 2021, 06:56:56 am ---Case in point: https://assets.publishing.service.gov.uk/media/602bb22f8fa8f50388f9f000/Alauda_Airspeeder_Mk_II_UAS_reg_na_03-21.pdf
--- End quote ---
What I don't understand from that document is why all the recommended measures were keep talking about a cap of 80 Joules battery, while the incident was about a 100kg drone.
A CR2032 coin battery holds about 2000-3000 Joules.
What kind of drone can fly with 80 Joules? :-//
--- End quote ---
They are talking about kinetic energy (as in thing fell on your head energy) not battery. There is the rule that UAW that can impart more than 80 joules of kinetic energy must not be operated above other people. 5 kg drone that falls on your head has 140 joules of kinetic energy and that one is already not allowed for flyovers...
Their drone would have 22,990 joules at impact, running horizontally at maximum speed and more dropping from the sky at terminal velocity...
Siwastaja:
--- Quote from: Nominal Animal on June 23, 2021, 02:51:13 pm ---(Edited to clarify: The only reason you'd wire a kill switch to require a working connection to kill a device instead of having the connection keep the device alive and kill it whenever the connection was lost, is because you believe an accidental killing of the device would be a bigger loss than anything a completely uncontrolled device could cause.
--- End quote ---
I think you may be
1) oversimplifying the design,
2) underestimating the rationale that went into that decision.
It likely isn't because they thought they want to rather save the device than people below the falling thing. This is the same false dichotomy as "save the market or save human lives" covid strategy discussion. In reality, preventing a crash saves both the property and human lives, so they have every motivation to prevent crashes.
The strange reverse-operating (let it fly until a signal comes in) kill switch is very likely because they thought about it, and tried to minimize the risk of loss of both property and human life.
I mean, it's obvious to most engineers, even beginners, that kill switch needs to operate so that power is killed when signal is lost. They likely prototyped it wired that way; until they found out in 5 minutes that nuisance trips happen and bring the thing down.
So given what they had: a flaky kill switch system, they did the optimization for lowest overall risk to both human life and property and wired the kill switch "backwards". This is the right choice based on two premises:
1) Loss of kill signal (say !K) is a more common event than the combination of loss of control and loss of kill signal (say !C && !K), so that P(!K) > P(!C && !K)
2) Safety target is not even near to 100%; accidents are to be minimized within resource constraints; but resources can't be increased.
Given the crappy kill signal design, 1 is likely true. They likely had dozens of hours of flight time and had their first dangerous accident because of the combination of loss of control and loss of kill signal. I'd guess had they wired the kill switch the other way, they would have crashed in ten minutes.
Which leads us to 2. The right thing to do is to increase the safety target. But there's no silver bullet. Oh the poor engineers. I don't know about this company, but I myself have been in situations where I'm being taken advantage of with severe resource-constraining from above. Yes, the right thing to do is to blow the whistle, "I can't do this safely" and if the culture doesn't change, then leave the business. And yes, that's what I have done, but it's not an easy choice which would happen immediately. In the meantime you try to do your best in the stressful situation which also blurs your vision. You also think you are doing good.
CEOs notoriously have higher risk of having narcissistic traits, and even if not, they tend to oversell the product itself, underestimate the schedule to produce the results, even more grossly underestimate the resources needed to design, and blatantly ignore feedback from their engineers then later say "you didn't say this out loud".
Designing such heavy unmanned aircraft is in my estimation a project where you would need to hire 3 to 10 top-tier top-class experienced engineers (not 1 competent alone; nor 50 clueless university students), give them budget of 5-10 millions to work with. 2-3 years to the first marketable pre-production prototype (and this includes design-for-manufacture, no Arduino hot melt glue) and 1-2 years more to make that actually manufacturable.
So Arduino is related; it was a project made by total hobbyists who can't take such a responsibility. It's not their fault, it's the fault of the management who very likely sold them the idea they could do it. The number of Arduinos everywhere in that system is just an indicator they have zero competent designers in the team and they should probably be doing lightweight mini-drones instead, or start doing the business seriously by finding the right people to do it.
SiliconWizard:
AFAIR, we talked about this "drone" a while ago in another thread.
Now whether the makers were well-intentioned or not, the weight of the device itself should have made it just plain illegal in this context. But IIRC, regulations about drones are pretty recent, and in particular the maximum weight per category has been defined on a EU level only a few months ago, so at the time they did this, there may have been no regulation about it to speak of.
That said, common sense should come into play. The same would apply to RC models. Building a 100kg RC plane and fly it is extremely dangerous, even when it's very well designed. No one in their right mind would do this unless strictly supervised and with all safety measures duly taken.
I don't think it has really much to do with the state of hobby electronics. I don't think it even has to do with the fact it's much easier and cheaper to build stuff these days. Decades ago, a few people were already building pretty weird and unsafe stuff. Think of this guy who built a neutron source in his garage (he wanted to eventually build a nuclear reactor.) That was 3 decades ago.
james_s:
--- Quote from: Siwastaja on June 25, 2021, 12:14:42 pm ---I mean, it's obvious to most engineers, even beginners, that kill switch needs to operate so that power is killed when signal is lost. They likely prototyped it wired that way; until they found out in 5 minutes that nuisance trips happen and bring the thing down.
--- End quote ---
I'm not sure I agree with that. In the case of something land or sea based, yes, absolutely cut the power if anything at all goes wrong. In the case of a fixed wing aircraft one could also argue for that, if the power is cut it can still glide to the ground and cutting the power limits the distance it can travel. In the case of a quadcopter, cutting the power means it will immediately plummet from the sky like a stone and smash into whatever happens to be below it. I do not think that is desirable at all, a momentary loss of the kill switch signal causing an uncommanded activation could easily cause a crash that could have been avoided entirely by simply leveling the craft and then gradually reducing throttle causing it to reduce altitude and land. Even an uncontrolled landing is likely to turn out a lot better than just cutting the power and letting it drop.
Either way, the kill switch control should have been bidirectional and self testing, immediately alerting the operator to any sort of malfunction. Also the right thing to do would be to take this thing out into the middle of nowhere for testing, there are places in most parts of the world that are sparsely populated with miles of open space and not much in the way of air traffic.
Nominal Animal:
--- Quote from: Siwastaja on June 25, 2021, 12:14:42 pm ---I think you may be
1) oversimplifying the design,
2) underestimating the rationale that went into that decision.
--- End quote ---
Obviously possible.
The software engineering analog here would be "I'll just leave myself this root account open so I can log in afterwards if something needs fixing." To get to that point, I don't see how you can know that much without realizing how bad an idea that is. Yet, it is a persistent pattern in massive breaches of internet-enabled appliances that we just cannot seem to get rid of. And I'm not talking only about the no-name cheapies; the clients of the name-brand netword equipment manufacturer Cisco seem to get bitten by this same thing every decade or so at least, even though many consider them the go-to enterprise source for such stuff.
I personally know enough of Arduino, BLDC motors, IMUs, various wireless comms and such, to consider tackling the task of building such a drone purely from a hobbyist basis, without being any kind of an engineer. And I'm known for recklessly tackling stuff that ought to be obviously too big to bite. But even if on mind-altering drugs, I would never ever make some of the design choices the designers of that drone did, unless I did those choices deliberately. So that is my yard-stick. Perhaps it is utterly, utterly wrong. I have no way to know for sure, just wanted you to know why I believe so –– what I believe is uninteresting, but the reasons why may be of interest and perhaps use to others.
That said, having done so much network service programming (a lot of web stuff, but plain 'ol TCP/IP, and more relevant to this particular stuff here, plenty of UDP/IP stuff too). UDP/IP in particular has the same kind of problems a remotely operated vehicle has: routers are free to drop UDP packets whenever they deem it necessary, so unlike TCP/IP, UDP/IP has no guarantees or features to provide any kind of reliability for the messages.
I guess having had to learn that the hard way over two decades ago, has colored my opinion of how reliable (rather, unreliable) real-world communications are. I am completely used to the idea of having messages lost and connections close mid-stream; and always plan well ahead how to deal with that. You could say it is one of the "details" I think about a lot when coming up with a design.
As an example, I would never use the same kind of control protocol to a remotely operated device as USB keyboards use. (Three types of messages are sent for each "keypress": a "press" event, optionally some "autorepeat" events at specific intervals if the key is being depressed for a sufficient duration, and a "release" event.) Instead, each control message would always contain a limit to its application – for example, "go that way at rate this, but stop doing that after duration then unless I direct otherwise" – because I've had even USB keyboard keys get stuck on systems that occasionally silently drop USB packets. Using UDP/IP, that sort of issue would be basically guaranteed to occur often enough to be noticeable to everyone. (And that assumes you've already learned to develop UDP/IP in a lossy test network. Because real world networks do not behave like the nice small closed test network you set up for testing; and you'd find that out the first time you used your stuff in the real world. Real world is a hard, effective teacher.)
So, indeed, I do need to re-evaluate my view on what one can expect from Arduino hobbyists; I admit my yard stick seems to be pretty bent. A banana. God dammit, I'm measuring in bananas again.
--- Quote from: Siwastaja on June 25, 2021, 12:14:42 pm ---2) Safety target is not even near to 100%; accidents are to be minimized within resource constraints; but resources can't be increased.
--- End quote ---
Drop that to say 50%, and I'm inclined to agree.
Still, I must point out that in my view/terminology, reducing safety target that low because of fiscal resource constraints, is still malice. It's not like the resources they were running out was energy or room or capability or such, just "business value".
--- Quote from: Siwastaja on June 25, 2021, 12:14:42 pm ---So Arduino is related; it was a project made by total hobbyists who can't take such a responsibility.
--- End quote ---
Yes; similar to how some people buy a gun and end up shooting themselves in the foot, or a biker they thought was a moose. Not malice, no, but negligence, perhaps?
It is not the existence of the tool or Arduino at fault, because this type of people end up doing much the same even if all they have are a bunch of rocks and a small satchel.
Some people say it is important to limit the access to such tools, but I disagree: I believe it is much better to just severely punish the idiots who misuse such tools. Kids and teens do get a pass, being still the responsibility of their legal guardians; so if they do it, punish their legal guardians instead. (I learned that from Robert A. Heinlein.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version