Receiving data from UDP (like unity livelink stream but the other way around)

Software C++
1

I have already posted in an existing thread my question, but I post it here again it case it hasn’t been seen.

So I succeeded in making the livelink stream work but I would like to listen-receive incoming UDP data in order to change some options in my while loop in real time without having to recompile.

I have tried this below but I received in the console.

Receive failed (recvfrom()): No error

Here is my code :

I declare outside the main loop:

std::string recvAddress;
unsigned short recvPort;
recvPort = 20002;

then in the main loop

// UDP Receive
        try
        {
            sock.recvFrom(recv_buffer, max_data_recv_buffer_size, recvAddress, recvPort);
            //std::string receivedData((char*)recv_buffer, bytesReceived);
            std::cout << "Received : " << recv_buffer << std::endl;
        }
        catch (SocketException& e)
        {
            cerr << "errror" << e.what() << std::endl;
}

and even tried this way :

// UDP Receive
        try
        {
            size_t bytesReceived = sock.recvFrom(recv_buffer, max_data_recv_buffer_size, recvAddress, recvPort);
            std::string receivedData(recv_buffer, bytesReceived);
            std::cout << "Received : " << receivedData << std::endl;
        }
        catch (SocketException& e)
        {
            cerr << "errror" << e.what() << std::endl;
            //exit(1);
        }

Am I missing something?
@JPlou any thoughts ?

2

Hey @robotpapier,

If I understand correctly, you want to send data from unity to the sender, to change runtime settings for instance. You have to add a sender in your unity project, and a receiver in the c++ sender, as UDP is one way only.
Have you implemented the sender part in Unity?

3

Hi @JPlou
Thanks for your reply.
Yes I can send message and can test that it is working.
I figured out why, my console shows : Receive failed (recvfrom()): No error
I forgot to bind to a local port.
So I added this code before my loop :

sock.setLocalPort(3338);

and in the while(run) loop , i have this :

int bytesReceived = sock.recvFrom(recv_buffer, sizeof(recv_buffer), recvAddress, recvPort);
std::string receivedData(recv_buffer, bytesReceived);
std::cout << "Received : " << receivedData << std::endl;

Now I can receive whatever message that is sent on port 3338. Houra !

But now I face another issue, the loop is stopped and Zed can grab a new frame only i I send an udp message :confused:

Do you know how I can prevent that? Do you knwo how I can run another loop maybe? Or if we can do it another way?

4

I think the function recvFrom must be blocking, so you should use it from another thread.

We have samples the use multithreading, like this one: https://github.com/stereolabs/zed-sdk/blob/abd4831de33832d2d2e29c15b60022793607b1b9/recording/recording/multi%20camera/cpp/src/main.cpp#L112

pool is a vector of threads, and the first argument passed on the line I linked is the function to be run (defined above), and the other are the arguments of the function.

Do not hesitate if you have more questions. :smiley:

5

Thanks again for this useful link.
I’m implementing it right now.

In the meanwhile, for now when I grab images from Zed to do bodytracking, I want it as fast as possible so I don’t have do any sleep at all.
But I have seen several time in example code sometimes you put 10ms or 50us of sleep.
Do i have to do this?

When I use opencv to display images, I am forced to sleep for 1ms other wise it freezes, but when i don’t need to monitor the camera, I comment the opencv lines for displaying the image and comment also any sleep function. And it works like this.

What is good practice, if no sleep, is there more risk of freezing?

6

Your example with threads is working great! :slight_smile:
Thanks !

1 Like
7

In most cases, when communicating between applications, you don’t want to continuously send data that can just be empty or containing info saying it’s empty. So by putting sleep code in you get closer to the real update rate of what’s sending data, and save yourself some processing, without impacting performance.

In case of updating the display or the network, sending data too frequently can just not work.
To sum up, it depends.

1 Like