4 ms·

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 e

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. 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.

HeyLaughingBoy 17y ago
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.
- djcapelis 17y ago
  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.
dkarl 17y ago
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.
- ramchip 17y ago
  And in this case, don't forget to do a #define INVERSE_MOTOR_POLARITY 1 or similar, so that the hack is clear and doesn't bite you when porting to another platform. It's not a bug, it's a customizable feature :)
  - litewulf 17y ago
    You're in trouble though when the front motors are wired one way and the rear ones another, or one particular motor is miswired. Imagine #define FRONT_MID_SECTION_MINI_MOTOR_POLARITY (...)
    - djcapelis 17y ago
      Typically more like: #DEFINE MOTOR_0_WIRED_WRONG_BY_#$@#$_ELECTRICAL_TEAM #DEFINE MOTOR_1_WIRED_WRONG_BY_#$@#$_ELECTRICAL_TEAM ... That said, the notion of portable embedded code when we're talking about the types of systems where these types of hacks thrive is pretty funny. These are not the type of routines people port or reuse and most of these hacks are very specific behavioral stuff to match specific pieces of hardware. 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.
      - ramchip 17y ago
        I think it's getting more common in the hobby community though. Just look at all the code and modules ready to use on AVRs, Stamps, etc. 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...
vijayshankar 17y ago
Once our hardware team mounted the camera in a cell phone device upside down. Later we had to write code to rotate the image 180 degree to compensate for it.
kaib 17y ago
I just recently wrote some code to do pcb milling with pretty close tolerances. The actual milling table wasn't straight however, so when the substrate was clamped down it would have Z variations 3x larger than the desired cutting depth. A 5 minute touch probe run and a simple 2D compensation table removed the need for a time consuming tramming operations and expensive clamping hardware. 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.
- HeyLaughingBoy 17y ago
  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.
blackguardx 17y ago
Don't worry, it works the other way as well. At my last job, I had to fix software defects in hardware.
- djcapelis 17y ago
  I think I'd like to file a hug report...

HeyLaughingBoy 17y ago

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.

djcapelis 17y ago
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.

dkarl 17y ago

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.

ramchip 17y ago
And in this case, don't forget to do a #define INVERSE_MOTOR_POLARITY 1 or similar, so that the hack is clear and doesn't bite you when porting to another platform. It's not a bug, it's a customizable feature :)
- litewulf 17y ago
  You're in trouble though when the front motors are wired one way and the rear ones another, or one particular motor is miswired. Imagine #define FRONT_MID_SECTION_MINI_MOTOR_POLARITY (...)
  - djcapelis 17y ago
    Typically more like: #DEFINE MOTOR_0_WIRED_WRONG_BY_#$@#$_ELECTRICAL_TEAM #DEFINE MOTOR_1_WIRED_WRONG_BY_#$@#$_ELECTRICAL_TEAM ... That said, the notion of portable embedded code when we're talking about the types of systems where these types of hacks thrive is pretty funny. These are not the type of routines people port or reuse and most of these hacks are very specific behavioral stuff to match specific pieces of hardware. 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.
    - ramchip 17y ago
      I think it's getting more common in the hobby community though. Just look at all the code and modules ready to use on AVRs, Stamps, etc. 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...

vijayshankar 17y ago

Once our hardware team mounted the camera in a cell phone device upside down. Later we had to write code to rotate the image 180 degree to compensate for it.

kaib 17y ago

I just recently wrote some code to do pcb milling with pretty close tolerances. The actual milling table wasn't straight however, so when the substrate was clamped down it would have Z variations 3x larger than the desired cutting depth. A 5 minute touch probe run and a simple 2D compensation table removed the need for a time consuming tramming operations and expensive clamping hardware. 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.

HeyLaughingBoy 17y ago
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.

blackguardx 17y ago

Don't worry, it works the other way as well. At my last job, I had to fix software defects in hardware.

djcapelis 17y ago
I think I'd like to file a hug report...