<story><title>The software fixed the hardware</title><url>http://www.jwz.org/gruntle/roomba.html</url><text></text></story><parent_chain></parent_chain><comment><author>djcapelis</author><text>This 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.&lt;p&gt;It was simple enough to do, but it always feels a bit wrong.&lt;p&gt;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.&lt;p&gt;It seems surprising how many issues you can solve with code if you aren&apos;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.</text></comment>
<story><title>The software fixed the hardware</title><url>http://www.jwz.org/gruntle/roomba.html</url><text></text></story><parent_chain></parent_chain><comment><author>HeyLaughingBoy</author><text>Meh! If I had a dime for every time that I was told to fix a hardware problem in software, or provide a &quot;limp home&quot; mode if software detected a hardware fault, well... I&apos;d have a lot of dimes. It&apos;s pretty standard behavior for electromechanical embedded systems.&lt;p&gt;The really important take home here is that the manufacturer sent out a software fix &lt;i&gt;to a consumer product that is not online!&lt;/i&gt; That&apos;s a huge leap forward and is something the industry has been pondering for a long time.</text></comment>