Raspberry Pi Robot with PiShield, Part 2

The previous post showed the basic functionality of the Raspberry Pi Robot. The Arduino-based motor driver takes in commands to drive the robot in different directions, can be controlled remotely in a serial terminal via SSH using the screen application.

This is what the system looks like:

The Raspberry Pi talks to the Arduino via USB serial. The movement commands are sent from the Pi to the Arduino, currently, 'w', 's', 'a', 'd' to toggle movement, and ' ' (space) to stop. there are also ASCII numbers 1-6 that correspond to PWM values to control the speed of the motors. While it would be possible to control the motor driver with the GPIO pins of the RPi directly, I had that other circuit all hooked up from a previous project, and all it required was a single USB cable to the Pi, so I went with that instead of rewiring everything.

This time, we want to start doing something a bit more fun. Here's a preview of the end result:

The premise of the example is quite simple: get too close to the robot, and it runs away from you!

We use Python this time to implement the sensing behaviour. The source code that implements the above is available here. I call this one the PyPiBot as it runs on Python... ;)

Basically, what it does is the following:

Initialization:

1. Open SPI device for getting sensor data from the PiShield 

2. Open serial port (for sending commands to the motor driver)

Main loop:

1. Get data from sensor port

2. If sensor value is greater than a certain threshold trigger a move forward routine:

   - send a 'w' to the robot, which puts it in forward mode

   - wait a second (sleep)

   - send a ' ' to make it stop

3. Check for ctrl+c and quit the program

What you notice about this particular script is that it is blocking, which means that while the robot is in the move forward mode and the script sleeps, you can't respond to anything else. We'll tackle that in another example in the future!

Raspberry Pi Robot with PiShield, Part 1

Using the base from Tippy, I've started building a Raspberry Pi powered, sensor enabled robot. Currently, you can SSH into it and control it via the serial port. The original Arduino-based motor driver from Tippy is still there, but in theory we could just send out PWM and control signals from the Pi directly.

Main components:

- Raspberry Pi Zero with inline 2-port USB adapter:

- - Port 1: wifi dongle

- - Port 2: Arduino USB serial

- PiShield Sensor Interface (current Kickstart project here)

- 5000 mAh OCHO mobile power bank (1A and 2.1A outputs).

- Arduino and Sparkfun motor driver. Its been a few years since I ordered that part. This one has two channels with PWM input for each channel for speed control. There are now ones that fit directly on the Raspberry Pi as well which could be more convenient to use...

- Tamiya Track and wheel set. Really handy little platform for making a basic tracked robot. One of the cheapest options out there too.

My idea is to add sensors to the PiShield, and then have it react to local environment conditions in addition to receiving wireless commands. The software I'm running on the Pi is the latest minibian, which usually boots up and gets an IP from my router in about 10~15 seconds.

Could this have been done on an Arduino or even an ESP8266 based board? Sure - but its kinda neat to be able to run linux on-board in a relatively compact package. Stay tuned for more updates!

p.s. apologies to /r/cablemanagement. This part is clearly not my strong suit... ;)

5V power supply shootout

As I've got quite a few Raspberry Pi's in employed in various settings, one constant issue is finding the right power source for them. The Pi3, for example, is supposed to require up to 2.5A under heavy use (I presume a lot of wifi activity + fully loaded CPU/GPU, which is probably not likely to happen all the time). However, it's always good to know where the limits lie. I've been running a Model B on a wifi dongle + USB webcam as a streaming home surveillance system for a while now, on a "measly" 1A adapter without any issue (its a Nexus 4 charger, results below explain the quotes around the word "measly"...), which is probably living a bit dangerously perhaps... Anyway, here's some tests I did recently, along with lots of pictures to show for it!

First up, the test equipment. Here I'm testing a Nexus charger (1A), Samsung Tablet charger (2A), a 2.2A supply from Element14, and a cheap "2A" supply from a dealer on AliExpress. Near the top left are the key components for the test, which will be displayed in a larger image following this one:

