What is the Solar Powered SunRover Robot? – Part 2

What is SunRover?

SunRover is a tracked solar powered robot designed to move around and explore the area while sending back reports, tracking weather, managing a power budget tightly and providing a platform for testing new sensors and equipment as they become available.

This is part 2 of 2 of postings describing the major subsystems for the SunRover robot.

The Block Diagram

The major subsystems are shown to the right.   It takes a lot of thought to put together a good block diagram.  You make a lot of design decisions that might be difficult to change later in the design.   Here is a list of the major system decisions you can infer from the SunRover block diagram:

• Use a prebuilt Track and Motor controller system
• Solar Powered system
• Solar Panels will be shifted from one subsystem to another according to demand and task set
• Two major computers:  Raspberry Pi 2 for higher levels of control and an Arduino for power management and turning devices and sensors on and off
• Dual WiFi communication Paths
• SunRover control panels using RasPiConnect [ www.milocreek.com]

That is a lot of design decisions made on a very high level.  Next, a quick explanation of each of the subsystems of SunRover.

Subsystems (Part 2)

Part 1 described the following systems:

• Track Motor Controller / Power Subsystem
• Solar Power Mux / Power Subsystem
• Control Subsystem / Raspberry Pi 2
• I2C Control Subsystem

Weather Sensor Subsystem

The weather sensor subsystem in SunRover will detect the following values:

• Wind Speed
• Wind Direction
• Rain
• Inside Temperature
• Inside Humidity
• Outside Temperature (AM2315 Encased Temp/Humidity Sensor)
• Outside Humidity (AM2315 Encased Temp/Humidity Sensor)
• Dust count outside
• Luminosity
• Light Color (can be used to detect some kinds of pollution)
• Lightning Detection

We do this by using the WeatherPiArduino / WeatherRack sensors combined with an Embedded Adventures AS3935 lighting detector I2C sensor.

You can see the anemometer and the wind vane in the SunRover logo.  It might look a little clunky, but it should work great.

 

WatchDog Subsystem / Arduino Mega 2560

The WatchDog subsystem is designed to monitor the power systems (three systems – WatchDog, Motors and Raspberry Pi), make adjustments to the solar panels and regulate the charging of the devices (with the help of SunAirPlus solar controllers and chargers.  It will also be used to schedule next wake up times for the Raspberry Pi, gather certain kinds of data while the Pi is asleep (such as the weather data).  It will have a second ESP8266 WiFi device that will be shut off most of the time,  just waking up periodically to send a “phone home” set of data packets and will implement a small set of commands.

Auxiliary Sensor Subsystem

There are two parts to the other subsystem for sensors in SunRover.   There are internal sensors and the camera which are permanently attached to SunRover and then an extended 3D Printed box that attaches to the front of the robot for us to place temporary and experimental devices such as a spectrometer, a small servo controlled arm.   This is the place that we will be swapping out boards and instruments in the future as new cool sensors become available.

Raspberry Pi Software

The software for the Raspberry Pi will be primarily built on Python using a scheduling system called  APS (Advanced Python Scheduler)[ref:  https://apscheduler.readthedocs.org/en/latest/ ] and will be generally task and time oriented.   This will be a “soft realtime system” where tasks will be executed in order, but aren’t guaranteed to run at an exact time.  It’s designed to be kind of mushy.  This is the right type of realtime system to build upon a Raspberry Pi, since linux is a pre-emptive multitasking operating system and you can’t depend on exact times of execution.  Hence the term “soft realtime system”.

You can get a lot more accuracy out of an Arduino, but you just don’t have the resources and software that you do in a Raspberry Pi.   A “hard realtime system” tries to guarantee order AND time.  You can’t do that very easily in a complex operating system like the Raspberry Pi has.   Try to set up a program on a Raspberry Pi that will turn on and off a GPIO line every 1 millisecond.  If you look at it on a logic analyzer or an oscilloscope you will see jitter.  It won’t execute exactly on the 1 millisecond mark every time.   This is the reason most servo controllers use an external PWM device to get good accurate movement.

Next Up?

Next up is the motor controller / power supply design.