New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Cam Test Fails on OAK-FFP-3P with 2x AR0234 and IMX378 #788
Comments
When you switch to a branch, you also need to run |
If you download as |
I cloned it using Git Desktop, I don't do zip downloads for that reason. |
What's the output of |
Some of these commands fail:
|
@kneave This setup works for me, just tried on OAK-FFC-3P:
I suspect the EEPROM is not properly set on your device, to identify it as an FFC device, where more camera sensors are being probed. An empty EEPROM (not calibrated) would work too. |
Calibration is something I've been having no end of trouble with so very likely is in an unknown state. For the name of the board, it was NEFIVE that I set it to. Do I need to change the filename of the board definition and the board name in it to append -FFC-3P at the end? What should I put as the revision? For the eeprom, how can I do a reset to blank to test this? |
Data from calibration dump is below in full, I think these are the important parts though:
By the way, I have tried going back to the ar0234_x3 branch which has previously enabled me to at least see the cameras in the calibration.py script, if I try and run it now however I just get the following: I am still able to preview the cameras fine with the script attached to the first post here so I've no idea what it's complaining about and I can't find an explanation here or on the forums. I have previously been fighting to get this calibrated, more info on the history here, and it looks like this device is in an unknown state now. I've tried running the factory reset script but it says there's no factory calibration to use. This is an FFC-3P though so I wouldn't expect it to have one as it came without cameras. If you're saying this should work on the develop branch then can you share the procedure to put this back to the factory state please? As you will see on the forum thread I've been trying to get this working for a long time now, I bought this device as I'd heard nothing but good things, I suspect that's for the preconfigured cameras though as the 3P really doesn't seem user friendly. I'm taking notes as I go so will be writing up a guide for newbies to get started and avoid all the problems I've hit. I need to fix them first though and that doesn't seem possible right now. Full config as dumped:
|
cc also @njezersek on calibration part. @kneave shared on forum:
|
Thanks Erik, any tips to get it back to a factory state would be greatly appreciated. I'm certain that a lot of this is me excitedly trying different things to get it working without really knowing what I was doing. I'll definitely be happy to share my notes once I get it working to help get others up to speed quicker. |
I would recommend this slightly less dangerous approach, with lower permissions for accessing only the EEPROM user area protected fields. It will update in-place the existing user calibration, modifying just
(the environment variable prepended to the command would work on Linux or MinGW, otherwise set for PowerShell similar to above, but use @kneave On the device you have, the factory calibration seems missing, it's probably a device from an earlier batch, but that should be fine. |
Thanks folks. Alex, what branch should I run your script against please? I'm getting the following error at the minute:
|
@kneave The script |
@kneave I think the old library is still installed. After switching branches, install the current one from the branch by running Adding for reference how I tested, flashing the calibration data from your post above to my FFC device, saved to a custom_calib_dp788.json file:
|
I was running |
That's great!
Yeah, that seems to be a bug in listing (which just shows features/capabilities), but shouldn't otherwise affect functionality or image quality. Thanks for catching that!
(AR0234 has both color and monochrome variants, but I'm not aware if it's possible to query the actual type from the sensor registers. At least for OV9282(mono)/OV9782(color) which present themselves as the same type of device, we haven't found a way to differentiate) Note about this warning: |
Ah, that'll explain the much lower framerate I'm seeing. Before with just one or the others I was seeing 30/60fps and now it's at about 19 which is not ideal to say the least. I actually chose the IMX389 because it was a tiny module and fit perfectly in the robot's head that I'm building. Previously he only had the two cameras so it wasn't an issue but for the third I needed one that was tiny to fit between and be able to maintain the aesthetic. Do you know of another similarly sized module that may not have the tuning issue? Alternatively, is there a way I could tune them myself or is that a bit hardcore? Photos for context: |
Playing around in cam_test I've managed to get it to 30fps across the board. I've tweaked the code to change the resolution of the IMX378 to 1080p and also set isp_scaling to 2. I'm not sure if this will improve if I'm not viewing the images and just processing them on the FFC-3P or not but it's good enough for me right now. Command line: This is pretty much my use case at the minute by the way, having the two wide angle cameras to generate a colour point cloud with the centre much narrower to allow for closer views of whatever the robot is looking at. The next task is to figure out the calibration of cameras with such different angles, I suspect I'll treat them separately and calibrate left and right together with the centre calibrated by itself. I've no idea if this is realistic in practice as I've not got this far before, but thanks to your help I can at least run scripts again. :) I'm happy for this to be considered closed, and thank you for your help with that, but if there is an issue for the AR0234/IMX378 combination for tuning performance I'd appreciate a link so I can follow progress and get updates. |
I think I've got calibration working but I'm getting the following error trying to update the device:
results of
|
@kneave which commit are you on? Make sure calibration is first read - then modified - then flashed. Otherwise above env var could be reapplied if there are still issues |
I'm was switching between a few branches trying to get it to work but they were all throwing the eeprom permission error. I managed to get it to flash using the env variable but if I try running any of the demos I get permissions errors again. It says to check udev but I'm on Windows I'll go through it again tomorrow and try again, I'm not quite sure what's going on at the minute. |
@kneave were you on Which script did you try that it prints the above? Is there anything else running in the background, using the device? |
The script was the depthai_demo.py on depthai:develop, there wasn't anything else running against the device at the time. Feel free to stand down for a while, I'm going to have a proper look at everything and make sure it's all in a sensible state before I take any more of your time. Thank you for the help so far :) |
This issue: |
Amazing, I'll give it a go today and let you know how I get on. Would this update be compatible with the pointcloud branch too by any chance? I've been using that a lot recently with a triple AR0234 setup and if I can bring the IMX378 back in to play with it it'd be ideal. I'm not sure how the two interact though to be honest, I suspect they're both separate firmwares? |
W00t! Finally been able to test this and it looks like it works a charm! Before, when I had the AR0234 and IMX378 enabled the white balance on the AR0234 was terrible, now it's identical with the IMX378 running! For how it was before, please see this post: and now, no difference! |
Check if issue already exists
I have found no reference by searching online or the forums
Describe the bug
I have an OAK-FFP-3P with the following configuration:
Left: AR0234
Centre: IMX378
Right: AR0234
When I try to run cam_test.py using the develop branch of depthai-python (which includes depthai-core) it fails. The AR0234 are also not detected. Note, if I switch to the ar0234_x3 branch, all the cameras are detected.
Image showing only the IMX378 detected when using the
develop
branch:Image showing the same script reporting all three cameras, running from the
ar0234_x3
branch:Minimal Reproducible Example
Expected behavior
I would expect cam_test.py to succeed and be able to stream all cameras.
Additional context
I have attached the simple preview script I've been using to test the cameras on each branch.
preview.zip
The text was updated successfully, but these errors were encountered: