Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The software fixed the hardware

jwz.org

Post reply on HN
Print view View original

11–20 of 43 posts

Re: The software fixed the hardware

#11

Post by ramchip »

dkarl wrote: post #10
djcapelis wrote: post #3

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…

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 somet…

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 :)

Re: The software fixed the hardware

#12

Post by jrockway »

Maciek416 wrote: post #6

I 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 + char…

My roomba has this problem from time to time. It's because the front wheel accumulates goo and stops rotating. The sensor that detects the wheel rotation then thinks the wheel is not rotating, and the robot moves erratically to free itself from the wall that it thinks is in its way.

Clean out the goo, and the robot is fine again.

Re: The software fixed the hardware

#14

Post by djcapelis »

dkarl wrote: post #10
djcapelis wrote: post #3

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…

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 somet…

Well, the values actually sent out to the PWM were backwards. Thankfully I could just invert it at the last step in the code where it got sent and so while writing the actual code I could pretend everything was correct. It's hard to think of -127 going forward and 127 going backwards as anything but a dirty hack.

While the underlying electronics thankfully didn't care, the digitized values set up certain expectations.

Re: The software fixed the hardware

#15

Post by litewulf »

ramchip wrote: post #11
dkarl wrote: post #10

Earlier quoted context omitted.

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 somet…

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 :)

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

Re: The software fixed the hardware

#16

Post by djcapelis »

litewulf wrote: post #15
ramchip wrote: post #11

Earlier quoted context omitted.

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 :)

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

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.

Re: The software fixed the hardware

#17

Post by bockris »

dandelany wrote: post #13
jeffbarr wrote: post #9

Can they send one to Mars to fix the rover?

They can and have! I always thought this was very cool. However, the current Mars rover problem is not a hardware problem, per se, it's a stuck-in-the-mud problem.

An elderly robot that walks with a limp that's stuck in the mud problem.;-)

Re: The software fixed the hardware

#19

Post by pcc »

Also it should be noted that devices like FPGAs allow for directly altering certain hardware structures via software.

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

Re: The software fixed the hardware

#20

Post by vijayshankar »

djcapelis wrote: post #3

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…

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.
Post reply on HN