I cannot beleve some of the posts on this site. Turning you car OFF will not lock the steering wheel the car must be in park for it to lock. Try it in you drive way someday start you car put it in drive and turn it off and see if you can lock the wheel. Make sure the brake is on at all times. As for driving with both feet which is a pet peeve of mine I think that would take a lot off drivers off the road itself. This is knee jerk reaction by the goverment and a very poor soultion at that. Fixing the problem and educatioing the public about what to do is whats needed.
When driving a manual, a useful technique is heel/toeing where you apply the brake and blip the throttle so you get a clean downshift. This "solution" would preclude doing that. It would make downshifting in low-friction conditions more dangerous, because the revolutions of the engine & transmission couldn't be matched as well. Then again, manuals seem to be going the way of the dodo these days...
This is fixing the wrong thing. The machine isn't broke, the drivers are. You can stand on the accelerator and brake pedals on a 600 hp Corvette and it won't 'override' the brakes. You can also turn off the key...(I know the steering locks, but that's better than headon at full throttle into whatever is in the way.) And why does the steering lock? Another answer to trying to fix stupid. This proposed fix will create problems for those mechanics, read drivers, and others who know the difference between the pedals on the floorboards of whatever they are driving.
I can see why the automakers are on board with this. It's a simple, cheap, technical solution to an ongoing problem. It's also going to be one more big hassle for competent drivers who have occasional need to do things slightly "outside the box". The first thing I would do if I bought such a vehicle is bypass the brake actuation sensor.
I can think of three main occasions for applying the brakes and throttle simultaneously. Starting on a hill with a stick shift is the obvious one. The less obvious ones are drying the brakes after driving through water, and increasing traction when one wheel is spinning on ice or gravel and the other is on bare pavement. In such a situation, with an open differential, a bit of light braking will sometimes slow the spinning wheel enough that enough torque will be transferred to the wheel with traction to get the vehicle moving.
There may well be some techinical problems with drive-by-wire systems in which a malfunction could cause the throttle to stick open, but the bottom line is that all these "stuck throttle" cases come down to operator error. Most of the time, the driver is frightened or feeble-minded and accidentally reacts to unwanted movement by pressing the wrong pedal to the floor. Even a brake-throttle interlock is not going to prevent that problem, which has been around as long as there have been automobiles with throttle pedals.
Even if the throttle genuintely sticks, however, a competent driver should be able to use the brakes to stop the vehicle and stall the engine. A brake system on a light vehicle can generally absorb 10 times the power that the engine can put out, albeit for only a short time before overheating. A hard brake application will always stop the vehicle. The trick is to brake hard and not give the brakes time to overheat.
On a modern vehicle, turning off the ignition switch generally closes the fuel solenoid, which is also certain to stop the engine. On older vehicles, an engine may keep running at high speed even with the ignition off, but once the brakes have brought the RPMs down, the engine will stop if the ignition is off.
The real problem with "stuck throttles" is incompetent drivers. The smarter we make the cars, the dumber the drivers seem to get. It reminds me of the old adage that as soon as you invent a fool-proof device, nature will come up with a smarter fool.
After over 45 years of engineering, how do I go about checking someone else's system with 20,000 lines of code?
Let me explain my technique on a simple system - one digital input from a sensor and one digital output. Using a SPREADSHEET I would generate the usual family of waveforms - sine, square, triangular, noise etc. of the broadest frequency range making sure that a family of values would go well into clipping and overload. You want to generate every value that can be coded on all the available bits.
Then I would output my sets of waveform values to a file and use a simple program to convert them into the digital input format of the system under test. The digital output of the system I then convert with another small program into a format the spreadsheet could accept and then plot.
On my spreadsheet I would have graphs of the system input waveforms and graphs of the system output waveforms. This software test method is analogous to testing an audio amplifier for performance under all frequencies waveforms and levels, including of course overload.
Multiple inputs and outputs are handled similarly. Analog input simulation is handled by D/A converters and analog outputs by A/D converters.
To be honest, there hasn't been a single system that I've tested in this fashion that hasn't shown some expectantly erratic behavior. In many cases it has lead to much simpler and elegant coding, because you actually see what your program is doing. The big secret to this method is that you deliberately test every single value including overloads. Don't forget to test common mode and normal mode input values and noise.
I get a real kick out of seeing bazaar software behavior. And of course, a great sense of satisfaction of having contributed to a truly robust system once the problems are licked.
I hope they include a mechanic's override. They like to hold the brake and rev to check for bad motor mounts, a weak brake, sputtering fuel problems, erratic spark, muffler noise, etc.
And keep it off our airplanes - we still plan to hold the brakes, rev and check the mags or minimize roll in a short field by checking if we have full power without moving and then let 'er go like a slingshot.
I have had this problem on my 2010 Subaru on occasion. It is not an electronic problem but is an unintended consequence of crash safety which dictates a constrained foot area. Because crash safety dictates a wider bell housing bump in the floor pan, the accelerator must be positioned leftwards from it's historical location (read 1960's American cars). In fact the accelarator and also the brake pedal are so far left on my car (and Toyota's that I have tried) that it is actually painful to hold the brake pedal when stopped. On occasion I haven't moved my foot far enough left to completely remove it from covering the accelerator when stopping. To exacerbate this problem, the Subaru, like many other cars with ABS and power brakes has a very mushy brake pedal. The brake has almost as much travel as the accelerator. So unlike cars with a rock hard brake pedal, when braking if the right foot is covering both pedals, both pedals will travel sufficiently to increase torque from the engine while applying brakes.
I do not agree with the NHSTA that some electronic fix is necessary. The NHSTA should require that brake pedals be "hard" when operational with or without power assist or ABS. Then the two pedals, brake and accelerator will have different tactile feedbacks.
In addtion the NHSTA should require that the placement of the pedals not cause undue stress on the foot and leg when using the brake. In other words the accelrator and brake pedals should be moved slighty to the right.
Having the engine not accelerate on a stick shift while braking would make downshifting nearly impossible on a manual transmission vehicle where the right foot is used to operate the brake and throttle simultaneously.
TIN WHISKERS!!! As an engineer in the electronic components industry, our products are specifically EXCLUDED from the ROHS mandate BECAUSE of the TIN WHISKER "problem". Our products are installed in designs that are as close as your local telephone pole, and as far away as the orbiting satellites, etc. The industry has recognized the potential for failure inherent in the use of these parts, where the TIN WHISKER migration is a definite possibliity. By the way, this phenomenon is not only limited to non-PB solder, but there is also a well-documented history of silver migration, which engineers & designers MUST be aware of when manufacturing electronic products.
What gave me a clue that something else was going on was none of the cleaning swabs were coming out with observable debris. The wear surfaces did not show pitting or other visible defects. But we knew opening and cleaning seems to clear the symptom.
Hind-sight, I suspect tin whiskers which are all but invisible unless using a microscope were shedding and falling into the various wiper areas. Whatever it was, it was not visible to the naked eye.
The NASA GSFC paper pointed out that VOMs would detect the resistance anomalies but were not enough to 'burn' the whiskers. I could see as the encoder was advanced, the resistance would drift. So I tried the GSFC approach, apply enough voltage to 'burn out' the whiskers.
I simply used a 9V battery in all combinations of the six pins while cycling the encoder. I didn't bother with trying to monitor the current to detect the 'whisker burnout.' Regardless, retesting the encoder shows the resistances were now linear with displacement.
There may be some aspect of carbon traces that I'm unaware of but the absence of debris on the cleaning swabs was pretty telling.
The Smart Emergency Response System capitalizes on the latest advancements in cyber-physical systems to connect autonomous aircraft and ground vehicles, rescue dogs, robots, and a high-performance computing mission control center into a realistic vision.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.