RasPi UI Proposal

Here's a quick mock-up of the RasPi service UI.
Having a pin out reference I always find useful ...  can prevent blue smoke sometimes :)
Alexinator40 and Ray have been suggesting a generalized I2C interface.  I think components from the Serial service can provide a UI which allows for generalized reads and writes to devices on an I2C bus.
The buttons on the right would be just to read and write GPIO pins..

Not sure .. got to start somewhere. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Ray.Edgley's picture

A good place to start :-)

The GPIO pins on the Raspi could be potentially used for any digital interface similar to what the Arduino does.

In general the GPIO can be configured as an input of an output.

None of the GPIO are analog, but that just simplifies it a bit :-)

Like the Arduino, some of the GPIO pis are multi-function:

I2C on GPIO02 and GPIO03
SPI on GPIO09, GPIO10 and GPIO11
I2S AKA PCM on GPIO18, GPIO19, GPIO20 and GPIO21
TTL Serial on GPIO14 and GPIO15

The ability to access and use the GPIO could be very useful instead of having to add another breakout board to have digital IO via the I2C which already has the service for the PCF8574

The generalized I2C interface could be used not just on the Raspi3 but also on the Arduino with it's I2C interface, the generalized I2C would allow for experimentation with new I2C devices that specific services have not yet been created for and I would suggest that it not be considered an expansion of the Raspi service but as a separate service in its own right.

The major thing that's required for the generic I2C service is the ability to convert or cast byte data (I2C native format) to other data types. An array of  4 byte can represent a float, or real value, just split up for the purpose of transmission on the I2C bus.

The Python service (jython) is very good for beginners to the world of robotics, and being able to use the I2C for new types of I2C devices within Python would be a major advantage.

GroG's picture

USB Cam --> RasPi --> 

USB Cam --> RasPi -->  mjpg-streamer -->  http/mjpg over network --> laptop --> mrl --> opencv --> browser

GroG's picture

Very little if any noticable

Very little if any noticable difference between aiming a browser directly at mjpg-streamer vs aiming a browser at localhost running the webgui and using OpenCV's mjpeg to stream.
The second route is going through an additional filter lkoptical track too, while converting the binary opencv image into a base64 jpg to be displayed.

Some frames are skipped.

Terrible and mrl is running at 110% on the raspi :P - slow fps and high latency (calcualations are still messed up :P )