Here are the interesting pieces of test equipment. On the left is a "USB charge doctor". They're available for a couple bucks on AliExpress. (e.g. link here.) There are a number of models out there at different prices, but their main feature is to be able to sit between a female USB outlet and a device connected by a male cable, and measures the voltage and current. Another cool feature of this particular one is it also has a resettable energy counter. This basically sums the amount of energy that has gone through, and is good at things like measuring how much capacity is left in your battery, or what the effective output capacity of a mobile power bank is. For example, on our aging Nexus 4, if I deplete the battery completely and charge it (system turned off), it measures about 1600mAh, which is quite a bit below its factory spec of 2100mAh. Our Nexus 5, much used but in newer condition with fewer cycles, reads about 2000mAh (out of 2300 new).

Plugged into the USB power meter, is a funny device with two large green resistors on it. This is a switchable dummy load that can be set to draw either 1A or 2A from the USB port it is connected to. Using basic Ohms law we can see that the resistors are most likely 5Ohms each, and the 1A mode just makes use of a single resistor (drawing 5V/5Ohms = 1A) while switching to the 2A mode, puts two in parallel (5V/2.5Ohms = 2A). There's also a handy two colour LED that lights up either green in 1A mode or red in 2A mode, assuming the power source doesn't crap out completely (see later tests).

The next funny device is a hacked microUSB female to female USB adapter. This is required in order to use the power meter with the chargers that have microUSB ports hardwired to them. Here are the chargers: Note that two of them are hardwired. I use a 1m Aukey microUSB cable so that they can be used with the same funky adapter (explained later). Aukey, along with UGreen, Anker, and a few other "respected" brands, provide quite high quality products from the AliExpress marketplace at a price that is a compromise between so-cheap-you're-surprised-they-even-work (and most often they don't) and arbitrarily-expensive-north-american-department-store levels.

Below shows the setup for the cellphone chargers. Since 

I could simply plug the USB power meter and dummy load directly into the charger (and is in fact what I'd normally do). However, I deliberately introduced the extra USB cable so that I could use my home-made adapter in between. This is because when I was making it, I realized that the wires of the USB extension cable I sacrificed, as well as the traces on the female microUSB adapter board was a bit on the thin side. If the resistance was significant, it may cause a noticeable voltage drop when using this adapter, and would have a negative impact on the observed performance of the charger. This way, any potential degradation would be consistent throughout all our tests. (The flip side of course means that I wouldn't be able to make a very convincing critique of the absolute performance, only how they measure up against each other....)

 So then, with a wired charger, this is what the setup looks like:

After that wall of text and pictures, lets finally get down to some results!!

Nexus 4 charger. 1A setting. 4.62V, 0.82A. Note the green light.

Nexus 4 charger, 2A setting. 3.94V, 1.37A. The power meter will probably crap out at some voltage threshold, but here we see its still kicking away, drawing way beyond its rated capacity...

Next we have the Samsung 2A charger. Here we see it at 4.6V, 0.83A for the 1A setting, and 4.53V, 1.65A for the 2A setting.

Onto the 2.2A rated charger from Element14: at 1A, it measures 4.83V at 0.9A

And at 2A, 4.5V and 1.65A

Finally, we have the cheapo 2A charger: even at 1A, the voltage drops down to 3.97V, and outputs a measly 0.7A

 And when trying to put a 2.5 Ohm load to draw 2Amps: .... uh oh.

Well, at least the red light gives off a feeble glow, showing that its at least trying. The voltage has dropped so low that the power meter no longer turns on. At some point I could easily verify this threshold on a variable power supply at some point...

Finally, just for fun, I got a 5000mAh Mediasonic Ocho power bank. It has a 1A and 2.1A port.

On the 1A port, I get 4.56V at 0.84A

Trying to draw 2 amps on the 1A port, we get a dropout. However, what you may barely make out in the picture below, is that the voltage is just on the threshold for the power meter to almost turn on. This suggests that its doing better than the cheap wallwart above!

