Extensible Robotics Framework

A unique electronic system that controls the robot

The Need for Flexibility

Imagine you have a PC with 3 USB ports. You connect your mouse to one, keyboard to another and a printer to the third. If you then want to print a file from your thumb drive, you would need to find a workaround. Similarly robotic systems need to interface with various sensory devices and actuation systems at a low latency. But most micro-controllers have limited I/O. This is why many robots need to be paired with larger systems, that are expensive. To reduce the cost I can up with a system that allowed multiple small micro-controllers to work together to achieve the functionality of the robot. This enabled the robot to be interfaced with a large number of sensors and actuators without slowing down its operation.

Targeted Sub-Systems

The robot needs to have multiple functions running in parallel. The metal detection system, the drive control, the coil segment actuation, the live video feed, the GPS and compass reception, all need to be running simultaneously at any point. We cannot reliably achieve this on a single inexpensive micro-controller. Thus its was necessary to create targeted subsystems that would only handle the particular task that was given to them and communicate with other systems as and when necessary. These subsystems communicated with a more competent SOC computer that served as a master to these micro-controllers(slaves). Thus the drive system was sourced to one controller, the metal detector system to another and so on. There are 3 micro-controllers and one master SOC computer deployed on the robot.

Extending the busses out of the controllers

Now the question arises as to how we establish communication between these controllers. A obvious answer was to extend the inbuilt communication buses that allowed the micro-controllers to communicate with sensors. The SPI and I2C protocol pins could be extended out into a parallel bus that allowed multiple micro-controllers and sensors to be connected together. Thus I created a protocol distribution board that allowed connecting multiple sensors and micro controllers. The I2C having a theoretical maximum of 255 devices to be connected, was used solely for sensory operations whereas the high speed SPI was used for real time operations like live command and remote control.

Google Sites

Report abuse