SunRover Part 4 – Adding a Pi Camera and Diagnostics System

On the Arduino

The Arduino uses an I2C scanning routine to see whether a specific device is present on the I2C bus. Note that this doesn't work for all I2C devices, and it can screw up some of then. A good case in point is the AM2315 outdoor temperature sensor at address 0x5C. To keep the sensor from overheating, the manufacturer of the device puts the sensor into sleep mode, except when it is going to be used. That makes sense; however, it means you have to go through a funny sequence [15] to make sure the device is awake and responding. It doesn't respond to an Arduino or a Raspberry Pi I2C scan (i2cdetect).

How do I handle this? In the SunRover initialization sequence, I try to read data from the device, and if I don't get any, I mark it as not present. Then, I use this information during the diagnostic I2C scan to insert the 5c address into the return data. Obviously, this needs to be refreshed every time I do a diagnostic scan.

The code in Listing 4 sets the I2C mux board [16] to read bus 3. Note that using this board has four benefits:

01 I2CMux1.write_control_register(TCA9545_CONFIG_BUS3);
02   if (! am2315_1.readData(dataAM2315))
03   {
04     Serial.println("Sensor am2315_1 not found, check wiring & pullups!");
05   }
06   else
07   {
08     am2315_1_Present = true;
09   }

• The use of four I2C buses allows duplication of I2C addresses for boards that can't be changed.
• A fault on one I2C bus still allows the other three to be used.
• It allows longer runs of I2C leads because the load of each bus is isolated.
• The board allows a mix of 5V and 3.3V buses. I use two of each in SunRover.

SwitchDoc Labs has redesigned the I2C mux card with Grove connectors (see this issue's SwitchDoc Labs column to find out all about Grove connectors) and has added status LEDs for each of the four channels. I'll be swapping these older boards out with the new boards shortly. Also, as SunRover reads more devices on I2C buses, it will have more technicolor lights.

An example of the Arduino I2C scanning code is shown in Listing 5 for bus 3 on I2C mux 1 (which is the I2C mux connected to the Arduino). The data sent from the Arduino across the serial link to the Raspberry Pi spotted the four buses and the addresses:

DIAG Response = 0,1e,21,3c,40,48,73,5c|\
                2,20,21,40,48,73|\
                3,21,40,48,49,50,57,68,73,77,7c,5c

01 // Bus 3
02   I2CMux1.write_control_register(TCA9545_CONFIG_BUS3);
03
04   I2CMux1.read_control_register(&config);
05   Serial.print("Bus 3 Control Register:");
06   Serial.println(config & 0x0F, HEX);
07
08   returnI2CDevices(myBuffer, myBuffer);
09   strcat(returnString, "3");
10   strcat(returnString, myBuffer);
11   if (am2315_1_Present)
12   {
13         strcat(returnString, ",5c");
14   }
15   //strcat(returnString, "|");

On the Raspberry Pi

During initialization of SunRover on the Raspberry Pi, the Pi sends a command to the Arduino power manager (DIAG) and waits for the reply. When the reply is received, the Raspberry Pi parses it using one of two methods. If an easily readable text message is desired, it calls the text parser, which produces output to the screen, as in the above diagnostic report. However, if HTML is desired, it produces an HTML screen that is loaded into a file for RaspPiConnect to read and display. Collecting the I2C data in this fashion allows me to build a database of the results to look for patterns of failures (e.g., temperature or humidity problems) and identify the time of failure.

I use RasPiConnect to build the control panels (bidirectional control, not just displays) for SunRover. I used a method for communicating between the SunRover control process and the RasPiConnect documented in the MouseAir project [17]. These are still works in progress.

The main control panel in Figure 9 shows a snapshot of all three power systems and environmental conditions surrounding SunRover. You can see the outside temperature (°C) and the solar panel voltages for each system. Note that these voltages are measured at the charger, and the solar panel multiplexor can have different numbers of panels attached to each power system.

Figure 9: Main control panel.

All three battery systems are fully charged. The graph shows the currents going into the motors. You can easily see when the motor was running by the high current demands of the motor (e.g., the middle of the chart). Note the button that triggers the solar tracking mode, as described in the previous article [3].

The panel in Figure 10 shows the power system for the Raspberry Pi. I was running a test on how far to run down the battery before shutting down and then powering off the Raspberry Pi [18].

Figure 10: Raspberry Pi power system.

Note that in most solar power systems, you need to monitor the battery voltage and not the 5V power supply, because with most modern voltage booster systems, the circuitry will work very hard to keep the 5V going and then just give up, crashing to a much lower voltage when it runs out of power. (Your voltage will vary with your system design!) With this behavior, your computer would have little or no warning about when the voltage is about to drop.

By monitoring the battery voltage, you can tell when the battery is getting low enough and then shut down your computer safely. For LiPo batteries, this will be when your voltage gets down to about 3.5V or so. I monitor the LiPo battery voltage with the SunAirPlus power controller [19], which has an INA3221 three-channel current monitor.

I chose 3.55V as the threshold to shut the Raspberry Pi down; after shutdown, I cut the power, because a shutdown Raspberry Pi can still draw about 100mA, which is a bunch on a solar-powered system.

You really need to issue halt before turning off the power on a Raspberry Pi. If you don't, you can corrupt your SD card. If you do corrupt your card, I just finished a tutorial on how to fix it [20].