Sensors, ports, pins, drivers and firmware by example

Question

I am looking to just make sure I correctly understand the fundamentals for how robotic systems typically receive and process inputs from sensors.

It is my understanding that a sensor peripheral, such as a camera or a temperature gauge, will be built to either send its data over port (perhaps a serial port such as USB) or over individual wires that must be soldered/connected to the I/O pins of the controller running the robot's firmware/software. So perhaps the camera is a USB camera that expects to send RGB video frames over the attached USB cable to whatever is listening at that USB port. Or perhaps the temperature gauge is sending real-time temp readings over a few wires to whatever those wires are connected to.

It is my understanding that the robot's firmware must use device drivers to read/write values over its I/O pins for talking with these sensors. So both the camera and temperature gauge must have device drivers so that the firmware must talk to it. In the case of a USB camera, the USB drivers almost assuredly already exist for the OS, unless its a real-time OS that for whatever reason doesn't have USB drivers written for it. And in the case of the temperature gauge, either the manufacturer would write and provide device drivers for the gauge's use on numerous/common OSes, or I would have to write my own device driver for the gauge myself. In that case I could write a device driver to expect listen and read for signals coming from, say, pins 9-14, and to send any values written to those pins (by the temp gauge) on to a memory buffer that my firmware could read them out of.

So I ask: how'd I do? Is my understanding of this process correct? Or is it grossly midled or off-base somehow? Thanks in advance for any steering or course correction!

Answer 1

Yes. Your understanding is correct. But I would like to clarify some things.

The "brains" of the robot: software, controller, firmware, etc. on the robot can come in many forms.

• Simple robots might just have a bare-metal microcontroller. An Arduino for example. Which typically have direct control over GPIO digital and analog pins. As well as communication buses such as RS232, I2C, etc. There is usually nothing like an OS here.
• More advanced robots might run a full microprocessor like a laptop. In this case there is most definitely an OS and the hardware interface is restricted to the standard communication protocols: USB, RS232, ethernet, etc.
• Lastly, there are things like RaspberryPi which are kind of a mix between the two. The processor is powerful enough to run a "real" OS, support a wide range of communication buses/protocols, as well as provide some low-level GPIO.

On the other side, sensors come in a wide range as well.

• A temperature sensor can be as simple as a variable resistor.
• Or as complicated as a WIFI connected IOT device.

So you see that connecting one to the other is highly dependent on your hardware / application.

Interfacing hardware with the computer is a common problem in robotics. (Note that this goes for motor outputs as well as sensor inputs). Usually what is done is to have an intermediate processor. For example a servo controller, or a sensor hub. Which is basically just a microcontroller to interface with the hardware, and some communication protocol with API to read the senor or drive the motor.