Motor Mount & Wheel Kit with Position Controller issues
I recently purchased the Motor Mount & Wheel Kit with Position Controller kit to creat my robot and have had some strange behavior with the programming. I ran my first roll test with a BOE-Bot board and the BS2 test code from the web site. It worked fine until I decided to try reversing the opposite position controller in the software. Then the robot ran away at a faster rate of speed and when it got to about the 400-500th position the wheels then switched to a high speed oscillation until I powered off the HB-25's. I wanted my forward to be in the opposite direction and thus the reversal of the position controller [noparse][[/noparse]or so I thought]
So the next thing that I tried was reversing the wires on HB-25's since I saw that in one other post here in the forums that it did not really matter. Still the issue occurs when setting one in reverse. Here is the strange thing: when you reverse the wiring on the HB-25's you have to reverse in the software the other position controller to make it work flawlessly. Again forward equals wheels first and caster last which is what I don't want now for testing purposes.
Why is it so finicky about the correct wiring and the exact controller that needs to be reversed? Currently it is wired like it says in the documentation and the position controller in the test code is the one that I have reversed. I have to issue a negative number to get it to run caster first.
More details as to my setup are found here:
letsmakerobots.com/node/7025
Post Edited (TheGrue) : 5/19/2009 8:47:49 PM GMT
So the next thing that I tried was reversing the wires on HB-25's since I saw that in one other post here in the forums that it did not really matter. Still the issue occurs when setting one in reverse. Here is the strange thing: when you reverse the wiring on the HB-25's you have to reverse in the software the other position controller to make it work flawlessly. Again forward equals wheels first and caster last which is what I don't want now for testing purposes.
Why is it so finicky about the correct wiring and the exact controller that needs to be reversed? Currently it is wired like it says in the documentation and the position controller in the test code is the one that I have reversed. I have to issue a negative number to get it to run caster first.
More details as to my setup are found here:
letsmakerobots.com/node/7025
Post Edited (TheGrue) : 5/19/2009 8:47:49 PM GMT
Comments
The reason that correct wiring is so important for the motors is that the motor must go the correct direction when the Position Controller tells the HB-25's to go "forward" or "backward". The Position Controller sends signals to the HB-25 in order to drive the motor to a certain location. If the motor is reversed, then the more the Position Controller tells the HB-25 to drive TO the location, the more the motor actually drives AWAY from the location.
The reason the "Sensor Orientation" of each Position Controller is important is because that is what determines how motion is interpreted from the optical switches. This is from the data sheet:
"The default definition for positive direction of travel is counter-clockwise rotation when
observing the wheel from the outside (screw side of the Position Controller board). After
receiving the SREV command, a Position Controller will interpret positive direction of travel
as clockwise rotation from the same viewpoint."
So if the motors are connected correctly, but the Position Controller isn't "oriented" correctly, then the Position Controller interprets the direction of motion as opposite what it should be, and then consequentially tells the HB-25's to drive in the wrong direction.
Incorrect wiring OR incorrect sensor orientation will both cause an undesirable state of operation. However, this is one situation where two wrongs CAN make a right. Let me elaborate. As you pointed out, normally the default setup is that "forward" is in the direction of the motors, and "backward" is in the direction of the caster wheel. This is what the demo code and default setup in the data sheet describe. Literally, the only difference between forward and backward is just a negative sign. However, if you really don't want to deal with a negative sign... then (step 1) switch the polarity of BOTH motors to be opposite what is described in the data sheet, (step 2) send the SREV (sensor orientation reversed) command to the OTHER Position Controller and don't send it to the default one. Essentially, it is a double negative for each wheel: the motor wire polarity is backward, but the sensor orientation is backward too so both incorrect directions cancel out the error. However, the result is that "forward" is now forever defined as the direction of the caster wheel, and "backward" is in the direction of the motors. To change it back again, you must swap both motors' wires, and again initialize the opposite device to be reversed.
Hopefully this helps, and gets you "up and rolling" so to speak.
-Kevin
The double negative makes sense to me now but I did not see that in my troubleshooting. I think my confusion came from not knowing which position controller on which wheel was suppose to be 0 and 1 respectively. I must have missed that in the docs. Anyway, with your help I got it to run caster first with positive numbers.
Thanks
I'd say keep them on. Otherwise, if you turn them off whenever you stop, you don't give them a chance to cool down with the fan.
Here is another consideration. The vast majority of idle current draw from the HB-25s is from running the cooling fan. The cooling fan is designed to help remove the significant heat generated by driving up to 25 Amps. Keep in mind 25 Amps is a HUGE amount of current. In contrast the ~2 Amps for the motor is probably not going to make the HB-25 even break a sweat. If you want to eliminate just about all of the idle current draw, you can probably get away with disconnecting the cooling fan (desoldering & removing; or simply snip one of the fan's leads) but leave the aluminum heat sink installed. The heat sink is pretty jumbo and still works decently well without the forced air flow from the cooling fan. Furthermore, the H-bridge chip is pretty efficient and probably won't generate that much heat with only ~2 Amps load. I would suggest testing this method out by running the motors for a little while. Then keep feeling the heat sinks every so often to make sure they are not getting too warm. If they don't get too warm after about 10 or 15 minutes of use, I would think you are good to go without the cooling fans.
One thing I should point out, is that removing the cooling fan will void the warranty on the HB-25s. Therefore, do so at your own risk. This is merely a suggestion, and not a guarantee that this configuration will work. That being said... if it were my own personal project, that's what I would do.
Good luck, and have fun!
-Kevin
This helps a lot. TOBI is designed to carry tools and computer equipment from/to a vehicle and a job-site with a lot of predicted idle time during the day. thanks again for the info.
Frank
letsmakerobots.com/node/7025/
As an option you can either reverse the Position Controller in the code or change the ID jumpers on the controllers to reverse the hardware which is what I did to keep the same code as the demo versions. But I tried both and both methods work fine and resolve the issue.
I am now altering the robot so that I can switch from the BS2 to the Propeller and I will update my page with those details for any who may be interested. I monitor the LetsMakeRobots page daily for postings.
Is there an Object on the Object Exchange for the Position Controllers? I must be blind but all I can find is ones for the HB-25's
As you have probably seen on my page letsmakerobots.com/node/7025 I am running my robot with the caster first. With that end as the front, both of my HB-25's are wired with M1 to Blue and M2 to Yellow. The position controllers are set with ID 1 on the left and ID 2 on the right. In the code ID 2 [noparse][[/noparse]Right] is reversed.
As to the code, take a look at mine in Pbasic letsmakerobots.com/files/Tobi_TestTiltToMovement2.4.bs2_.txt
let me know what you think
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Searider
Anyway, I just uploaded a demo object to the Object Exchange that does what the BS2 demo does "MPC_Roll_Demo.spin"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Searider
'' File - Delay
VAR
long divider
PUB config(secondDivider)
divider := secondDivider
PUB pause(count)
waitcnt(clkfreq/divider*count + cnt)
I have never posted code before so I am not sure if this is correct
</code>
''Delay
CON
WMin = 381
PUB PauseMSec(Duration)
{{Pause execution in milliseconds.
PARAMETERS: Duration = number of milliseconds to delay.
}}
waitcnt(((clkfreq / 1_000 * Duration - 3932) #> WMin) + cnt)
PUB PauseSec(Duration)
{{Pause execution in seconds.
PARAMETERS: Duration = number of seconds to delay.
}}
waitcnt(((clkfreq * Duration - 3016) #> WMin) + cnt)
<code/>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Searider
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Searider