Pololu Qik Motor 0 won't start after error cleared

So I have a Pololu Qik 2s9v1 dual motor controller, and I’m using it to control two motors via serial from my Raspberry Pi. When the RPi boots, it outputs a few garbage bits over the TX line to the Qik, which trips the CRC-enabled, fixed baud rate Qik into Error mode (red LED turns on). After the RPi finishes booting, I start my program, which first sends a “Read Error Byte” (0x82) command to clear the error. The error successfully clears, the red LED turns off, and I can read the returned error byte. I then send two commands to start both motors 0 and 1 (0x88 0x7F and 0x8C 0x7F). Only motor 1 starts, and motor 0 does nothing! Then, a few seconds later, I send the same exact motor commands using the same exact code, and both motors start. This is repeatable every time I start the system from a powered off state.

I know all of the commands are being sent properly. I’m using CRC for all of my commands, and getting no errors on the Qik when sending them. So it has something to do with the Qik not turning on Motor 0 right after an error has been set/cleared. It does not matter how much time has elapsed between when the error was cleared and when the motor command is sent, could be seconds, could be 20 minutes, and still the same behavior. I also tried reversing the order of the motor commands, so right after reading the error byte, I command motor 1 first: 0x8C 0x7F, and then 0x88 0x7F. Still, motor 1 turns and motor 0 does not.

This is wacky behavior and is driving me nuts. I have a temporary workaround, where I send a very short pulse to “clear” out this weird behavior. I send 0x88 0x01, 0x8C 0x01, 0x88 0x00, 0x8C 0x00. This sends a move command to both motors, and then immediately commands them to stop… so the motors don’t move but still receive a move command. Once I’ve done this, I can successfully control both motors as normal. I tried this method using only 0x88 0x00 and 0x8C 0x00, but it doesn’t work. The weird behavior can only be “cleared” if you use a non-zero speed.

I suspect it may have something to do with the configuration parameter for stopping motors on error? I do not want to turn off this feature though, as my system can physically break if the motors don’t correctly receive a stop command.

Anybody have any idea what the heck is going on? Any help would be greatly appreciated. Thanks!!

Hello.

Thank you for the detailed description of the problem and what you have tried. It sounds like you might have found a bug in the firmware. We are going to try to see if we can reproduce the problem here. I will post again when we have some results.

-Brandon

I tried imitating your setup using an Arduino Uno and the qik 2s9v1 (with the fixed baud rate and CRC jumpers in place) and was unable to reproduce the error. I used a program that sends some garbage over the serial line to trigger the error, clears the error by sending the “Read Error Byte” command, then sends the two motor commands that you specified (0x88, 0x7F and 0x8C, 0x7F). Both motors react to the commands. I also tried switching the order of the motor commands and was still unable to reproduce the error.

Could you post the code you are using? I would like to try to reproduce the problem with an actual Raspberry Pi.

-Brandon

My code is long and drawn out, it will take some work to cut out the parts that are relevant. Can you try just hooking up to a Raspberry Pi and testing with some basic code similar to what you did with the Arduino? I’m powering the logic voltage of the Qik with the 3.3v rail on the Raspberry Pi. I wonder if you can repeat the problem just by booting the Pi with the Qik powered and attached. I used the instructions from this site (http://www.hobbytronics.co.uk/raspberry-pi-serial-port) to configure the Raspberry Pi’s UART. Let me know if this sounds like a good plan.

We will continue looking into it, but in the meantime, you might try resetting the board when you start your program instead of clearing the error with the “Read Error Byte” command. The RST pin on the jrk is internally pulled up to VCC; you can reset the board by briefly pulling this pin low.

-Brandon