BlueAure
@BlueAure@infosec.pub
- Comment on A4988 driver module sleep pin 4 months ago:
Usually, not adhering to timing recommendations isn’t going to damage a circuit. However, it introduces potentially undefined or unpredictable behavior. For example, if you are driving a pump with specific timing requirements to control precisely the amount of fluid passed and you skew the timing a bit. Most of the time it would probably be fine, but there would be the potential that it might pump too much or too little. For a low precision application like a sump that’s ok, but for a high precision application like an medication pump it has the potential to kill someone.
At the end of the day, it depends on your tolerance for risk. Manufacturers generally certify their products for the timing on their datasheets. If you operate out of those specs, you are taking the responsibility of what happens.
Don’t want to scare anyone off, but it all depends on what you’re doing with it. In personal projects, yeah I’ll do all kinds of squirrely out of spec shit, but I’d never do that at work cause of potential liability. It’s up to you to determine if losing a couple steps on your watering pump will kill anybody or not! :D
- Comment on Considering positioning strategies for autonomous mechanum-wheeled robots 1 year ago:
Assuming that there is at least some amount of slippage between the wheel and ground, it seems to me that you’ll need to regularly check the ToF sensors anyway. I’ve found that encoders are fantastic for a lot of things, but not so much for measuring distance because of the problems you’ve described. Perhaps a recurring local check on a reduced set of points to verify location then forward the full cloud less often for further remote processing? It really sounds like you have a tradeoff depending on whether you value accuracy of location or accuracy of wheel rpm (analogous to speed). Using both would give you a nice way to calculate the ideal motor rpm to minimize slippage in a surface agnostic way.