Is Arduino killing the electronic hobby?

[SiliconWizard]

The thing I remember most from my electronics hobby in the 80s-90s was how much harder it was to find parts. There wasn't much nearby besides Radio Shack and they almost never had all the parts I needed to build anything. I think DigiKey was around, but I didn't know about it and would have had to get my parents to call them up and order stuff.

I was lucky to have an electronics store in my city which had a lot more than your typical Radio Shack. I would go there with a list of parts - pretty much looking like a BOM - and they usually had most of them.

As to books, many specialized books were pretty expensive too. So what I'd do sometimes is go to a library shop, spend some time in the Electronics section and read chapters in books without buying them.

[ataradov]

My dad had all the components I could have ever wanted. Without that I doubt I would be doing electronics at all. There were definitely no component stores in 90s Russia, and only grownups could get the components though all sorts of sketchy ways.

I also found in backups my first ever MCU-based project. It was a replacement controller for the Sharp microwave oven and the file is dated March 2000. Here is the complete source code for some random 8051 MCU https://pastebin.com/raw/6Q2sHjwP Not too poorly written actually for what it is.

[rstofer]

My issue with Arduino is that sometimes people that only used Arduino assume they know how to do actual product development and apply for the real programming jobs. That never ends well.

Case in point: https://assets.publishing.service.gov.uk/media/602bb22f8fa8f50388f9f000/Alauda_Airspeeder_Mk_II_UAS_reg_na_03-21.pdf

65 pages of wasting time!  Where in that tome is the reason for the 'Case in point'.

In any event, even real airplanes fall out of the sky when things go wrong.  The Boeing 737-MAX, a brand new design, has crashed a couple of times and they used real engineers and everything.

[tooki]

The thing I remember most from my electronics hobby in the 80s-90s was how much harder it was to find parts. There wasn't much nearby besides Radio Shack and they almost never had all the parts I needed to build anything. I think DigiKey was around, but I didn't know about it and would have had to get my parents to call them up and order stuff.

Digi-Key has been around since 1972 and Mouser since 1964. Newark was a shop opened in 1934, with their first catalog in 1948! But like you, as a kid in the 80s, I didn’t really know about any of them (nor McMaster-Carr.) I got my stuff from Radio Shack and the various cheaper ads in the back of Popular Electronics. I’m sure DK and Mouser advertised in that, but I had no way of realizing just how much more they carried than the other guys.

[rstofer]

I would only give someone the 555 suggestion as an alternative to the Arduino, or if they specially wanted a more discrete solution, or if they had specific requirements such as size, parts cost, or something.

Arduino is far from perfect and I certainly groan when I see it in a "professional" product although if it does the job it can make sense.  But the complaining about people learning electronics through Arduino is just silly "old man yells at cloud" nonsense.

It probably turns out that an 8 pin uC uses fewer components than a 555 for any configuration.  We don't need the timing capacitor or the resistors for astable operation.  Adjustable frequency will still require a potentiometer and perhaps a second if we want to set pulse width.  The uC can generate symmetric waveforms, the 555 needs a lot of help to do the same.

I decide to design a new 'widget'.  I look around and decide that an ATmega328P would be a good choice for my project but I need a development board to get started on the code.  Oh, wait, I could do the preliminary work on an Arduino and just unplug the chip.  Half of my work is already done because libraries exist for just about everything.  Even if I don't use the Arduino libraries, I can rip the code from the source files and modify it to suit my needs.  I don't have to write everything from scratch.


I view the Arduino as a universal gadget, usable at many levels.

[langwadt]

The thing I remember most from my electronics hobby in the 80s-90s was how much harder it was to find parts. There wasn't much nearby besides Radio Shack and they almost never had all the parts I needed to build anything. I think DigiKey was around, but I didn't know about it and would have had to get my parents to call them up and order stuff.

yeh, when I was a kid there was one electronic store here and they they (he) usually didn't have the parts you wanted, when he closed there was none.
Now 20 years later there are several online hobby stores that delivers overnight and has a huge selection of electronic parts, kits, and lots of mechanical stuff as well, in addition to the huge selection of internal stores with a bit of patience

[ledtester]

If you're interested in how things were done in the last century, you might spend some time browsing through the Encyclopedia of Electronic Circuits series compiled by Rudolf Graf.

One of the circuits in Vol. 1 is the "Computalarm" which has a rather sophisticated mode of operation despite not containing a "computer"!

