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.
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.
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.
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.
While the underlying electronics thankfully didn't care, the digitized values set up certain expectations.
It's not a bug, it's a customizable feature :)
Hopefully you're not putting in hacks in the parts of the system you might actually reuse that's supposed to be more independent!
Code re-use is a principle that's often struggled outside of embedded systems. Inside embedded systems code it's downright scarce.
It's only a shame that a lot of it is fairly unreliable C code. The situation for embedded C reminds me of PHP. You can find snippets for anything, but most of them won't be written by experienced library authors and can have an 'interesting' behaviour...
My management was recently trying to convince me to rewrite a FAT file system in high level code due to issues with power management, corruption and the disk we store our most precious data on.
This wasn't so much fixing as augmenting. Software has the unique benefit that it can replicated essentially free while the physical improvements need to be administered separately in each and every instance.
Re. the backwards wired motors. Storing a config table in EEPROM seems to be a simple and portable solution to this. Do it in the logical way until you hit the output pins.
Ding, ding, ding!!! We have a winner. This is exactly correct: write your code the way everything should be in a perfect world, BUT have a hardware abstraction layer to separate that from reality. The upper layer code should just know that when the end sensor is reached, the hydraulic ram should be reversed. The HAL knows what state the end sensor must be in when it's triggered, and what polarity to send to the valve controlling the hydraulic ram.
Even in small embedded systems, a properly tiered architecture can save a lot of trouble.
At my last job, I had to fix software defects in hardware.
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.
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:
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.
Clean out the goo, and the robot is fine again.
"oh, its already bagged up and installed on the rocket, we've got 2 years to fix it until its going to suffer 45 seconds of insane conditions, so just let it slide for now .."
In these cases it can actually be possible to fix a hardware bug (or add a hardware feature) via software, where the hardware itself actually gets fixed (ie its not just firmware working around an ongoing hardware constraint).
Here's the link: http://news.ycombinator.com/item?id=1032152
The serial port is also a non-standard (for serial ports) connector (it is a standard DIN connector). My guess is that the average Roomba owner doesn't have a PC with a serial port, and probably wouldn't want to acquire an uncommon connector and wire up a serial converter cable, and then run some program on their PC to dump the firmware image in to the Roomba. The osmo dongle makes the process near foolproof for soccer moms and grandmothers and so on.
There's really no need for a USB port on the Roomba, so it's silly to incur additional costs on every single unit to add it.
That said, one of the things I really like to see these days is new generations of extremely competent hardware designers who have absolutely no problems with the expenses of hardware iterations .. even though it means less work for me in the end, its good to see. I have lost count of the times I've had to write some god-awful driver code that just makes me want to puke my lungs out, just because the hardware guys were too lazy to breadboard something ..