That sounds odd. The way it was done in every place I worked, is that a set of changes were approved for a release before they were planned and implemented. We organized the work as expected: each bug/feature on its own branch, with its own set of unit tests, etc., and automated testing applied on each commit. These branches are then merged to the integration branch once they are known good. Before the release process starts, QA would get a copy of the integration branch and test that.
The dependency problem doesn't exist, because all the features were already approved to be in the release. The only way there would be a problem is if someone decided late in the game to pull a feature and that feature was a dependency to something else.
Not all buyers are using loans. First house I sold was to someone who refused title insurance because in his words, "that house has been sold 3 times in 10 years, the title's fine."
As an aside, I'm told that Title companies make absolute bank. Most buyers get title insurance, but the insurer very rarely ever has to make a payment.
The problem is that everyone is having that idea at the same time! Posts on /r/embedded asking a related question keep being shut down because there are so many web developers now asking daily how they can get into embedded systems because of a perceived lack of LLM penetration.
No such thing! Companies that aren't already actively using AI for embedded development are looking closely at it and experimenting with procedures to incorporate into their workflow. Why anyone would think that a company would ignore a potential improvement to their bottom line is beyond me.
Yeah, it might take a while, but it will happen faster than you think.
Custom machine building is a very difficult business to be in. As you mentioned, it's hard to scale. I knew of a particular service provider (custom motion systems) whose philosophy was to break even on the first job and profit on any followups.
There are many, many, many solutions like this on YouTube from all over the world. I have to admit that there do seem to be more Russian ones than anyone else, but maybe they're just better at posting video. I've seen an insane amount of homebuilt tractors and offroad vehicles coming out of russia.
Not avionics, but I've spent most of my career in medical devices. A project's Design History File would indeed have the detailed design documentation of the system. The problem would be that word "detailed." The relevant standards state that the documentation should be sufficient for a normally-skilled engineer to recreate the (software) system, but how stringently that is applied can be very hand-wavy. And then there's the problem of drift where the software changes and the docs are updated, but perhaps not as precisely as they should be, and different people have different levels of documentation rigor. Well, you can see how it ends up 20 years later.
I'm actually dealing with exactly this problem on an old project right now :-(
> conformal coating (which I hate for reverse-engineering), which is usually omitted from prototypes
Bad memory from a couple years ago. Debugging a machine under development at a customer site, which was luckily only a few blocks from the office, since I was there a lot, I would get random resets, hangs, and loss of debug information from the SWD probe. Swapping boards, debug probes, nothing we could think of fixed it and it was so random it was hard to track down.
Long story short, after it happened on one occasion when the project EE was also debugging something and he touched one of my probes, we found that there was conformal coat residue on some of the debug pins and the probes would occasionally vibrate onto an insulated section, causing loss of signal.
No idea why the board house put it on a prototype, but we probably lost a few dozen hours due to that one problem.
It's been long enough ago that I don't use it as an interview answer anymore, but one of the most interesting things I built (technique-wise) was a Z-80 based serial multiplexer with no RAM. The only volatile memory it used was the device registers. The fun part was handling subroutine calls without a stack. The Z-80 has an indexed jump mode, so before calling a subroutine, I'd fill the jump register with the statement after the subroutine call, and when the subroutine was done, execute the jump with the (return) address prefilled.
Anything to save a few bucks on a 6264 SRAM component :-)
People move around: that's what cars are for. Trucks may not be "designed for urban areas" (whatever that means), but they certainly go into them on a daily basis.
With a range of 77 miles, I wouldn't make it to work and back. Everyone I know (yes, it's anecdotal, but a widely-shared one) has to commute on roads where the average speed is well above 30mph.
For a significant segment of the US population, that thing wouldn't get them to work and back, so they'd have to charge it both at home and at work. And in many cases, forget running any errands, picking up kids from daycare, etc.
And minimum speed on US interstates is typically 40mph, so that reduces its usability even more.
It's very dated by now, but The Control System Design Guide by George Ellis is a pretty good hands-on book about designing and analyzing control systems. It goes well beyond the basic PID stuff, but I found it very helpful when I was getting a Mechatronics certificate 20+ years go. TBH, it's the most accessible book on the subject that I've ever read.
> we will replace most PIDs with a small neural network for almost all industrial applications
A similar argument was made in the early 90's/late 80's for using Fuzzy Logic (https://en.wikipedia.org/wiki/Fuzzy_logic) instead of classical control algorithms, including PID.
I'm sure many here will remember the late Bob Pease of National Semiconductor writing articles[1] against this, mainly due to the inability of the designer to predict the behavior of the system. Believe it or not, being able to logically reason about how an algorithm that's controlling tens of thousands of $$$ of product in process is actually important.
Available for smaller projects (sub-80 hours), consulting, or to just shoot the breeze.
[email protected]