CPX Stalls

Discussions about the AI-deck
whoenig
Expert
Posts: 395
Joined: Mon Oct 27, 2014 2:55 am

CPX Stalls

Post by whoenig »

I am using the latest aideck-esp-firmware, aideck-gap8-examples (with the wifi_jpeg_streamer), and crazyflie-firmware (i.e., all main/master branches). So far the demo works fine, and I get about 10fps when using opencv-viewer.py.

However, once I add a very simple functionality in the crazyflie-firmware app layer to send some data STM32 -> GAP8, I observe communication stalls for WiFi. In particular, the frame rate is initially also 10fps and quickly (after 10sec) drops to 0.1 fps. If I enable UART logging on the ESP32

Code: Select all

    esp_log_level_set("ROUTER", ESP_LOG_DEBUG);
the issue magically disappears (but the framerate also drops to about 2fps). To me it seems like an issue with either flow control or even buffer sizes (my StatePacket_t is small, about 19 Bytes). Increasing the RX Buffer on the GAP8 (from 5 to 20) does not help. Reducing the TASK_FREQ from 10 to 1 helps (but the bandwidth should be sufficient to handle a frequency of at least 10 Hz).

Any thoughts?

Code: Select all

#define TASK_FREQ 10

typedef struct
{
    // some data
} __attribute__((packed)) StatePacket_t;
// static StatePacket_t cf_state;

static CPXPacket_t cpx_packet;

void appMain()
{
    uint32_t lastWakeTime;

    //Wait for the system to be fully started to start stabilization loop
    systemWaitStart();

    cpxInitRoute(CPX_T_STM32, CPX_T_GAP8, CPX_F_APP, &cpx_packet.route);
    cpx_packet.dataLength = sizeof(StatePacket_t);
    StatePacket_t* state_packet = (StatePacket_t*)&cpx_packet.data;

    vTaskDelay(10000); // wait until WiFi is connected

    lastWakeTime = xTaskGetTickCount();
    while (1)
    {
        vTaskDelayUntil(&lastWakeTime, F2T(TASK_FREQ));

        // Updating state data
        // ...
        
        cpxSendPacket(&cpx_packet, /*timeout*/ 10 /* ms */);
    }
}
marcus
Bitcraze
Posts: 659
Joined: Mon Jan 28, 2013 7:02 pm
Location: Sweden
Contact:

Re: CPX Stalls

Post by marcus »

Thanks for reporting this. We haven't tested this use-case yet, but I'll try to get the time to do it so we can debug it.
whoenig
Expert
Posts: 395
Joined: Mon Oct 27, 2014 2:55 am

Re: CPX Stalls

Post by whoenig »

I tried again with the latest main/master, since there were lots of CPX changes recently. Unfortunately, I still have the same problems. If you need the detailed code:
https://github.com/IMRCLab/aideck-gap8- ... tree/cvmrs and https://github.com/IMRCLab/crazyflie-fi ... tree/cvmrs.
marcus
Bitcraze
Posts: 659
Joined: Mon Jan 28, 2013 7:02 pm
Location: Sweden
Contact:

Re: CPX Stalls

Post by marcus »

Thanks for the code. I've started implementing some load testing, but it's not good enough yet, so having a way to trigger this is good.
marcus
Bitcraze
Posts: 659
Joined: Mon Jan 28, 2013 7:02 pm
Location: Sweden
Contact:

Re: CPX Stalls

Post by marcus »

I've tested this and it doesn't slow down over time, do I need to do anything to trigger it? Does this output look ok?

Code: Select all

0.17729340449672598
5.6403677442973725
Resolution is 324x324 with depth of 1 byte(s)
Image format is 0
Image size is 104976 bytes
CF State 0.0,0.0,0.0 m at time 0.08 s
marcus
Bitcraze
Posts: 659
Joined: Mon Jan 28, 2013 7:02 pm
Location: Sweden
Contact:

Re: CPX Stalls

Post by marcus »

Ah, I missed the app part...
marcus
Bitcraze
Posts: 659
Joined: Mon Jan 28, 2013 7:02 pm
Location: Sweden
Contact:

Re: CPX Stalls

Post by marcus »

I can reproduce it, thanks for the firmware! I'll try to dig a bit and see what I can find.
whoenig
Expert
Posts: 395
Joined: Mon Oct 27, 2014 2:55 am

Re: CPX Stalls

Post by whoenig »

Awesome - thanks!

In my experiments it didn't matter if the GAP8 had a "sink" for the messages or not. The issue goes away when sending data with 1Hz in the STM32 app. Of course, ideally we would like to send with 20 to 100 Hz (depending on how fast the motion is).
marcus
Bitcraze
Posts: 659
Joined: Mon Jan 28, 2013 7:02 pm
Location: Sweden
Contact:

Re: CPX Stalls

Post by marcus »

I finally got some time to look at this and it seems to be caused by the WiFi not sending data fast enough. No idea why sending the data via UART effects this, I'm still digging around. But it seems as if it got much better by increasing the priority of the WiFi sending task. If you want to test edit the ESP32 firmware file wifi.c. Close to the end of the file you should edit the priority for the sending task from 1 to 2.

Code: Select all

xTaskCreate(wifi_sending_task, "WiFi TX", 5000, NULL, 2, NULL);
I created an issue for this on Github (link)

To be continued..
marcus
Bitcraze
Posts: 659
Joined: Mon Jan 28, 2013 7:02 pm
Location: Sweden
Contact:

Re: CPX Stalls

Post by marcus »

After some more digging there seems to be another issue as well, the priority improves it but there's some other unknown problem.
Post Reply