Possible revision for 27906 position controller
RobotWorkshop
Posts: 2,307
I've been using the Parallax # 27971 wheel kit with the included # 27906 position controllers and a pair of HB-25's. Overall they work very well and I've been really happy with the kit. In fact I just ordered another set for a new robot.
However, there is one thing about the position controllers I am not really thrilled about which could easily be addressed. It is something that I missed in the docs and caught me by surprise. The issue is when you need use one of the motors in reversed orientation. When the motors are in this configuration you MUST have the controller send out an SREV command to the controller when the motor is setup for reversed orientation. If you don't and bump the reversed wheel then it will just take off and keep spinning until the controller gets a SREV command or the power is removed. Not what you want to happen on a large robot! It is a concern since there is a window of time when things are starting up where the wheel can start moving before you get a chance to send out the SREV command. Also, if something happens on the host (hangs during startup) or you download new code that needs work and the SREV never gets sent then you could be in for a nasty surprise.
Software settings are perfect for most of the configuration items but I really dislike that I have to send a software command for something that should be a hardwired setting. After reviewing the docs/source for the position controller this could easily be fixed by adding one Jumper (2-pin header) and pull up resistor on one of the unused pins. The extra jumper could mean set the default orientation of the position controller. Upon startup the position controller code can look at the jumper. If it is open then set it to 1 (normal). If it is shorted then set to -1 (reversed). Any commands from the host could still override this setting but at least whenever the system is powered up you won't have to worry that your robot may take off on you! With this change it should still be compatible with all the software already written to use them. If there is an opportunity to revise the board this is one change I would really like to see.
In the meantime there are a couple ways to work around this.....
First, Parallax has been kind enough to post the source for the position controllers and make it available. With that you could change the default orientation in the initialization part of the position controller code to orientation = -1; and then reflash the controller which you prefer to stay reversed upon power up. (Just be sure to mark it as such)
The second method (which is what I am using now) is to control power to the HB-25's. I have a large relay on the power lines to the HB-25's. I can turn on/off power to the relay under software control. By default the power to the relay is off. I keep the power off until the controller sends out the SREV command to the position controller with the reversed orientation. This way the motor can't move on it's own since it doesn't have power yet! I originally added the power management so I could turn off the power to the HB-25's to save power when it didn't need to move. It ended up helping fix this situation too!
So, If you have one of these wheel kits and are using the position controllers just be aware of how they work and if you are using one in the reverse orientation then you should really consider one of the workarounds to make sure the robot is safe.
Robert
However, there is one thing about the position controllers I am not really thrilled about which could easily be addressed. It is something that I missed in the docs and caught me by surprise. The issue is when you need use one of the motors in reversed orientation. When the motors are in this configuration you MUST have the controller send out an SREV command to the controller when the motor is setup for reversed orientation. If you don't and bump the reversed wheel then it will just take off and keep spinning until the controller gets a SREV command or the power is removed. Not what you want to happen on a large robot! It is a concern since there is a window of time when things are starting up where the wheel can start moving before you get a chance to send out the SREV command. Also, if something happens on the host (hangs during startup) or you download new code that needs work and the SREV never gets sent then you could be in for a nasty surprise.
Software settings are perfect for most of the configuration items but I really dislike that I have to send a software command for something that should be a hardwired setting. After reviewing the docs/source for the position controller this could easily be fixed by adding one Jumper (2-pin header) and pull up resistor on one of the unused pins. The extra jumper could mean set the default orientation of the position controller. Upon startup the position controller code can look at the jumper. If it is open then set it to 1 (normal). If it is shorted then set to -1 (reversed). Any commands from the host could still override this setting but at least whenever the system is powered up you won't have to worry that your robot may take off on you! With this change it should still be compatible with all the software already written to use them. If there is an opportunity to revise the board this is one change I would really like to see.
In the meantime there are a couple ways to work around this.....
First, Parallax has been kind enough to post the source for the position controllers and make it available. With that you could change the default orientation in the initialization part of the position controller code to orientation = -1; and then reflash the controller which you prefer to stay reversed upon power up. (Just be sure to mark it as such)
The second method (which is what I am using now) is to control power to the HB-25's. I have a large relay on the power lines to the HB-25's. I can turn on/off power to the relay under software control. By default the power to the relay is off. I keep the power off until the controller sends out the SREV command to the position controller with the reversed orientation. This way the motor can't move on it's own since it doesn't have power yet! I originally added the power management so I could turn off the power to the HB-25's to save power when it didn't need to move. It ended up helping fix this situation too!
So, If you have one of these wheel kits and are using the position controllers just be aware of how they work and if you are using one in the reverse orientation then you should really consider one of the workarounds to make sure the robot is safe.
Robert
Comments
Communication Timeout Mode
The HB-25 has a selectable Timeout mode. When this mode is enabled, the HB-25 will shut off the motor
after 4 seconds if it does not receive pulses from the microcontroller. Once the motor is shut off, if the
HB-25 receives a valid pulse again, it will restart the motor. Timeout mode should always be enabled in
applications where a failure of your microcontroller could cause a dangerous situation or safety risk, or
potentially cause damage to your application.
If it could be adjusted down to MicroSeconds instead of Just four seconds.
Just a thought, Am I even close??
The issue is in regards to the position controllers. They send out the R/C style servo pulses to the HB-25's. When they are connected you shouldn't get pulses from anything except the position controller.
I believe the issue is that since the position controller doesn't know a motor is reversed that it tries to move it back when it drifts position so it stays put. However, when it tries to move the motor it goes in the opposite direction making the difference worst. As a result it starts rolling and keeps on rolling. If it gets the command to reverse the orientation so it knows the right way to turn the motor then it isn't a problem.
The problem is that when power is applied to everything the motor with reversed orientation could just take off like that if bumped until the position controller is setup. If you use a work around posted above it should be ok.
Of all the settings that you can configure on the position controller the only ones that really need to have jumpers for the initial setting are the ID numbers of the controller and the orientation. With that you shouldn't have to worry about a run away robot.
I'm looking over the code for them and the schematics and it appears that a simple firmware change and small hack to the existing boards would do the job. I may order an extra pair of position controllers to modify and see if it fixes it. It should.
I've run into an issue just like this before with the old HandyBoard controllers. I ended up making a small mod to all my HandyBoards where I replaced a chip with a different version, cut one trace, and added a jumper. It fixed the run away robot issue with that.
I don't mind my robots having a mind of their own but I really don't want them moving around on their own unless their program is telling them to do so.
Robert