They have a range of personal/SOHO routers that all run officially-supported-by-manufacturer OpenWRT, and their own UI skin isn't bad (though easy to switch to LuCI if you want)
Reading through their support forums is what sold me on them - their firmware engineers actually pay attention to issues, engage in threads, and respond with patched firmwares.
Coming from a heavy MSSQL background two things pleasantly surprised me about PG's copy, both of which are mentioned rather casually in the article:
1. The CSV data can be streamed over STDIN that is read over the driver connection. This takes the "write a file over a networked filesystem that the DB server has access to" overhead completely out of the equation.
2. The overhead of bulk insert is shockingly low - in some ad-hoc benchmarks we did for our use case, we were breaking even between regular batch prepared statement inserts and copy-based bulk insert at around 10 records, and by 100 records we were already seeing the same factor of speedup that the article demonstrated.
Both are survivable, but in general a helicopter autorotation is much less forgiving. (source: I have a private helicopter pilot license)
In a airplane, a loss of engine power translates to slowing down. If you're on top of things, you will notice this and nose-down in order to maintain airspeed. If you fail to notice this, your airplane will stall, but even that can be recovered from by nosing down in time.
In a helicopter when you lose power this translates very quickly (with 4-5 seconds) into loss of rotor RPM. Within 1-2 seconds you must change the angle of the blades in order to enter the autorotation configuration - if your rotor speed drops below a certain RPM before you make this change, you drop out of the sky with no chance of recovery. Making this an automatic reaction is a big part of helicopter pilot training.
Once you have entered autorotation/glide, the next challenge is finding a suitable place to land. In both cases you ideally need a flat hard open surface, though airplanes generally need a longer area than helicopters. Unfortunately a helicopter has a very poor glide ratio - ~5:1 (5 feet horizontal for 1 ft vertical) while a light airplane has something like ~9:1 glide ratio. Furthermore most helicopters cruse at much lower altitudes (1K-3K ft above ground level) vs. light airplanes cruising 4K-8K ft AGL). So you end up having 1/2 to 1/4 the time and distance to find a suitable landing site.
When it comes to the actual landing itself, gliding vs autorotation are different but one is not necessarily more dangerous than the other. In both cases you have a well-defined set of ideal airspeeds, descent rates, etc. which will lead to everyone surviving the experience. And in both cases you don't earn your pilot license until you have demonstrated that you can consistently do this correctly.
One more nuance - light airplanes (eg: Cessnas) are easier to glide than heavier/faster airplanes because everything happens slower. Since light airplanes are also the cheapest to operate, they are most often found in the hands of new/inexperienced pilots - it is good that they are forgiving.
Meanwhile light helicopters like the Robinson R22 are actually much more difficult to autorotate than larger/heavier helicopters - everything happens faster and is less stable. Unfortunately since these helicopters happen to be the cheapest to operate, they also very often find themselves in the hands of new/inexperienced pilots. This was such a big problem that there is a special piece of federal aviation regulation (SFAR 73) which puts additional training requirements on pilots specifically for the Robinson R22 and R44 models.
In the big picture though, general aviation is incredibly safe. The vast majority of non-commercial accidents can be attributed to some form of human error - either poor pilot judgment or lax adherence to maintenance requirements.
I personally think MakeBlock (http://www.makeblock.com/) does a great job of being a modernized metricized replacement for Erector sets.
It's not particularly cheap - probably costs ~$300 to get a decent sized kit or a smaller kit with enough spare parts to experiment.
All of the mechanical parts are machined reasonably well and fit together in a large number of useful configurations - I really like them for rapid mechanical prototyping.
The electronics are basically arduinos with beginner-friendly connectors - haven't used them myself but have generally heard good things about them.
I can't speak to how their technology actually works, but here's a quick lay-of-the-land for how it could work / how you could start your own similar business:
The two most popular manufacturers of higher end drones - DJI and 3DR use standard 802.11 radios for control, telemetry, and FPV video streaming if supported. The manufacturer transmitters include slightly directional amplified antennas so they get better range than your smartphone would, but it's all IP over 802.11. This means all your standard WiFi hacking tricks are perfectly useful here.
If you were looking to hijack a DJI drone, https://github.com/noahwilliamsson/dji-phantom-vision would be a good place to start. The only hardware you would need is a standard 802.11abgn network card and a directional power-amplified antenna.
Most other higher-end drones use two separate radios - one for control (typically running either the Spektrum or Futaba RF protocols over a 2.4GHz link) and one for telemetry (typically running MAVLink over some sort of FHSS link on 433MHz or 900MHz).
Hijacking the control side of one of these systems would require dedicated radio equipment - in the case of Spektrum's DSM protocol, some sort of CYRF wireless-USB chipset board. Spektrum's DSM/DSM2/DSMX protocol is not open-source, but a lot of effort has been put into reverse-engineering it and you can see sample DSM-compatible firmware for a CYRF-based USB transmitter board here: https://github.com/1bitsquared/superbitrf-firmware
Hijacking the telemetry channel could also yield control over the drone - depending on the flight controller and firmware used, you could issue MAVLink commands to either return-to-home or fly to specific coordinates. MAVLink is a serial protocol layered over a semi-reliable radio link - to interfere with it, you'd first have to hop on the link and then intercept/override the serial command stream.
Theoretically MAVLink can run on top of any radio which exposes a serial link interface - some hobbyists use bluetooth, but most people eventually switch to using longer-range telemetry radio modules running on either 433MHz or 900MHz bands. Most of these radio modules run a particular open-source FHSS firmware known as SiK - https://github.com/Dronecode/SiK
If you look at the SiK source, you can see their implementation of FHSS and should be able to figure out how to search for, lock onto, and potentially interfere with a particular radio link.
Beyond the major manufacturers, there are hundreds of smaller drone manufacturers, and the radio protocols and systems they use vary from manufacturer to manufacturer and model to model. As a general rule, anyone claiming "iPhone app control" is running some sort of 802.11-based protocol (eg: Parrot / Bebop), while even smaller and cheaper drones are running custom 2.4GHz RF links.
One final consideration - most drones have varying degrees of failsafes programmed into them in the event of a loss of control signal (potentially through RF jamming). Cheaper drones will simply shut off and fall out of the sky. More advanced drones / controllers can perform one of a number of behaviors, including loitering in-place or returning to their original launch location.
One more final consideration - most of the interference and hijacking methods described here are very much of questionable legality in the FCC's eyes. Also there are enough existing reasons drones fall out of the sky (bad piloting, unreliable hardware, poor maintenance) - we don't need to add another reason. Be safe, be responsible, and be legal.
Before you write off your company and teammates, get over your own ego and learn how to learn from others.
A defining characteristics of rockstars is that they know what they know and they know what they don't know, and they are honest with others about the boundary. An idiot is not someone who says "I don't know how to X" - it's someone who says "I know how to X" but really doesn't.
Here is how I learn from people smarter or more experienced than me:
1. I look at a problem someone else is working on, and ask myself "how would I solve this?".
2. Then ask myself "why would I solve it the way that I did?". Is it because it's the only solution I could think of? Or is it because there were multiple approaches but the one I chose was best for reasons and assumptions X, Y, and Z. The important thing here is to be honest and rigorous about why I made the decisions I did - no settling for "just because"
3. Then I look at what the other person did. If it's identical to what I would have done, I give myself a cookie! If it's not identical, then I spend time to answer the following questions:
- How is their solution different from mine
- Does each difference matter? If so, how/why?
- For each difference, why is their choice better than mine?
4. Now this is the important step - I then talk to the person. And instead of giving them an open-ended "why did you do solve this problem in this way", I describe to them what I would have done and ask them the same questions from the previous step. These are small, simple, efficient questions so you're not wasting the other persons time, but by confirming your own answers, you are reinforcing your ability to learn and are avoiding living in ignorance.
5. I observe the other persons reaction to this interaction. The vast majority of professionals I have interacted with have at the very least been willing to help me in this way because they understood that teaching a teammate is overall a net positive to the team. And it should increase their confidence in the quality of the work that I do on my own.
If the person refuses to make time to even answer simple specific questions or is actively hostile towards the very act of me asking these types of questions, I write them off as assholes and move onto someone else.
Now I really suspect that most of your team will not be assholes. But even if they are, assuming you're being compensated well enough to tolerate them, all you need is one non-asshole who is "better" than you to learn from and bam - you have a mentor.
If literally everyone is an asshole (per the definition earlier), then I look at how much I'm being compensated (cash, equity, status, pedigree) and will either get out or check out.
But the important first step is making an effort to become better, and using the other people you work with as resources. It's okay to do this stuff offline - if your team is having a high-level design session, don't open your fool mouth to ask "why don't we just write all this in a single function" and waste everyones time. But if that's really the best solution you could come up with, pull aside one of the other people and confess "I would have done this all as a single function - why is that wrong and why did you break things out in this way?"
They have a range of personal/SOHO routers that all run officially-supported-by-manufacturer OpenWRT, and their own UI skin isn't bad (though easy to switch to LuCI if you want)
Reading through their support forums is what sold me on them - their firmware engineers actually pay attention to issues, engage in threads, and respond with patched firmwares.