R

rmaxwell

In addition to higher MAP, YOLOv10 has far fewer params to the point where the 's' size model may be practical to run on the Myriad (depending on how many operators spill over). Would you be able to open source the firmware so the community can make these changes itself rather than Luxonis having to do this internally each time a new model comes out? Previously Intel has been a blocker to open sourcing the parts relating to the MX, but is this still the case? What about with RVC4?

Thanks jakaskerl that works

Hi jakaskerl, I'm running it on the video. You can see my changes here: https://github.com/luxonis/depthai-experiments/compare/master...RichardHMaxwell:depthai-experiments:script-blocking

erik I craeted an issue here: luxonis/depthai-core864

erik What should happen to the input queue in the above scenario, i.e. If the script node slows down both of the output queues, then should the input queue back up?

Hi,

The docs don't provide an explanation of how data is shared between the ScriptNode and other nodes and what the synchronisation behaviour is. From the people tracker example i can see that tracklets are retrieved from a dict-like object called node.io and that accessing the tracklets appears to be a blocking call. To experiment further, I inserted a 0.5 second sleep in the python script and I noticed that this slowed down both output queues of the pipeline (i.e. both the video output and script output), but it didn't cause the input video queue to back up/block as expected. The tracklets appeared to back up too, which means that if the script is consistently slower than the input stages of the pipeline, then the device will eventually run out of memory.

Would someone be able to describe what the expected behaviour in the above scenario is?

Hi,

I'm trying to read data in a python ScriptNode via UART, and the read and read_line functions return immediately rather than blocking until the configured timeout is reached. By default, the timeout is None, which means that those pySerial functions should block until the requested number of bytes are available / until a line feed is received. I have tested this on both an OAK-FFC 4p and OAK-PoE 1p using the default UART settings on both the transmitter and receiver (i.e. 1 stop bit, no flow control or parity bits). To reproduce, you can run the following script:

    import serial
     
    ser = serial.Serial("/dev/ttyS0", baudrate=115200, timeout=None)
    while True:
        result = ser.read_until()
        node.warn(f"received {len(result)} bytes: {str(result.decode(encoding='ascii',errors='ignore'))}")

If nothing is plugged into the UART pins you will see the script print 1000s of messages per second, and always 0 bytes read. If you actually send a line feed terminated message over UART you will see that your message is broken over several log lines rather than just the expected single line - and of course there will still be 1000s of 0 byte messages in between.

Note that if you set timeout=1 (1 second according to the pySerial docs), the behaviour is approximately the same as above, however if you set much larger values, then the results are strange: with timeout=1000 the call blocks for ~1.6 seconds, and for timeout=100 it blocks for 23 seconds

I also noticed that on two occasions that the very first call to read_until would block indefinitely even when the TX side was sending data.

PS: the docs don't say that it is pySerial that is provided by the script node environment, or which version of the library is being used. I'm just assuming this is the case based on the module and method names.

Hi, i'm also interested in using the ffc-4p with SoM-Pro for prototyping. The datasheet says the ffc-4p uses the SoM-Pro, which has 128MB of flash, so could someone please explain where the 16MB limitation discussed above is coming from?

Thanks very much erik

Re support: i'm using the SoM-Pro, not the IOT - is the Pro still supported?

I'd like to use the OAK-SoM-Pro for an industrial computer vision application and I need to be able to update the model, depth AI pipeline and config from an ESP32 over SPI. The reason I need to do OTA updates is because it's not practical/affordable for us to remove the device and connect it to a host computer over USB each time we want to deploy an improved model, or tweak the pipeline config. I can see that there were plans to add support for updates over SPI, but i couldn't find anywhere in the documentation for the bootloader, integration guide or SoM-Pro that explained how to do it. Could someone please explain how / give an example? It would also be nice if we could use the dap format for these updates so that we don't need a lot of bandwidth to push minor updates.