The software fixed the hardware
1–10 of 43 posts
Re: The software fixed the hardware
#2So, does it actually "fix" the hardware by say, oscillating the wheel in such a way as to clean or jiggle the sensor, or does it update the firmware to compensate for the wheel sensor's spotty readings?
Re: The software fixed the hardware
#3This type of thing happens all the time with embedded platforms. Software fixes for hardware defects are common. When we were building robots invariably the electronics team would always wire some motor backwards. Since the motors had similar power in both directions they would always ask me to just write the code to run motors they wired the wrong way backwards.
It was simple enough to do, but it always feels a bit wrong.
Other types of software workarounds are possible though too. I once modified the acceleration curve of the robot (clamped down the jerk) so that there would be reduced stress on the poorly made drive train and under many failure modes this changed the robot from essentially dead in the water to workable.
It seems surprising how many issues you can solve with code if you aren't used to it. But these hacks are actually everywhere in a lot of embedded systems and allow teams to continue to quick, cheap and dirty work when needed that can get patched up later.
Re: The software fixed the hardware
#4So, does it actually "fix" the hardware by say, oscillating the wheel in such a way as to clean or jiggle the sensor, or does it update the firmware to compensate for the wheel sensor's spotty readings?
The entry itself speculates that the new firmware simply compensates for the spotty sensor(s).
Re: The software fixed the hardware
#5This type of thing happens all the time with embedded platforms. Software fixes for hardware defects are common. When we were building robots invariably the electronics team would always wire some motor backwards. Since the motors had similar power in both directions they would always ask me to just write the code to run motors they wired the wrong way backwards. It was simple enough to do, but it always feels a bit…
You describe them as workarounds, but often this the intended design. If you only have manual control, then perhaps a driveshaft must be made larger and heavier for the case of the ham-fisted user. If the transmission is under software control, the software can be careful about accelerations to avoid overstressing the driveshaft.
The point is that when you consider the system as "mechanical, electrical and software" you get a lot more flexibility than if you think of it as "mechanical and electrical" but we do some stuff in software.
Re: The software fixed the hardware
#6I had a similar problem with my Roomba. Recently it began to bump into phantom walls where there were none, to the point where it would get stuck in the middle of the floor, turning around and around, stuck in a jail of invisible walls.
The Roomba detects this problem and emits a failure code of 9 beeps. I contacted iRobot about the problem, and their response was to ship me a fresh Roomba (without the battery + charging station) right away. Here are some pictures of the battery transplant:
http://dl.dropbox.com/u/1149620/roombasurgery/index.html
From the troubleshooting instructions that iRobot gives you upon encountering the 9-beep code, I suspect that there's probably just a faulty or possibly dirty (likely very inexpensive) sensor on the front bumper of the robot. I wonder if there's a similar fix to jwz's Roomba where I could patch for the bad sensor somehow (the roomba appears to have more than one way to detect it's stopped moving), and perhaps accept a slightly "dumber" but otherwise working Roomba.
Re: The software fixed the hardware
#7This type of thing happens all the time with embedded platforms. Software fixes for hardware defects are common. When we were building robots invariably the electronics team would always wire some motor backwards. Since the motors had similar power in both directions they would always ask me to just write the code to run motors they wired the wrong way backwards. It was simple enough to do, but it always feels a bit…
You describe them as workarounds, but often this the intended design. If you only have manual control, then perhaps a driveshaft must be made larger and heavier for the case of the ham-fisted user. If the transmission is under software control, the software can be careful about accelerations to avoid overstressing the driveshaft. The point is that when you consider the system as "mechanical, electrical and software"…
Certainly I agree the system is more complex and we could have designed it to work this way. But the stark reality was that these components were supposed to be wired a certain way in our design and the drive system was supposed to stand up to a lot more torque, as per the intended design.
So I think it is fair to call these particular fixes workarounds.
Your point that it is silly to look at these systems as anything other than integrated (often quite deeply) is well taken however. The fact that one can fix a mechanical defect using the software section of the system speaks volumes about just how integrated they are.
Re: The software fixed the hardware
#8Meh! If I had a dime for every time that I was told to fix a hardware problem in software, or provide a "limp home" mode if software detected a hardware fault, well... I'd have a lot of dimes. It's pretty standard behavior for electromechanical embedded systems.
The really important take home here is that the manufacturer sent out a software fix to a consumer product that is not online! That's a huge leap forward and is something the industry has been pondering for a long time.
Re: The software fixed the hardware
#9Can they send one to Mars to fix the rover?
Re: The software fixed the hardware
#10This type of thing happens all the time with embedded platforms. Software fixes for hardware defects are common. When we were building robots invariably the electronics team would always wire some motor backwards. Since the motors had similar power in both directions they would always ask me to just write the code to run motors they wired the wrong way backwards. It was simple enough to do, but it always feels a bit…
it always feels a bit wrong
It helps to think of it as "don't care" code rather than "error compensation" code. Which way should the engine be wired? It's cool; the software doesn't care. Just wire it up however. What order should I start these services? It's cool; they don't care. Just start them up however. As soon as your users stop caring about the stuff you can take care of, they'll have time to care about something else that's more important.