The most frustrating part of developing the wall following algorithm from my last post was the constant moving back and forth between my office, to tweak and load firmware, and test area (kitchen hallway). To solve this problem, and to overall streamline development, I decided to add a Raspberry Pi to the robot. Specifically, I'm using a Raspberry Pi 2 that I had lying around, but expect to switch to a Pi Zero once I get code the code and design in a more final state. By installing the Arduino IDE and enabling SSH, I'm now able to access and edit code wirelessly.

Having a full-blown Linux computer on the robot also adds plenty of opportunity for new features. Currently I'm planning on adding camera support via the official camera module and a web server to serve a web page for manual control, settings configuration, and data visualization.

While I expected hooking up the Raspberry Pi as easy as connecting to the Arduino over USB, this turned out to not be the case. Having a barebones SBC revealed a few problems with my wiring and code.

The first issue I noticed was the Arduino resetting when the motors were running, but this was easily attributable to the current limit on the Raspberry Pi USB ports. A USB 2.0 port, like those on the Pi, can only supply up to 500mA of current. Motors similar to the ones I'm using are specced at 250mA each, so having both motors accelerating suddenly to full speed caused a massive voltage drop which reset the Arduino. This was easily fixed by connecting the motor supply of the motor controller to the 5V output on the Raspberry Pi GPIO header. Additionally, setting the max_usb_current flag in /boot/config.txt allows up to 2A on the 5V line, minus what the Pi uses. 2A should be more than sufficient once the motors, Arduino, and other sensors are hooked up.

The next issue I encountered was much more nefarious. With the motors hooked up directly to the 5V on the Pi, changing from full-speed forward to full-speed backward caused everything to reset! I don't have an oscilloscope to confirm this, but my suspicion was that there was so much noise placed on the power supply by the motors that both boards were resetting. This is where one of the differences between the Raspberry Pi and a full computer is most evident. On a regular PC there's plenty of space to add robust power circuitry and filters to prevent noise on the 5V USB lines, but because space on the Pi is at a premium the minimal filtering on the 5V bus wasn't sufficient to remove the noise caused by the motors. When I originally wrote the motor controller library I didn't have motor noise in mind and instead just set the speed of the motor instantly. In the case of both motors switching from full-speed forward to full-speed backward, the sudden reversal causes a huge spike in the power supply, as explained in this app note. I was able to eventually fix this by rewriting the library to include some acceleration and deceleration. By limiting the acceleration on the motors, the noise was reduced enough that the boards no longer reset.

While setting up the Raspberry Pi took longer than I'd hoped due to power supply problems, I'm glad I got a chance to learn the limits on my design and will keep bypass capacitors in mind when I design a permanent board. I'm also excited for the possibilities having a Raspberry Pi on board provides and look forward to adding more advanced features to OpenADR!