The circuit has a built-in, self-arming feature. The driver turns off the ignition, presses the arm button  on the Computalarm, and leaves the car. Within 20 seconds, the alarm arms itself -- all automatically! The circuit will then detect the opening of any monitored door, the trunk lid, or the hood on the car. Once activated, the circuit remains dormant for 10 seconds. When the 10-second time delay has run out, the circuit will close the car's horn relay and sound the horn in periodic blasts (approximately 1 to 2 seconds apart) for a period of one minute. Then the Computalarm automatically shuts itself off (to save your battery) and re-arms. If a door, the trunk lid or the hood remains ajar, the alarm circuit retriggers and another period of horn blasts occurs. The Computalarm has a "key" switch by which the driver can disarm the alarm circuit within a 10-second period after he enters the door. The key switch consists of a closed circuit jack, J1, and a mating miniature plug.

[eti]

I've seen this topic before, in various guises. A HUGE waste of time and energy is wasted on this. Void thread, bin it.

[james_s]

65 pages of wasting time!  Where in that tome is the reason for the 'Case in point'.

In any event, even real airplanes fall out of the sky when things go wrong.  The Boeing 737-MAX, a brand new design, has crashed a couple of times and they used real engineers and everything.

I thought it was well written and very comprehensive, the sort of investigation I'd expect for any aircraft crash. This was not some kids quadcopter, this was a 9 foot long unmanned aircraft weighing several hundred pounds and it was chock full of rookie mistakes. Yes real airplanes crash too but this thing was virtually guaranteed to crash and it's only dumb luck that it didn't kill somebody or cause serious property damage. Deciding that upon loss of radio signal the craft would continue at the present throttle setting rather than gradually decrease for a more or less controlled landing or deploy a chute is mind blowing. Declaring redundancy because there are four motors is idiotic, anyone who has ever flown a quad knows that if any one of those four motors fails the thing falls out of the sky. Four motors is not an asset in terms of reliability, it is a liability. It's very clear that none of the people involved were engineers and certainly not with any background in aviation. It looked like some kids who had some experience building and flying toy quadcopters thought they could simply scale up the design and call it good. That is exactly the point, illustrating the problem when hobbyists get arrogant and think they are real engineers. That's not to say that there aren't some extremely skilled hobbyists out there but these guys are not them.

[Nominal Animal]

Case in point: https://assets.publishing.service.gov.uk/media/602bb22f8fa8f50388f9f000/Alauda_Airspeeder_Mk_II_UAS_reg_na_03-21.pdf

Ah yes: a "dead man's switch" implementation which requires a separate person to go check the pilot, and if still struggling, put him out of his misery with a switch.

Their "kill switch" was literally a LoRaWAN module that in theory should be able to energize a relay to cut off power to the rest of the device.  The incident occurred, because this "kill switch" could not contact the drone to "kill" it.

That sort of stupidity is not characteristic of the Arduino environment; it is characteristic of humans who believe their stuff is more valuable and therefore always to be prioritized over any risk to others.

(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.  And since the device at hand was a flying death trap of over 90kg of metal, plastic, and glass fibre, including several high energy Li battery packs easily capable of causing a fire individually, the "designer" was an idiot who apparently felt that killing someone else would have been preferable over losing the device itself.  They should be prosecuted, and never allowed to "engineer" anything more complicated than a ditch in the ground ever again.  May sound hyperbolic, but when a person shows they are willing to risk the lives of others to reduce the risk to their own property, they need to be evaluated and judged by the same criteria they applied to others, or they'll never change their behaviour.)

[Brumby]

"Is Arduino killing the electronic hobby?"

No.  It is saving it.

The key point to remember is that the hobby - LIKE EVERYTHING ELSE IN THE WORLD - is changing.  Today's society is used to better communications, better health, better engineering, better just-about-anything than previous generations.  Higher quality, lower price, improved functionality, greater choice ... and many other aspects of the utility of the things around us.  As a result, our expectations are much higher and attaining that "WOW" factor that fired up young imaginations is now at a much higher level.

Our joy came from achieving something that was not found in the everyday.  We CREATED something to do our bidding.  That desire and reward hasn't changed, only the platform on which it is built .... it's a lot higher these days.

It is very much a matter of "standing on the shoulders of giants".  Today's younger geeks can see greater possibilities than we did in our day, only because those that went before have built upon the work of those before them.  Here is where we see the earlier developments become commonplace and what we consider unremarkable today would have blown our socks off in our school days.  I still remember sending off a bank cheque payable at the Chemical Bank New York, New York for some 7400 series ICs at prices that made it worth the wait for snail mail to the USA and back.  One of the projects I made with them - and a piece of Veroboard - was a digital clock.  Did I not do electronics because I used ICs instead of discrete transistors?

Let the Arduino crowd do their thing.  They are involved with (one facet of) hobby electronics.  It is an entirely valid corner of the electronics playground and quite appropriate for the characteristic direction of development across a broad spectrum of disciplines: specialisation.

As a final point, I would ask this....  If YOU were able to get your hands on something like an Arduino when YOU first started out in electronics, wouldn't YOU have jumped at the chance?  (Aside from the fact that most of us wouldn't have had something to run the Arduino IDE on  )

