Skip to content

Feature/dynamic calibration on start#1695

Open
JakubFara wants to merge 51 commits intodevelopfrom
feature/dynamicCalibrationOnStart
Open

Feature/dynamic calibration on start#1695
JakubFara wants to merge 51 commits intodevelopfrom
feature/dynamicCalibrationOnStart

Conversation

@JakubFara
Copy link
Collaborator

AutoCalibration node

Purpose

  • The auto-calibration of the camera on startup.
  • The auto-calibration process is invoked only if the stereo pair is present.

New AutoCalibration node

  • This node has a DynamicCalibration subnode.
  • Firstly, we check the current calibration; if it is not good, we recalibrate using the DynamicCalibration node.
  • The auto-calibration is turned off and can be turned on by DEPTHAI_AUTOCALIBRATION=on.

Remarks

  • It runs only on the host.
  • The packetization is not involved yet.

Testing

  • Basic test is added to the tests/src/ondevice_tests/pipeline/node/auto_calibration_test.cpp
  • Run the HIL tests with the DEPTHAI_AUTOCALIBRATION=on
image

Copy link
Collaborator

@MaticTonin MaticTonin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good, put some general comments on what should be checked before even marking it as testable.


# "full commit hash of device side binary"
set(DEPTHAI_DEVICE_SIDE_COMMIT "5aea90014bbf269c4f2e09243fcd502e28174be7")
set(DEPTHAI_DEVICE_SIDE_COMMIT "665f8773f7269292eabd2ee562debb2a778776a4")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check what is latest develop, so we dont downgrade.


# "version if applicable"
set(DEPTHAI_DEVICE_RVC4_VERSION "0.0.1+d5a6e66b0e2a72a400ac6a4cd1dc79eb033fa68a")
set(DEPTHAI_DEVICE_RVC4_VERSION "0.0.1+5ee962d36af9c2f04ec126aa10cc8083dba61dde")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check what is latest develop, so we dont downgrade.

: dataQuality(dataQuality), calibrationConfidence(calibrationConfidence), passed(passed), calibration(calibration) {};
virtual ~AutoCalibrationResult();

double dataQuality;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docstings

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done here: 9808e7368

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comments as above.

@moratom
Copy link
Collaborator

moratom commented Feb 27, 2026

@JakubFara this doesn't have the packetization right?

@moratom moratom added the testable PR is ready to be tested label Feb 27, 2026
@JakubFara JakubFara force-pushed the feature/dynamicCalibrationOnStart branch 2 times, most recently from 4ef8d97 to 610ef67 Compare February 27, 2026 07:24
Copy link
Collaborator

@moratom moratom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, exitcting!

Left a few comments/questions.
I think we should add packetization here as well (on the bridge created after Gate node).

Comment on lines +663 to +670
if(buildInternalQueue) {
// Starts pipeline, go through all nodes and start them
for(const auto& node : getAllNodes()) {
if(node->runOnHost()) {
node->buildInternalQueues();
}
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this internal queues?
Linking subnodes together without using createOutputQueue() doesn't work?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a subnode, and I would like to create subnode->output.createOutputQueue() inside the parent node.
The problem is that if I use :
 - parent::buildInternal(){subnode->output.createOutputQueue();}
The parent on the subnode is uninitialized and points to null.
 - parent::start(){subnode->output.createOutputQueue();}
The pipeline is already build so I can not create the queue anymore.
If I shift the start() before the pipeline is build it works, but it could cause some issues with other pipelines.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have changed it to buildStage1, and it does the same.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we use the "conventional" way and add inputs to the parent node and then do a normal link between the subnode and the parent node?

The why for my ask is mostly that createOutputQueue() approach won't work if we later mate this node device runnable on RVC4.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also - pipeline graph will show the structure much nicer in that case as the information gets lost with createOutputQueue() (the information on how the internal connections look like)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not realize this option. Fixed here: 9041e3a67 Replace createOutput/InputQueue with linking

Comment on lines +24 to +25
auto outputCameraLeft = cameraLeft->requestIspOutput(20);
auto outputCameraRight = cameraRight->requestIspOutput(20);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any specific reason to go with 20?
I think going with "default" makes more sense here, to avoid having troubles syncing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed here: f94689e Set fps in ISP to default

@JakubFara
Copy link
Collaborator Author

#1695 (review)

I’ve identified a bottleneck in the current packetization logic. If the transmission time exceeds the message arrival rate, buffer overflows occur, leading to message loss. This is unintended behavior.
My Solution: Implement adaptive packetization. The system should estimate the arrival time of the next message and dynamically adjust the packet intervals to ensure they are processed within that timeframe.

@JakubFara JakubFara force-pushed the feature/dynamicCalibrationOnStart branch 3 times, most recently from 95fcff9 to c0a8b3a Compare February 27, 2026 12:20
@moratom
Copy link
Collaborator

moratom commented Feb 27, 2026

I’ve identified a bottleneck in the current packetization logic. If the transmission time exceeds the message arrival rate, buffer overflows occur, leading to message loss. This is unintended behavior.
My Solution: Implement adaptive packetization. The system should estimate the arrival time of the next message and dynamically adjust the packet intervals to ensure they are processed within that timeframe.

Not sure I understand, XLink streams internally are blocking, where does the buffer overflow happen?
What should happen is XLink creates upstream blockage (stops receiving frames from the input queue).

Can you elaborate on which buffer overflows?

@JakubFara
Copy link
Collaborator Author

JakubFara commented Feb 27, 2026

Can you elaborate on which buffer overflows?

If you send messages slower than they are coming, you have a problem (on the XLlink side, the input is not blocking, or on the sender side if it is blocking). Because of that, I think that the FPS should not be set in the XLinkOut stream. You can simply set it on the Gate side in this case, though.

@JakubFara JakubFara force-pushed the feature/dynamicCalibrationOnStart branch 3 times, most recently from de12aa5 to 67272b5 Compare March 2, 2026 15:48
Comment on lines +626 to +661
if(isBuild) return;
// start ---Add AutoCalibration block---
std::unique_lock<std::mutex> lock(pipelineBuildMutex);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this intentional?

The idea before was to lock before isBuild is checked, to avoid a race condition here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will move it before the check

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if(isBuild) return;
// start ---Add AutoCalibration block---
std::unique_lock<std::mutex> lock(pipelineBuildMutex);
auto autoCalibtationString = utility::getEnvAs<std::string>("DEPTHAI_AUTOCALIBRATION", "");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to add this to the README.md

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JakubFara JakubFara force-pushed the feature/dynamicCalibrationOnStart branch from e206ded to c52f725 Compare March 3, 2026 15:06
@MaticTonin MaticTonin added testable PR is ready to be tested and removed testable PR is ready to be tested labels Mar 3, 2026
@MaticTonin MaticTonin added testable PR is ready to be tested and removed testable PR is ready to be tested labels Mar 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

testable PR is ready to be tested

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants