Transfer video stream and detection result of multiple OpenMV through RS485 bus

When we threat the OpenMV as a stand alone sensor, we should first connect it to the IDE through USB, so we can see what the OpenMV Cam is looking at while working on our code,
but when we finish our code, we disconnect the USB, and for example, put the OpenMV to the end of a robotic arm, after that, we can’t know what is the cam looking at, and how is the recognition process.

Especially for a project which with multiple OpenMV attached, it’s hard to connect all device to PC through USB, so, I start to thought, why not connect all device through a single RS485 bus, include multiple OpenMV and multiple robotic arms, it’s very useful for industry applications.

I already doing it on Raspberry Pi, and I really want to do it on OpenMV, one RS485 port for every thing: communication with the IDE, upgrade firmware etc.
But I’m not very similar with OpenMV, and don’t have enough time for it at now, maybe a few month later. But now, let’s back to my demo:


Full video:

The Raspberry Pi can output preview video and control command at the same time. We can monitor the recognition process on the PC. When problems are encountered, it is convenient to know the reason and adjust the parameters, and disconnecting the PC will not affect the demo operation.


The human head shape board above the Raspberry Pi is a solderless socket board for CDCTL-Bx. It uses the CDBITE connection method: Bite the module with the probe.

The demo uses CDNET-TUN to set up a standard LAN, which allows video transmission without writing any code. And for controlling the slider, such as programming in Python via standard Socket communication, requires only 4 lines of code including the import statement, to control its movement and ensure that the command is delivered accurately. In addition, the Raspberry Pi can access the internet at any time through the PC, and it is easy to update software and for remote control.

However, for applications where high real-time performance is required, both the PC and the MCU can use the underlying CDNET protocol stack directly, which is very convenient to use.

This demo is base on the CDBUS protocol, which introduces an arbitration mechanism that automatically avoids conflicts like the CAN bus, more details:
GitHub - dukelec/cdbus_doc: Introduce to the CDBUS (Advertising, please ignore.) (Introduction)
GitHub - dukelec/cdbus: CDBUS Protocol and the IP Core for FPGA users (Protocol details & FPGA IP core)

A debug log picture for CDBUS is added. I use two computers to communicate through CDBUS Bridge box, share Internet from one to another, download files, and play MV videos on the YouTube for several days:


The device corresponding to /dev/ttyUSB1 has a low priority, so when it completed sending more than 16 million packets in one direction, it successfully managed to avoid 9753 data collisions. And there is no packet error or lost.

The RS485 baud rate tested was 1 Mbps + 10 Mbps, and the length of the test line is about 2 meters.

Moreover, even if the bus is short-circuited or disconnected from the bus, the upper CDNET protocol will automatically retransmit corrupted packets to ensure the integrity of the user data.

Hi, sorry for not getting back to you in a immediately.

To send video data over RS485 please use the hardware UART on the OpenMV Cam and set the baud rate to something very high. The hardware UART can run above 1 M Baud up to about 4 M Baud or so.

Then just do this at the end of your script loop:

uart.send(img.compress())

This will jpeg compress the image and send the byte stream to the UART. Now, you may wish to add headers and etc. to make it easier for your application to view.

Alternatively, you can use OpenMV IDE to open a serial port connected on the other end of the RS485 link. If you do that… using OpenMV IDE’s Open Terminal feature under tools… then you should to this instead:

uart.send(img.compress_for_ide())

This jpeg compresses the image and then turns the byte stream into a special format for reception over a clear text serial link with debug info from things like print(). OpenMV IDE will be able to decode the image and display it in the frame buffer.

Thanks for your reply, but I don’t think your solution is suitable for real applications, for example, if a robotic arm and an OpenMV module connected on the same RS485 bus, when the OpenMV output the image byte stream, and if we send command to the robotic arm at the same time, the data on the RS485 bus will conflict and corrupted, so we need a mechanism to avoids conflicts, which was already implemented in the CDBUS protocol.

Even for a single OpenMV, when it output data, most command we send to it will be corrupted and lost.
And don’t forget my post title is to connect multiple OpenMV through a single bus.

I hope you are not going to suggest me to use the traditional polling method, because that’s too slow to transfer video streams. :neutral_face:

Okay, I’m not really sure what you want me to do… if you want to hack the firmware to add the CBUS library please go ahead. You can also put a gateway device in front of the OpenMV Cam to handle the CBUS.

We provide the basics with the OpenMV Cam of being able to create a JPEG file stream and we provide a SPI bus / I2C bus / Async Serial bus on which you can send the data. If you have a device that can talk CBUS and route data over it please use that with the OpenMV Cam. It looks like there are CBUS bridges…

You don’t need to do anything for me now. I just want to see if anyone is interested in it. If so, I’ll take the time to create a matching shield for OpenMV as soon as possible and open source it for everyone to use. If I have problems in this process, I will ask you for help again. :wink:

Cool, well, to view the image stream just use the open terminal feature with OpenMV IDE and send the img.compressed_for_ide() jpeg data.

As long as the device appears as a serial port to the PC in some way shape or form you’re good.