[Dprglist] Anyone using an Omega2 Pro?

[Murray Altheim]

On 20/09/20 5:35 pm, David Anderson via DPRGlist wrote:
> Howdy

Hi David,

> On 9/19/20 3:18 PM, Jim Merkle via DPRGlist wrote:
>> Need to figure out what you plan to do with the board / why
> THIS board is necessary.
> 
> Seems like most of the robots I see on the net that are using a 
> RPI or similar to run a robot,  also use a separate board, STM32
> or Arduino or similar controller, to do the real-time stuff and
> provide all the needed I/O pins, hardware timers and comparators
> and such.

The Pi's 40 pin GPIO has I think 22 digital IO pins, which is for
most robots probably enough. As there are no analog input or output
pins one has to use an external board for that.

> So that's a reasonable place to put things like motor control and > encoders and odometery, as well as drivers for various sensors and
> actuators.  The RPI/Linux board can then deal with things like 
> cameras and -WiFi.

Most of the Pi boards run from 1-1.5GHz so they're not generally
underpowered compared to a 16MHz Arduino, but those higher-level
things like cameras, cameras-as-sensors, WiFi, etc. can use up a
lot of cycles quickly.

> That seems like a good separation of labor.  You don't have Linux 
> on the robot controller board but you can have an RTOS to provide
> concurrency and timed delays and the like.   For which there are
> a number of good free options available.

There's another way of looking at this.

Rather than use Pi GPIO pins for robot IO I've tended towards using
I2C devices, which generally don't load the Pi much at all, i.e.,
the boards that require processing power often have their own
on-board processor of some sort. For example, the Pimoroni IO
Expander connects via I2C and provides 8 digital IO and 6 analog
IO pins, using an on-board 16MHz Nuvoton MS51 microcontroller to do
all the work. The PMW3901 Optical Flow Sensor and the VL53L1X Time
of Flight Sensor both use fancy sensor chips that themselves do all
the work. Even the MLX90640 thermal camera sensor boards rely on
the sensor chip itself, providing an I2C interface. The HuskyLens
and PixyCam camera-as-sensors are again using their own processors
and connect via SPI, I2C, UART or USB.

So yes, this separation of labour seems to work very well.

 From NASA's 1996 Mars Sojourner rover to the latest Curiosity Rover,
there's a central control processor with the complicated sensors
and scientific instruments providing their own processing power.

> I see the attraction of doing both of those functions, high and
> low, with the same hardware.  But seems like it might lock you 
> in. Especially after having spent the many hours required to get
> the I/O and drivers to work.

Well, unless one buys a readymade robot there seems to be some
investment required at *some* level. I'm still futzing around with
PID controllers, whereas Harold is using ROS and gets PID control
for free. That's a different kind of lock-in...

Cheers,

Murray

...........................................................................
Murray Altheim <murray18 at altheim dot com>                       = =  ===
http://www.altheim.com/murray/                                     ===  ===
                                                                    = =  ===
     In the evening
     The rice leaves in the garden
     Rustle in the autumn wind
     That blows through my reed hut.
            -- Minamoto no Tsunenobu