For robotics system design, it is often useful to think about dividing system functionality by time scales. For SparkiSLAM, I'm splitting tasks into three groups: "real-time," fast, and slow. 

"Real-time" tasks are processes that need to react very quickly. Examples instead closed loop control of motor speeds, edge detection and reaction for line following, and obstacle or cliff avoidance. These control loops are computationally simple and need to happen very quickly

For SparkiSLAM, these so-called real-time tasks run on-board the Sparki's Arduino-compatible processor. The Sparki will poll for commands over serial, move it's servo-mounted distance sensor, read from the distance sensor, and transmit the information over serial. I may also add cliff detection and avoidance and send accelerometer and magnetometer data over the serial connection to use sensor-fusion for positioning.

Fast tasks are processes that require more computation and need to be off-loaded to a separate processor. This ensures that tasks that need to occur quickly like very fast feedback loops are not bogged down by higher level functionality. In this SparkiSLAM project these tasks will run on a Raspberry Pi that is mounted on-board the Sparki, connected through a serial connection, and powered by the Sparki's batteries. Tasks it will perform include trajectory following, state estimation, and sensor fusion.

Slow tasks take more much computational power. These processes include the SLAM algorithm itself and path planning. These tasks do not endanger the robot or its operators so it's OK if these task run at a few hertz or less. For now, I will try to run these processes on the Raspberry Pi. I hope to off-load them to a server to make this a cloud powered robot.

One of the broad goals of this project is to create a simple way to deploy cloud processors to perform complex robotics algorithms to reduce the cost and complexity of robot hardware and make advanced robotics more accessible to students.