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.
No sane engineer would waste his time and money trying to collect the $1million prize for finding the problem with Toyota throttle controls. Firstly, the lawyers would have made it impossible to collect with the fine print. Secondly, how would you find the intermittent vehicle, let alone the intermittent fault without total access to the technical documentation? It would take one a long time to get familiar with the technical hardware and software details. I guarantee you that Toyota would not be particularly friendly to you. Let's face it, your life would be destroyed if you are shown to be a whistle-blower. It's human nature.
In the 70's I owned a Ford farm tractor which had the standard issue Ford lap-belt seen in all Ford vehicles. What disturbed me was that whenever I went over the very bumpy plowed sections of the field, the lapbelt would release by itself. Closer examination of the construction showed the hinged cover folded back so its ends were flush with the back face of the belt buckle. What was happening was that the fat in my stomach (6'4" 175lbs at the time) when I was pushed into the buckle would push the cover out and release the belt. I could demonstrate this release mechaism by simply leaning into the belt buckle. I wonder how many people died wearing this belt, and were recorded as seat belt not buckled. Oh the humanity! When I contacted Ford, they asked me to mail in the belt. The new belt I then bought had the back wrapped around the side avoiding the problem. So Ford engineers obviously knew what was happening and had quietly fixed the problem.
Truchard will be presented the award at the 2014 Golden Mousetrap Awards ceremony during the co-located events Pacific Design & Manufacturing, MD&M West, WestPack, PLASTEC West, Electronics West, ATX West, and AeroCon.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.