More about Motors
I received Revision 4 of the main boards last weekend. The part I was most nervous about was the motor IC footprints and soldering the tiny surface-mount pins. But that actually went pretty well, even though I forgot to use flux on the first attempt.
I did make one major mistake on the board, wherein the controlled-voltage line to the micro-controller is missing. It's something that I had noticed and thought that I fixed, but somehow didn't actually fix. The good news is that it's really easy to jumper that connection.
So pretty soon, I had enough components soldered onto the board to test the motors. The result from that was fairly disappointing: the controller would reset immediately when the motors were turned on. But it didn't ALWAYS reset and, when it actually continued working, the motors were turning strongly and motor IC was not getting warm. So, that was the silver lining, I guess.
I tried bodging in various capacitors but, still the result was nearly always the same: the micro-controller would halt the moment the motors were started. This was all pretty frustrating until I attempted setting the PWM value to the motors to 100 (it can be anywhere from 0 to 255 and I had been defaulting to the highest value) and it worked! After that, I adjusted the code to allow me to change the speed with the remote.
With this setup, I was usually able to increase the speed to nearly full power. Often, at somewhere around the highest power, the controller would reset.
I also played around with some code that automatically increased the power, as in the above video.
Sometimes it would get to full power but, more often, it would reset once it got near full power.
So, it turned out to be a really good thing that I had spent time on the software while waiting for the boards to arrive. Being able to send remote commands was a Godsend: being able to interact with the electronics allowed me to test the hardware far better than a program with no user input would have. I didn't have the interactive speed-control stuff already coded but, with the framework that I did have coded, adding it took literally less than five minutes.
I tried adding a couple more AAs in series but that caused everything to not work. I'm not sure why, since the regulator should be able to easily handle that much voltage.
Because I was only testing my two drive motors with no load, and not even factoring in the turret motor, I could reasonably conclude that there is no possible way that my 5.5 volt power pack was going to power all three motors and controller, without constant danger of the controller resetting, no matter what I set the PWM values to in software.
So I could add more battery, switch to more efficient motors, limit the current to the motors somehow, or separate the battery for micro-controller. The last option is the simplest and is what everyone tells you to do in the first place. I can't really explain my resistance to it, just some false notion of what I consider "keeping things simple", I guess. Well, and, practically speaking, there's not really a place to put it! It would fit in the turret but the tank needs to be mostly disassembled to access the turret.
I have major life events happening and, within the month, I won't be able to invest anything into this project, for some unknown period of time. I had hoped to get to a good stopping point by then: not necessarily "finished", but with the major problems solved or, at least, with the knowledge of how they would be solved. This separate battery thing, it really isn't a big deal but it does require me to work some stuff and I need to experiment in order to determine a few things. Like, for instance, I would rather tie the Hall sensors/sonar sensors to the main battery pack, so that I can preserve the 9V's output for the micro-controller. But I've seen how much electrical noise the motors generate (Briefly, I had my IR receiver connected to power just adjacent to the motors. When I turned on the motors, the IR receiver ceased to function very well. Moving it to regulated power solved the issue.) so I need to determine whether the main/motor power can be filtered enough to also run the sensors.
Speaking of sonar ... I was playing around with the sonar sensors before my boards arrived and ... man, they sure are finicky. Searching the forums, this can possibly be helped by adding a cap. But there's also the issue of the sensors interfering with each other. It's not that this issue had never occurred to me before. But I had always kicked the can down the road, just planning on figuring it out when I came to it. But's actually a big problem. Like, it's simply not possible to tell if a burst of sound originated from your own sensor or the other tank's. And it's not that the occasional false positive is terrible: the tank will just stop and, possibly, turn to avoid an imaginary obstacle. But if two tanks are facing each other, their pulses will constantly trigger the other's sensor. It will look like a wall ahead.
I thought of some goofy software solutions to this like:
- Wait some relatively long time between pulses, say, 2 or 3 seconds
- Only pay attention to echos within a really short time period. Since we only care about objects within a meter or two, this could be something like 5 - 10 ms. Disregard all other echos.
- If an echo is received, this counts as an object being detected but also the pulse delay is modified to some random value between 2 and 3 seconds. The idea is to keep one tank's pulses from being in sync with the other's. If we only paid attention to a 1000 ms period within a 1 second window it's possible we would only have 10% of results being triggered by the other tank.
Anyway, the above is sorta complicated and maybe would not work as well as my back-of-the-envelope calculations suggest. Also, even without the interference issue, there simply remains the possibility that a wall will simply fail to be detected. A false negative is much worse than a false positive: the tank will be running into a wall, spinning or stalling its motors, and quite possibly won't ever figure out that it is stuck, since the sonar sensors don't work at all at very short distances. I think many people use bump sensors as backup, even when their main sensors are sonar or IR.
I never really wanted bump sensors to be my obstacle avoidance sensors. Something about it seems ungainly: robots running around all willy-nilly, bumping against stuff like drunks at a party. It's just not sophisticated. There's a practical problem, too: with my tanks the barrel can be extending beyond the body of the tank, meaning that the first thing that will contact the wall will be the barrel.
So, I dunno. I get the sense that sonar is always gonna be finicky, while bump sensors are relatively simple and robust, but more limited. If I go the bump sensor route, I need something cheap, robust, something that will detect a collision anywhere along the front or rear of the tank, and, ideally, only using one input per end of the tank (Some setups use dual whiskers on the front of a robot, but I don't have many input pins to spare).
I found a tutorial for some nice-looking bump-sensors made from acrylic which seems to fit the bill:
https://makezine.com/projects/bump-sensor-for-the-tiny-wanderer/
Whether I go with sonar or bump sensors, I think the boards I have now will suffice to bodge together some version of what I want. I can tape a 9V battery to the turret and supply power to the microcontroller from there. And, if I can achieve most of the functionality that I planned, even if it doesn't work perfectly, that will give me a pretty good idea where to take the project whenever I can return to it.
I did make one major mistake on the board, wherein the controlled-voltage line to the micro-controller is missing. It's something that I had noticed and thought that I fixed, but somehow didn't actually fix. The good news is that it's really easy to jumper that connection.
So pretty soon, I had enough components soldered onto the board to test the motors. The result from that was fairly disappointing: the controller would reset immediately when the motors were turned on. But it didn't ALWAYS reset and, when it actually continued working, the motors were turning strongly and motor IC was not getting warm. So, that was the silver lining, I guess.
I tried bodging in various capacitors but, still the result was nearly always the same: the micro-controller would halt the moment the motors were started. This was all pretty frustrating until I attempted setting the PWM value to the motors to 100 (it can be anywhere from 0 to 255 and I had been defaulting to the highest value) and it worked! After that, I adjusted the code to allow me to change the speed with the remote.
I also played around with some code that automatically increased the power, as in the above video.
Sometimes it would get to full power but, more often, it would reset once it got near full power.
So, it turned out to be a really good thing that I had spent time on the software while waiting for the boards to arrive. Being able to send remote commands was a Godsend: being able to interact with the electronics allowed me to test the hardware far better than a program with no user input would have. I didn't have the interactive speed-control stuff already coded but, with the framework that I did have coded, adding it took literally less than five minutes.
I tried adding a couple more AAs in series but that caused everything to not work. I'm not sure why, since the regulator should be able to easily handle that much voltage.
Because I was only testing my two drive motors with no load, and not even factoring in the turret motor, I could reasonably conclude that there is no possible way that my 5.5 volt power pack was going to power all three motors and controller, without constant danger of the controller resetting, no matter what I set the PWM values to in software.
So I could add more battery, switch to more efficient motors, limit the current to the motors somehow, or separate the battery for micro-controller. The last option is the simplest and is what everyone tells you to do in the first place. I can't really explain my resistance to it, just some false notion of what I consider "keeping things simple", I guess. Well, and, practically speaking, there's not really a place to put it! It would fit in the turret but the tank needs to be mostly disassembled to access the turret.
I have major life events happening and, within the month, I won't be able to invest anything into this project, for some unknown period of time. I had hoped to get to a good stopping point by then: not necessarily "finished", but with the major problems solved or, at least, with the knowledge of how they would be solved. This separate battery thing, it really isn't a big deal but it does require me to work some stuff and I need to experiment in order to determine a few things. Like, for instance, I would rather tie the Hall sensors/sonar sensors to the main battery pack, so that I can preserve the 9V's output for the micro-controller. But I've seen how much electrical noise the motors generate (Briefly, I had my IR receiver connected to power just adjacent to the motors. When I turned on the motors, the IR receiver ceased to function very well. Moving it to regulated power solved the issue.) so I need to determine whether the main/motor power can be filtered enough to also run the sensors.
Speaking of sonar ... I was playing around with the sonar sensors before my boards arrived and ... man, they sure are finicky. Searching the forums, this can possibly be helped by adding a cap. But there's also the issue of the sensors interfering with each other. It's not that this issue had never occurred to me before. But I had always kicked the can down the road, just planning on figuring it out when I came to it. But's actually a big problem. Like, it's simply not possible to tell if a burst of sound originated from your own sensor or the other tank's. And it's not that the occasional false positive is terrible: the tank will just stop and, possibly, turn to avoid an imaginary obstacle. But if two tanks are facing each other, their pulses will constantly trigger the other's sensor. It will look like a wall ahead.
I thought of some goofy software solutions to this like:
- Wait some relatively long time between pulses, say, 2 or 3 seconds
- Only pay attention to echos within a really short time period. Since we only care about objects within a meter or two, this could be something like 5 - 10 ms. Disregard all other echos.
- If an echo is received, this counts as an object being detected but also the pulse delay is modified to some random value between 2 and 3 seconds. The idea is to keep one tank's pulses from being in sync with the other's. If we only paid attention to a 1000 ms period within a 1 second window it's possible we would only have 10% of results being triggered by the other tank.
Anyway, the above is sorta complicated and maybe would not work as well as my back-of-the-envelope calculations suggest. Also, even without the interference issue, there simply remains the possibility that a wall will simply fail to be detected. A false negative is much worse than a false positive: the tank will be running into a wall, spinning or stalling its motors, and quite possibly won't ever figure out that it is stuck, since the sonar sensors don't work at all at very short distances. I think many people use bump sensors as backup, even when their main sensors are sonar or IR.
I never really wanted bump sensors to be my obstacle avoidance sensors. Something about it seems ungainly: robots running around all willy-nilly, bumping against stuff like drunks at a party. It's just not sophisticated. There's a practical problem, too: with my tanks the barrel can be extending beyond the body of the tank, meaning that the first thing that will contact the wall will be the barrel.
So, I dunno. I get the sense that sonar is always gonna be finicky, while bump sensors are relatively simple and robust, but more limited. If I go the bump sensor route, I need something cheap, robust, something that will detect a collision anywhere along the front or rear of the tank, and, ideally, only using one input per end of the tank (Some setups use dual whiskers on the front of a robot, but I don't have many input pins to spare).
I found a tutorial for some nice-looking bump-sensors made from acrylic which seems to fit the bill:
https://makezine.com/projects/bump-sensor-for-the-tiny-wanderer/
Whether I go with sonar or bump sensors, I think the boards I have now will suffice to bodge together some version of what I want. I can tape a 9V battery to the turret and supply power to the microcontroller from there. And, if I can achieve most of the functionality that I planned, even if it doesn't work perfectly, that will give me a pretty good idea where to take the project whenever I can return to it.
Comments
Post a Comment