The trouble seems that there aren't many people that get software AND electronics AND mechanics AND on top of that marketing, right.
It is rare enough to find people with good electronics and software skills.
It is rare enough to find people with good electronics and software skills.
Once upon a time I worked for a manager who could only bring software instincts to any problem. He was dismissive, even, of ME problems. But not every problem can be solved in two-week sprints and pushed over LTE to the fleet. (Actually, if you want a good start-up idea, find a way to push a field update to a 5 kilo aluminum casting over LTE -- I'd invest in that.)
But here is the thing -- unless you can synchronize the release of software + electronics + mechanics, you don't have a robot. That means design, validation, component tracking, field updates, maintenance. You always need to take a step back and ask yourself what instincts to bring to a problem, and if you are weak in one/some of those areas, learn who's instincts you can trust and bring them in.
I am presumptuous enough to believe this applies to IOT mechatronics as well as robots. (Actually robots need more than SW+EE+ME, but this rant is already long enough.)
So in the good case this degree might broaden your horizon and teaches you that you don't know enough and in the bad case it might make you overconfident in even more areas while having even less knowledge than from a more focused degree.
Students should understand that what they learn at uni is as far from real world product development as possible. Uni does not have incompetent coworkers, unreasonable, conflicting or entirely missing requirements, scaling issues, vendors trying to screw you, procurement processes trying their best to prevent you from doing anything, faulty materials, etc. Knowing a bunch of mechanic formulas or software development patterns does not an engineer make.
MIT students have complained, after graduation, of finding companies that worked like soap operas.
At Uni you are taught many things including "things NOT to do"; some seeming quite obvious. I thought:
"Well, I shouldn't encounter those "things NOT to do" in the Real World TM, because professionals in the workplace have had 10 years to learn these lessons."
Ah, the naivety of youth...
Professionals are just people who convince someone to pay them for what they do. What they do doesn't have to include competence.
- They're all running at a rather leisurely pace, about 1 mask per second. That's very slow for a simple low-cost product. Compare textile machinery, progressive stamping presses, bottle making machines, and printing equipment. That's probably because demand for these things wasn't high until recently, and nobody designed a high-speed machine.
- The bottleneck seems to be attaching the elastic loops. The rest of the process is all roll to roll and could easily be 3x as fast. Is there some better way to do that?
- Can you get wider rolls of the source materials and build machines that make more masks at a time?
- At the output end, most machines just dump the finished masks into a bin. That loses order and count. They then need a separate packaging operation. They come out of the machine in a consistent position and orientation, which can be exploited. A better machine would put 10 or 20 masks put into a printed poly bag and heat-seal the bag. Then it would drop the bag into a waiting cardboard carton. When the carton is full, switch to a new carton. The filled carton gets a shipping label and rolls down a roller conveyor headed for shipping.
Compare [1], an N95 mask making machine, and [2], a paper cup making machine. The paper cup machine is doing a tougher job at 5x the speed. It has a flying paster, like a big printing press, so you can change rolls without a shutdown. The cups are shot out through a pneumatic tube to the cup stacking and packaging machine. That's why paper cups are so cheap.
I really wish my post-college engineering experience could be anything like that. I miss making useful things.
On the other hand, her first asp.net page was demonstrated by Steve Ballmer at CES, so she did advance in the world.
Unfortunately, the power assymetry between managers and engineers frequently manifests itself as you have described:
-- managers trying to understand everything through the lens of their past experience,
-- engineers trying to conform to managers (ie. using manager's language to formulate problems and solutions)
-- managers dismissing/prioritizing down areas, ideas, problems that they are not familiar, promoting/prioritizing up where they feel they have good understanding,
-- engineers responding by doing the same (ie. focusing on where they feel they will be rewarded by manager).
-- managers hiring/promoting based on their assessment of the candidates/employee competency in the area of expertise of the manager, because it is easier to rate candidate/employee competency if it is in your area.
-- managers failing to improve in areas where they are completely new. Maybe because people in general tend to want to improve in areas they already know. Maybe because they don't want to be seen as noobs making silly mistakes with experts around, and so trying shun entire area as less important so that the discussion can focus on where they are comfortable talking to experts.
-- so on...
So where a team works on a product that requires software/electronics/mechanics, the team, regardless of its initial composition, will over time get skewed in the area of expertise of its top manager.
Same goes for startup -- duo of guys who know software and electronics will inevitably look for products in the areas they know best. Not being able to quickly rate how difficult something is, mechanically, is definitely scaring a lot of people away.
I also noticed people dealing with software and electronics rarely mingle with mechanics/material experts which I think might also explain a little bit why there aren't too many enterprises that join those areas well.
From a SWE perspective, Robotics Engineers need to know physics and math than the average SWE learns.
Interestingly almost all the successful robot projects I've worked on seem to follow a waterfall process. You keep working on it till it works. After its ready don;t change anything.
I thought waterfall was to plan it out in detail, then do all the work according to the plan despite realizing that the plan is wrong, then finally, after disbanding the development team, test it to see if it works?
That's obviously a caricature, but if you have the feedback loop to see if it works while you're working on it, you might also call it agile.
Someone who came up through software intuitively knows that while "it is only a 3 line change in each of 4 files", making the change in master is only the beginning. Also on deck are: back-porting and validating in the 4 release branches still running on the 4 hardware versions in the field, and pushing the update reliably, oh, and it changes the log format so our log monitor query needs to be updated and validated.
EE -- yes, it is just changing out one connector -- but we need the latching version and only two latching variants are available, and one requires moving a mounting hole which would require chassis rework, the other is expensive and has a 12 week lead time... and in any case we need to update the test fixtures. And we need to keep some of the old test fixtures around for the old rev, and while we could save some money by reworking some of our old test fixtures, who has time to write and validate the engineering change order for the test fixture rework?
ME -- yes it is only moving two mounting holes, but both the chassis and the skins need to move, so we either have to rework the fleet to accept new skins, or do two sets of expensive tooling for the skins, or do some kludge adapter that allows new skins on old chassis, but we need to vibration test that.
Intuition and instinct are about understanding the implications and the unarticulated risks buried with decisions.
Having worked in this space, the failures usually come from lopsided teams. Too many startups try to treat these products as technology products with a side of building materials, assuming that the technology is the hardest part.
In reality, the technology part is easy. The most difficult part is manufacturing and shipping reliable mechanisms at low cost. It can be done, but the mechanisms and mechanical parts need to be treated as the primary product, not an afterthought.
A mass market automated pill dispenser you can just dump your prescriptions in seems like an obviously viable product. But, building something that’s easy enough to use, reliable enough to be safe, and cheap enough to be affordable is a pipe dream.
However, pills are of wildly different shapes and sizes, which invalidates most of the seemingly obvious sorting solutions. Prescriptions can also call for multiple pills in the same day.
I think the main weakness is that for a few folks, medicine changes would be difficult because they often are mid-week or mid-month and for some, they would really need their medicines re-packaged. I'm not sure this is as big of a problem in nursing homes and whatnot because the nurse is dispensing the meds, while some folks at home have bad memories or the beginnings of undiagnosed dementia and just won't remember.
Though the number of old folks is getting larger, so maybe that's a market by itself.
I know for a fact that my parents and my wife's parents would all love this.
My mother was a nurse, so she handles it better than most, but she still spends an hour a week on it.
Never mind that an internet connected, custom-engineered juice press was a bad idea in the first place. It was still out-manufactured by simple tools like a garlic press, or a little metal thing you twist your fruit on top of. Or a blender.
You have to look in the manual to add or remove a code, but it remembers at least a dozen codes. It doesn't talk to a smartphone. It doesn't have a network connection. It doesn't store a log of openings, and it doesn't violate your privacy.
What it does is solve the two biggest problems with door locks: not having your key, and getting a key to a friend so that they can get into your house.
But I wonder how it’d fare if someone like the lockpicking lawyer reviewed it’s mechanical lock design? Is it actually a good lock?
I'm not convinced it matters as long as it seems, to the layperson, to be a lock of average quality. No one really wants a lock to feel insecure if it is held in the hand, for example. And sure, if tests say you can just hit it and open it, you'll pass. But as long as it doesn't have obvious defaults... It is good.
Most locks really just keep out crimes of opportunity. Few folks have locks that will keep out folks that would destroy your front door or break your windows and few are real challenges to lockpicks. And the shouldn't be challenges to lockpicks! Otherwise, how would a locksmith do their work? It doesn't matter, though. Most folks simply aren't lockpicks - and a good number of folks that can* pick locks well do not have desires to break into homes.
There's also a perception that software is more valuable than hardware, which can affect the workplace culture in a negative way.
That should be my niche (if it's small enough to be called one), but I've worked firmly in software since graduating a few years ago, and I'm increasingly worried that I'm unhirable for anything else, even if I brushed up with some hobby electronics at home, despite it being electronics that got me into CS.
Is there any truth to that? Would I have to start over in a grad role for anyone to hire me for hardware? (I'm not actually looking, I just don't like the thought that the road's closed, my next job has to be software.)