IDE <--> M7 disconnects upon running script

OpenMV Products
#1

Hello,

Just received my M7 board and looking forward to playing with it!

I’ve downloaded the 1.6 IDE and flashed the latest firmware. When running the Hello World example script, the IDE always seems to disconnect from the camera. I expect the FPS values from the while(True) loop to be constantly written to the Serial Terminal in the IDE, but usually only get <10 values after reconnecting to the camera. Am I doing something incorrectly?

I have also tried the Snapshot example. A blurry picture is saved to the camera (will focus next), but the IDE disconnects each time and I don’t see the print() statements in the Terminal.

Appreciate the help!
V

#2

Kwabena is the IDE expert, he’ll get back to you soon, but to save you time, what’s your operating system ? And please try a different USB cable.

#3

Hi, what OS are you using? We’ve seen this issue before and some folks have fixed it by using a different computer. I’m pretty sure we’ll have to do a work around in the IDE to solve the problem. On our end none of my test mahines run into this problem so I haven’t been able to reproduce. The disconnection issue happens due to issues with the serial port driver on the host PC. I fixed one issue with windows systems that forget to return received serial data from the camera already, but, there could be another issue.

Anyway, so, you can either switch to another computer or OS and the issue will likely go away for you or if you’d like you can help me root cause the issue and hen I can apply a work around in the IDE.

#4

I am running OS X 10.11.6

I tried connecting with another USB cable, and the same issue occurred. I can use another PC, but am game to help you debug for my current case.

#5

Okay, if you use windows the issue may disappear or a VM inside your Mac.

Anyway, please try these three things and let me know what happens:

  1. Just connect to your cam via OpenMV IDE. Don’t run any scripts or anything. But, make sure a script stays open. Does the green run button stay highlighted? Observe how long is stays around. Does it disappear? It should just stay green forever if there’s no problem.

  2. Assuming the run button stays green, disable the frame buffer (top right hand corner) and then run the hello world script. You’ll get text output only on the serial terminal. See how long this works for. If everything is good it should run forever.

  3. Finally, enable the frame buffer and see how long the system runs. If it’s good it should run forever with video. Since you’re having a problem you likely won’t get to here.

…

I really need to USB analyze your computer to see the issue but this gets me kinda close.

#6

Hello,

I could run steps 1 and 2 successfully. The script does not run for step 3; the camera instead disconnects from the IDE.

I don’t know if this is useful, but I borrowed a USB analyzer from work to sample the communications (see attached). There are various export options, let me know if you need a different form of file/data.

I’m using a pretty old MBP for this, with only USB 2. I’ll switch to a Windows desktop with USB3 if the problem is intractable.
vtun frameBuffer enabled.csv (349 KB)
vtun frameBuffer disabled.csv (113 KB)
export options.PNG

#7

Mmm, the traces will help. Will look at them. Thanks. Also, can you let me know how long the system is able to run step 2 for? Wondering if this is a data limit issue or something. The only difference when the frame buffer is enabled is that there’s a lot more data moving over the wire.

#8

Thanks for these traces. Very helpful. So, it looks like the issue is something subtle going on in the driver. All data is transferred over the USB fine. However, the serial thread reading/writing data appears to never get all the image data from your computer’s serial port driver.

I fear this is an issue with the kernel dropping serial data. This may be what’s been hounding us with phantom problems constantly. (Yes, this does happen. Seriously. Making a cross platform IDE is F’ing hard).

I think the fix for this is just to request less data in one go. This will affect the IDE frame rate somewhat but should fix the issue. What bothers me is that I requested less than 4K which most Kernel buffers are sized too… Not sure how small I should break up packets into.

…

Got any info on your computer’s USB hardware? :slight_smile: Probably not, I know. I just need to figure out to break up image packets. Maybe I can make the IDE smart and have it dynamically change the chunk size.

…

Anyway, I should be able to generate a test IDE image soon for you. I’ll do this today.

#9

Mmm, the OpenMV Cam doesn’t support chunking up reading the image data. This will be harder.

#10

Try this IDE out. Please let me know if the problem was fixed. The changes I made seems to have fixed the read stall issue. Maybe your issue is fixed too.

http://upload.openmv.io/openmv-ide-mac-1.7.0/openmv-ide-mac-1.7.0.dmg

#11

Hi Kwabena,

Unfortunately, 1.7 didn’t work with helloworld once I enabled the frame buffer. This IS an old laptop that I’m using. What details about the USB hardware do you need? Perhaps you can make your life easier by issuing minimum hardware requirements for the pc.

Also, you asked a little earlier to see how long the helloworld could run if I disabled the frame buffer. For version 1.6, it was ~9.81 minutes.

I’ll be switching to a newer PC to run things, so please consider this issue closed. I’m happy to run small tests if you need them.

Thanks, V

#12

I reviewed chunking up commands to the OpenMV Cam and I may implement it for the next version of OpenMV IDE. That said, it’s somewhat hard to work around the kernel dropping bytes… Not sure what the maximum USB buffer size is for the driver your Mac is using for generic serial ports.

I don’t think the issues is in your hardware. It’s likely just the serial port driver not allocating enough buffer space to handle data sent at 12mbps. It’s probably assuming the camera is a standard serial port not able to transfer data faster than 250000 bps. Thus, the buffer in the driver to receive bytes before delivery to the user application is probably not that big.

If we wrote a custom driver we could get around this but that would be even more work.

#13

I k ow how to fix this issue. I just need to get some time to work on it.