DHB-10 Firmware Command Protocol
ArtBaker
Posts: 3
in Accessories
Is the DHB-10 able to accept a new command while the previous command is still executing?
The specific scenario I'm curious about is an emergency stop that's triggered by sensors other than optical encoders:
1. The robot's microcontroller has given the DHB-10 a MOVE command to send it forward
2. While the robot is still moving, an edge sensor connected to robot's microcontroller determines that the platform will go over a cliff before it reaches its destination.
3. The microcontroller aborts the forward movement by sending (some command) to the DHB-10.
Is this scenario supported? The firmware documentation seems to be saying that a "GOSPD 0 0" command can be used as an emergency STOP, but I'd like to verify that assumption.
Thanks!
The specific scenario I'm curious about is an emergency stop that's triggered by sensors other than optical encoders:
1. The robot's microcontroller has given the DHB-10 a MOVE command to send it forward
2. While the robot is still moving, an edge sensor connected to robot's microcontroller determines that the platform will go over a cliff before it reaches its destination.
3. The microcontroller aborts the forward movement by sending (some command) to the DHB-10.
Is this scenario supported? The firmware documentation seems to be saying that a "GOSPD 0 0" command can be used as an emergency STOP, but I'd like to verify that assumption.
Thanks!
Comments
Yes, the "GOSPD 0 0" command will stop the motors while in the middle of a "MOVE" command.
I received my DHB-10 yesterday and just successfully tested these commands myself.
Other limitations in the command protocol: I don't see any way to determine the status or "health" of the DHB-10 controller.
For example, once I send a command to move, it looks like the only way to determine that the command has completed is by repeatedly issuing a SPD command and looking for zero as the reply. But this really only tells me that the optical sensors aren't generating any pulses. Maybe the sensors (or their IR sources) have failed.
Or perhaps the wheels really *have* stopped moving, but does this mean that the robot has reached its destination point, or is it simply blocked by some object in such a way that its wheels won't turn. And if that's the case, is the controller suddenly drawing a huge amount of current because the wheels are frozen? Has the DHB-10 had some other kind of internal failure?
The current command protocol seems very "optimistic" about such things; it seems to assume that "everything will just work." Unfortunately, in practice failures occur, and it's good for the robot's control software to be able to find out about them. Otherwise, the only failure notification will be a small cloud of smoke escaping from the robot...
If anyone from Parallax is following this discussion, I have a suggestion:: Perhaps in an updated version of the firmware, you could provide some commands that would allow a caller to query the status and health of the controller. Such extensions would greatly enhance the value of the DHB-10.
I know the original Eddie firmware had a section of code which disabled the motors if the encoders stopped prematurely. Unfortunately the original firmware's algorithm caused frequent encoder errors so I think this feature was disabled.
I updated the Eddie firmware to include an ARC command and some other commands. Here's a thread about my efforts.
I don't think I ever added any sort of fault detection algorithm back into the code. I'm not sure if the DHB-10 firmware includes this sort of protection. I don't think it does.
A better command to stop the robot than "G0SPD 0 0" is "G0 0 0". "G0SPD 0 0" will drive the motors if the encoders are connected incorrectly (I know this for a fact). "G0 0 0" sets the motor power to zero rather than the speed to zero. IMO, this is a safer stop strategy.
Maybe a command like "PWR" could be added to request the power level of the motor? I'm sure I could add this myself.