[RoGeorge]

- Is Arduino killing the electronic hobby?
- Is the other way around.  Electronic hobby is killing Arduino.  With every day.  Countless Arduino are misused, abused and killed in electronic hobby.  It's a massacre out there, a true Arduino genocide, I tell you! 

[james_s]

Case in point: https://assets.publishing.service.gov.uk/media/602bb22f8fa8f50388f9f000/Alauda_Airspeeder_Mk_II_UAS_reg_na_03-21.pdf

Ah yes: a "dead man's switch" implementation which requires a separate person to go check the pilot, and if still struggling, put him out of his misery with a switch.

Their "kill switch" was literally a LoRaWAN module that in theory should be able to energize a relay to cut off power to the rest of the device.  The incident occurred, because this "kill switch" could not contact the drone to "kill" it.

That sort of stupidity is not characteristic of the Arduino environment; it is characteristic of humans who believe their stuff is more valuable and therefore always to be prioritized over any risk to others.

(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.  And since the device at hand was a flying death trap of over 90kg of metal, plastic, and glass fibre, including several high energy Li battery packs easily capable of causing a fire individually, the "designer" was an idiot who apparently felt that killing someone else would have been preferable over losing the device itself.  They should be prosecuted, and never allowed to "engineer" anything more complicated than a ditch in the ground ever again.  May sound hyperbolic, but when a person shows they are willing to risk the lives of others to reduce the risk to their own property, they need to be evaluated and judged by the same criteria they applied to others, or they'll never change their behaviour.)

In this case it's not quite that simple, with an aircraft that large and heavy that is totally incapable of gliding will fall out of the sky like a rock if the kill switch is activated, an accidental activation of the kill switch very well might result in injury or death just as a failure to activate it. The real problem (among many others) is the idiotic failsafe behavior that causes it to keep flying if signal is lost. The hard kill should be a very last resort, prior to that if the signal is lost the craft should attempt a controlled landing. This is not hard to do, even $40 toy quadcopters these days have an auto-land feature. Rather than plummet out of the sky and smash into whatever happens to be below it, the craft should attempt to get as close to the ground as possible before shutting off. Really it should have multiple redundant onboard GPS receivers and try to return to the location it took off from. If the GPS position it sees is further from the takeoff location than would reasonably be possible for the craft to have reached (suggesting GPS malfunction) the craft should enter a panic mode and attempt a soft landing wherever it happens to be.

[RoGeorge]

in my opinion, the history of electronics is important from an educational point of view.
because electronics is so complicated and diverse, starting at the beginning and continuing to the present time.
is a good place to start. the skill is knowing what parts of electronics history are important for getting to the final conclusion.

Agree!! When I was an adjunct creating and teaching some grad school courses on RFIC design, I tried to convince folks at the university that a really good Electronics History course is not an option for a good well rounded EE student but a requirement, they didn't agree and no course

Electronic History would have been a great theme for an EE class.  Maybe some youtube classes, or a book instead.

The EE history idea reminded me about the first chapter from "Planar Microwave Engineering" by Thomas Lee.  It's a condensed history of EE and a very entertaining read.  Everybody "brush and floss after every meal, and visit your dentist regularly", because outch, it hertz what happened to Hertz!   

That chapter is free to download as a sample from the book:
https://assets.cambridge.org/052183/5267/sample/0521835267ws.pdf
https://www.cambridge.org/highereducation/books/planar-microwave-engineering/CA50D727AD97C3F4789065F1F9DB0771#overview

[langwadt]

Case in point: https://assets.publishing.service.gov.uk/media/602bb22f8fa8f50388f9f000/Alauda_Airspeeder_Mk_II_UAS_reg_na_03-21.pdf

Ah yes: a "dead man's switch" implementation which requires a separate person to go check the pilot, and if still struggling, put him out of his misery with a switch.

Their "kill switch" was literally a LoRaWAN module that in theory should be able to energize a relay to cut off power to the rest of the device.  The incident occurred, because this "kill switch" could not contact the drone to "kill" it.

That sort of stupidity is not characteristic of the Arduino environment; it is characteristic of humans who believe their stuff is more valuable and therefore always to be prioritized over any risk to others.

(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.  And since the device at hand was a flying death trap of over 90kg of metal, plastic, and glass fibre, including several high energy Li battery packs easily capable of causing a fire individually, the "designer" was an idiot who apparently felt that killing someone else would have been preferable over losing the device itself.  They should be prosecuted, and never allowed to "engineer" anything more complicated than a ditch in the ground ever again.  May sound hyperbolic, but when a person shows they are willing to risk the lives of others to reduce the risk to their own property, they need to be evaluated and judged by the same criteria they applied to others, or they'll never change their behaviour.)

In this case it's not quite that simple, with an aircraft that large and heavy that is totally incapable of gliding will fall out of the sky like a rock if the kill switch is activated, an accidental activation of the kill switch very well might result in injury or death just as a failure to activate it. The real problem (among many others) is the idiotic failsafe behavior that causes it to keep flying if signal is lost. The hard kill should be a very last resort, prior to that if the signal is lost the craft should attempt a controlled landing. This is not hard to do, even $40 toy quadcopters these days have an auto-land feature. Rather than plummet out of the sky and smash into whatever happens to be below it, the craft should attempt to get as close to the ground as possible before shutting off. Really it should have multiple redundant onboard GPS receivers and try to return to the location it took off from. If the GPS position it sees is further from the takeoff location than would reasonably be possible for the craft to have reached (suggesting GPS malfunction) the craft should enter a panic mode and attempt a soft landing wherever it happens to be.

https://en.wikipedia.org/wiki/Battleshort

[Nominal Animal]

The hard kill should be a very last resort, prior to that if the signal is lost the craft should attempt a controlled landing.

I fully agree.

How to shut down in the case of unrecoverable failure is a complicated matter.
You just do not make such an emergency shut down dependent on transmitting a separate signal like the designers of that craft did; you need to detect the failure in the first place and not just ignore any failures and trust a separate signal.

It is important to realize that in that crash case, the craft was basically designed to completely ignore loss of communications, and only had a kill switch of some sort that relied on a separately transmitted signal.  That's what the report states, anyway.

Furthermore, that signal was intended to energize a normally closed relay, to cut off power to specific parts of the craft.  A typical failure of such a relay means that even when a signal is transmitted, it would have no effect. At least a normally open relay would change state whenever powered on or off, and would be more likely to fail into the emergency state; a normally closed relay is more likely to fail into the closed state.  If the supply providing power to the normally closed relay failed, even when received, the kill signal would have zero effect.  This design is insane.

It is true, though, that I might attribute to malice something that was really only based on utter stupidity.  Just because I believe sheer stupidity is not enough and malice is required to design that drone as it was, does not make it true.

[james_s]

I don't see any signs of malice at all, it is entirely believable that the people who designed it did what they did out of shear ignorance. They are apparently not trained engineers but hobbyists. For a typical hobbyist quadcopter the design while not great was adequate. It's normal to not have any sort of remote kill feature at all, however you can normally program the flight controller to reduce throttle if a loss of signal occurs.

[2N3055]

I don't see any signs of malice at all, it is entirely believable that the people who designed it did what they did out of shear ignorance. They are apparently not trained engineers but hobbyists. For a typical hobbyist quadcopter the design while not great was adequate. It's normal to not have any sort of remote kill feature at all, however you can normally program the flight controller to reduce throttle if a loss of signal occurs.

It was a scaled test of human carrying vehicle that weighs 100kg... There was nothing adequate on that idiotic design, except thrust...
It should have been hard configured to land autonomously if it looses the signal, and all communication must have been two way with transaction confirmation...
And that is just plain common sense, nothing advanced or "professional" about that way of thinking.

[james_s]

I don't see any signs of malice at all, it is entirely believable that the people who designed it did what they did out of shear ignorance. They are apparently not trained engineers but hobbyists. For a typical hobbyist quadcopter the design while not great was adequate. It's normal to not have any sort of remote kill feature at all, however you can normally program the flight controller to reduce throttle if a loss of signal occurs.

It was a scaled test of human carrying vehicle that weighs 100kg... There was nothing adequate on that idiotic design, except thrust...
It should have been hard configured to land autonomously if it looses the signal, and all communication must have been two way with transaction confirmation...
And that is just plain common sense, nothing advanced or "professional" about that way of thinking.

I said the design was adequate for a hobbyist quadcopter, NOT for this much larger aircraft. The whole project has the appearance of a group of average drone hobbyists who naively thought they could just scale up a toy quadcopter and call it good. Obviously this is not true.

[RoGeorge]

Case in point: https://assets.publishing.service.gov.uk/media/602bb22f8fa8f50388f9f000/Alauda_Airspeeder_Mk_II_UAS_reg_na_03-21.pdf

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?   

[2N3055]

Case in point: https://assets.publishing.service.gov.uk/media/602bb22f8fa8f50388f9f000/Alauda_Airspeeder_Mk_II_UAS_reg_na_03-21.pdf

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?   

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]

(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.

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]

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.

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]

I think you may be
1) oversimplifying the design,
2) underestimating the rationale that went into that decision.

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.

2) Safety target is not even near to 100%; accidents are to be minimized within resource constraints; but resources can't be increased.

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".

So Arduino is related; it was a project made by total hobbyists who can't take such a responsibility.

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.)