On the 2A port, we have no trouble at least keeping things going. 4.27V @ 1.56A. Considering that these guys are supposed to at least register a "charging" status on power hungry tablets, its not surprising that it at least manages to chug along, even if the voltage dips quite a bit... for about $10cad from NCIX when on sale, these guys are an amazing deal.

So, there you have it! Here's all the info consolidated in one place:

Charger      Rated   1A             2A

Nexus 4      1A      4.62V 0.82A    3.94V 1.37A

Samsung      2A      4.60V 0.83A    4.53V 1.65A

Element14    2.2A    4.83V 0.90A    4.50V 1.65A

Cheap0       2A      3.97V 0.70A    N/A

Mediasonic   1A      4.56V 0.84A    N/A

Mediasonic   2.1A    4.64V 0.8A     4.27V 1.56A

Comments and final thoughts

The voltages across the board seems a bit on the low side. This is definitely related to the adapter I built. Due to the thin wiring of the cable and small traces, the adapter's resistance will create a.) a voltage drop and b.) reduce the amount of current (Ohms law here we go again...). As mentioned earlier, I wanted to get a sense of the relative performance of these chargers with respective to each other, and if I removed the adapter for the chargers that don't need it, it would skew the results quite a bit against the wired chargers.

I was especially interested in getting some sort of measurement of these wired chargers that I was especially interested in, as prior to the making of this adapter, I had no way at all of testing their performance in any way (other than to see if a Pi manages to boot and/or display the "low voltage rainbow square").  At the same time, I could unquestionably say that the cheap adapter is totally off in terms of rated performance, not even coming close to performing at its advertised values.

For a more definitive view on the absolute performance of these guys, I should probably look into building a microUSB adapter with beefier wiring to reduce the amount of losses through this part. It might also be good to actually compare the performance of the cheap USB power meter with a decent bench meter to see if there are any discrepancies there as well. 

As one last point - the cheap USB dummy load gets pretty HOT. I would not recommend it for any prolonged tests, and perhaps invest in a headsinked and actively cooled version at some point.

Kickstarter is Live!!!

I have a habit of back filling this blog, typically in a sneaky way such that when you visit, it looks like the content has been gradually updated over the years. However, currently due to PhD stuff, family/baby stuff, and various other things, I haven't managed to backfill adequately to get rid of the obvious gaps, so this post will look somewhat unexpected... but here goes: after starting this project about two years ago with Infusion Systems, the PiShield is finally live on Kickstarter!!

Shutting down the RPi gracefully

One of the things thats worth considering when using an embedded linux system, is the integrity of the file system when it comes to pulling the plug. In the past, I've had issues (especially with poor quality SD cards) with file corruption. The RPi should not be simply disconnected from power when you're done, and if you're running an application without console access (either direct or via ssh), its a good idea to implement the means to shut down the system gracefully.

There is a large number of documentation on how this can be done via a physical switch connected to the GPIO pins. For my implementation, I aimed for the following:

- as few components as possible

- as straight forward header connections as possible

To achieve this, I ended up using pin 05 (GPIO03), which is conveniently located next to a GND (pin 6):

img source: https://www.raspberrypi.org/forums/viewtopic.php?f=78&t=82397

This pin has internal pull-up resistors enabled by default, which means you can use an active-low switch without having to add a resistor. To hook this up simply requires a 1x2 header connection attached to a switch (or bare wires, if you're into that sort of thing) on the other side.

Then, I employed the interrupt method (because polling constantly sucks, right? :P) as described here. The interrupt needs to be modified to trigger on the falling edge instead of rising, due to the active-low logic we're dealing with.

The unintentional bonus of using these two pins is that once the Pi is in the halted state, triggering this pin again will boot it up again! (This is likely a built-in feature which I luckily stumbled upon...)

The one weird thing I discovered, was that the interrupts do not fire when the script is running in the background, which might not be suitable for some usage scenarios since it requires load the python script last and keeping it in the foreground. I'm still investigating this...