Please provide the following info (tick the boxes after creating this topic): Software Version
DRIVE OS 6.0.8.1
Target Operating System
Linux
Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
Host Machine Version
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
In run*.sh file
with ${DATA_SOURCE} = “SENSOR”
I am not able to run simple camera pipeline,
I am getting following error
<11>1 2023-12-18T14:44:34.554302+01:00 - camera_pipeline0 15086 - - [0us][ERROR][tid:rr2_main][LaunchSpecReader.cpp:596][LaunchSpecReaderBase] apps/roadrunner-2.0/framework/core/LaunchSpecReader.cpp(596) DW_FAILURE Could not get libName of app: cgf_sync_ctrl_client
<11>1 2023-12-18T14:44:34.554355+01:00 - camera_pipeline0 15086 - - [0us][ERROR][tid:rr2_main][LaunchSpecReader.cpp:596][LaunchSpecReaderBase] apps/roadrunner-2.0/framework/core/LaunchSpecReader.cpp(596) DW_FAILURE Could not get libName of app: cgf_sync_server
is cgf_sync_ctrl_client & cgf_sync_server are only meant to be used with virtual sensors? Let me know.
I couldn’t find any documentation regarding this.
PerceptionPipeV1.zip (105.2 KB)
here is the app that i created using only the pre-bult node, when i try to run this app with the bash script i have error
DW_FAILURE Could not get libName of app: cgf_sync_ctrl_client
DW_FAILURE Could not get libName of app: cgf_sync_server
in the log
I am not sure cause of it, if you can give me some pointers about this it will help.
I think these two are different examples I tried to implement… the one that you tagged here is based on minipipeline example and this one is more related to cgfdemo pipeline… errors that i get are different I don’t know if is it related … let me know…
Dear @SivaRamaKrishnaNV@VickNV ,
This topic is blocking for me,
cgf_sync_ctrl_client and cgf_sync_server are prebuilt binaries,
The question is are these only supposed to be used in GCF demo pipeline,
or can be integrated into any custom pipeline? is there any dependency? necessary to use CGF deme pipeline as a base?
I was trying to reuse it for synchronization, but if is it not the intended use let me know. If you can point to any relevant documentation it will be helpful. Thanks.
Hi @SivaRamaKrishnaNV I am not sure if removing two entries will serve my use case, I wanted to use them for the synchronization of sensors. It will help me a lot if you let me know the intended use of these two binaries. Thank you.
You can ignore cgf_sync_ctrl_client . The cgf_sync_server is in charge of most of the synchronization during the CGF initialization and exit.
These are noise and expected to remove in next release.
FYI, for cgf_sync_server entry in json file, the participant denotes the number of clients(processes) that needs to be synchronized. It varies in each application.
Dear @SivaRamaKrishnaNV ,
Sorry for the late reply,
Can I have more information about “cgf_sync_server”, It can be with referenced to cgf_demo app?
the number of clients mentioned are 7, and the port 4002 is also mentioned in CGF demo example, which are these 7 clients in this example and how these clients know about port 4002 ?
How exactly the synchronization happens in this cgf_demo example from NVIDIA.
Thank you.
Dear @sushant.bahadure,
which are these 7 clients in this example and how these clients know about port 4002 ?
The seven clients are camera_master,schedule_manager,cgf_sync_ctrl_client,camera_pipeline0,camera_pipeline2,camera_pipeline3,camera_pipeline4 . The default port number for client is 4002. We have used client names instead of num clients(i.e 7) to avoid confusion in next release.
How exactly the synchronization happens in this cgf_demo example from NVIDIA
There are several stages in the synchronization:
(1) The clients handshake with the server by pre-defined port/address using socket, registering their interested fences.
(2) The clients call an api “sync” with a fence as its input, which sends a message containing the fence and the client’s ID to the server. The api “sync” is blocking call.
(3) When receiving a message from a client, the server will check the status of all clients that are interested in the fence in the message. If all clients interested in the fence are already blocked by api “sync”. The server will send out messages of “proceed” to those clients (containing the fence).
(4) The clients that receive a message of “proceed” from the server will unblock the corresponding “sync” according to the fence. The api “sync” will then returns.
By utilizing the combination of fences and api “sync” in the codes, synchronization can be achieved among multiple clients.
Dear @sushant.bahadure,
No, you don’t need to implement any changes in the custom node codes. This is taken care at process binaries like LoaderLite, ScheduleManager, CGFSyncControlClientLite, CGFSyncServer