I have an unusual bug with the code I have written for my rover V2 robot.

I have a raspberry pi running some computer vision code written in opencv tracking an object doing the heavy processing.

Once the object is detected, a command is sent via serial (USB) to make the robot move left, right, forwards etc.. The pi sends: w, a or d for the direction it wants the rover to move, it then turns off it's ability to send any further commands via a flag and will turn this back on when the rover sends a response confirming it has completed the command.

The idea is, eventually the rover v2 will be able to do some audio processing itself so it can turn and face the direction of a sound impulse but always prioritize any incoming serial data, sending the more accurate movement commands.

So my idea has been to implement an interrupt routine that is called upon receiving a command using the less than perfect approach suggested here.

So now for the weird part.. the code works entirely... until the motors have power!

If the Rover V2 motor power is entirely disabled the interrupt routine will work flawlessly. The Raspberry Pi will send a command and receive every reply from the Rover.

However, if the Rover V2 Motors are powered on, the Rover will receive all commands and send replies accordingly. The issue is for some reason, the Raspberry Pi will occasionally not receive a reply rendering the robot stationary as no more commands can be sent, this happens after varying periods of time all the way from 2 successful command interrupts to 100.

The fact that this occurs only when power is applied to the motors on the Arduino, is leading me to believe it is not a fault in the Pi code.

Why is it, that as soon as the power is applied to the motors there is inconsistency in the transmission of serial replies?

Does anybody have any suggestions on how I could further diagnose the cause of this fault?

Or is there any obvious issues in this code I have not seen?

Thanks in advance!


Code can be viewed HERE

  • 1
    Without examining your code my immediate thought is EMI. As the motors spin then induce noise in the comms signals which corrupts them making the Pi not receive the right thing. What EMI filtering do you have on your motors? – Majenko Mar 5 '17 at 18:36
  • One thing to try would be doing a dry run - let it "move" the motors but disconnect them. Also consider if your power source is truly sufficient for the motor demands and sufficiently separated from the logic supply source. It's possible you will see messages related to USB interference is the dmesg output of the pi. You might ultimately want to consider using a different interface than USB, and implementing error correction. Also consider a mechanism (timeout, break, or even watchdog) to get out of unexpected but possible software states - ideally indicate the issue before recovering. – Chris Stratton Mar 5 '17 at 20:11
  • Fixed: Interrupt routine was calling itself nestedly, terrible practice, lesson learnt! Thanks for the suggestions guys! – ohkneel Mar 6 '17 at 12:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.