Pi Camera Robot Wheels, Outputs & Duration

[JTeagle]

I've got the chassis that goes with the Pi Camera Robot. I'm playing around with scripts that use the mini-driver script provided to control the wheels, so I'm basically calling the setOutputs() function to give the wheels speed changes.

This is working, not an issue with getting it to work as such, but despite me leaving the current speed in effect for 5 seconds (i.e., I'm not sending a new signal to change speeds within that 5 seconds), the wheels only appear to run for 2 seconds and then stop.

I tested this theory by having the script set the wheels to a value of 20 (fairly sedate), waiting 5 seconds, then setting them to 80 (belting along), waiting another 5 seconds, and then finally setting them back to 0.

What I'm actually getting is 2 seconds of slow rotate, back to still for the remaining 3 seconds, then 2 seconds of fast rotate, back to still for the remaining 3 seconds. I can confirm the timing is working as I do get the 5 seconds before it changes speed (and then prints the final message).

I can't see anything in the mini_driver.py file which might suggest a time limit... and indeed, if you keep your foot on the joystick on the web page it will go for longer than 2 seconds.

Note that I *am* running this test with the wheels running free, as my Pi is using the mains power so I don't want it unplugging itself by running away across the floor

Any ideas? Am I supposed to keep re-enforcing the outputs at regular intervals? This seems a little tedious.

[Alan]

Hi there,

Sorry for the delayed reply. I was out at the Linux User Pi Jam in Poole yesterday, and so didn't have time to look at the forum yesterday.

What you're seeing is the 'Dead man's switch' feature that I put into the Mini Driver sketch. Essentially, I didn't want the robot to drive off into a wall if it was driving forward, and communication was lost over wifi etc.

You can disable this if you want by commenting out the following lines from mini_driver_firmware/mini_driver_firmware.ino

Code: Select all

// Turn off the motors if we haven't received a command for a while
unsigned long curTime = millis();
   
if ( curTime - gLastCommandTime > MOTOR_COMMAND_TIMEOUT_MS )
{
    gLeftMotorDutyCycle = 0;
    gRightMotorDutyCycle = 0;
    gLeftMotorDirection = eMD_Forwards;
    gRightMotorDirection = eMD_Forwards;
}

If you change either VERSION_MAJOR or VERSION_MINOR at the top of the file, then the next time you connect to the mini driver with an instance of the MiniDriver class, it should see that the version number is wrong, and download the new version of the firmware to the mini driver board.

Having said that, personally I would leave the timeout in there and just send the desired motor speed repeatedly. I know it seems a bit tedious, but I feel that it's good as a safety feature, and I tend to run my robots with state machines, where commands are sent at regular intervals to the robot depending upon the current state of the robot.

Regards

Alan

[JTeagle]

Thanks for the response, Alan. It's good to know that it *is* by design, and not a bug. I didn't look in the .ino file as I didn't realise it contained readable code. I'm happy to leave the feature in there; now that I know it is a design feature, I will (have) code(d) accordingly. I did indeed confirm that sending commands at regular intervals kept it running and I have a mechanism to handle that automatically in my script now. Just caught me by surprise at the time

Thanks.