ESP-IDF如何在HTTP视频流长连接中同时收发舵机控制数据

核心问题结论 #

你要的同连接双向读写能力完全可以在ESP-IDF的官方http_server组件上实现，不需要魔改框架，性能和你在Arduino上测的效果一致。

你现在用的官方http_server底层就是基于lwip的全双工socket实现的，只要拿到连接对应的原生socket描述符，就能像Arduino里的WiFiClient.read()/write()一样自由读写，不会被HTTP协议层的逻辑限制。

具体实现步骤 #

• 第一步：在视频流请求的handler里，先正常返回multipart/x-mixed-replace的响应头，不要让http_server自动结束响应，直接进入持续推流的循环。
• 第二步：调用httpd_req_to_sockfd(req)获取当前HTTP连接对应的原生socket文件描述符，把这个socket设置为非阻塞模式，避免读数据时卡住推流流程。
• 第三步：推流循环里每次取帧发送前，先调用recv()从socket读客户端发过来的二进制控制指令，读到就直接解析执行舵机动作；帧数据直接调用send()往socket写，和你之前的推流逻辑完全兼容。

核心参考代码（只保留关键逻辑）：

static esp_err_t video_stream_handler(httpd_req_t *req) {
    // 配置流响应头
    httpd_resp_set_status(req, "200 OK");
    httpd_resp_set_type(req, "multipart/x-mixed-replace;boundary=PART_BOUNDARY");
    httpd_resp_send_chunk(req, NULL, 0); // 先把头发送出去，进入分块传输模式

    // 获取原生socket，设为非阻塞
    int sock = httpd_req_to_sockfd(req);
    int fcntl_flags = fcntl(sock, F_GETFL, 0);
    fcntl(sock, F_SETFL, fcntl_flags | O_NONBLOCK);

    char boundary_buf[64];
    uint8_t cmd_buf[8];
    while (1) {
        // 非阻塞读控制指令，不会卡推流
        int recv_len = recv(sock, cmd_buf, sizeof(cmd_buf), 0);
        if (recv_len > 0) {
            // 解析舵机角度/方向参数，直接改LEDC PWM占空比，不要加延时
            servo_exec_cmd(cmd_buf, recv_len);
        } else if (recv_len == 0 || errno == ECONNRESET) {
            // 客户端断开就退出循环
            break;
        }

        // 正常取帧推流
        camera_fb_t *frame = esp_camera_fb_get();
        if (!frame) continue;

        // 写帧边界头
        size_t header_len = snprintf(boundary_buf, sizeof(boundary_buf),
            "--PART_BOUNDARY\r\nContent-Type: image/jpeg\r\nContent-Length: %u\r\n\r\n",
            frame->len);
        send(sock, boundary_buf, header_len, 0);
        // 写JPEG帧数据
        send(sock, frame->buf, frame->len, 0);
        send(sock, "\r\n", 2, 0);

        esp_camera_fb_return(frame);
        // 单核ESP32喂个看门狗，避免复位
        vTaskDelay(pdMS_TO_TICKS(1));
    }
    return ESP_OK;
}

针对你硬件的优化注意点 #

你用的是带4MB PSRAM的单核ESP32-CAM，按下面的配置做可以把延迟压到最低：

• 舵机PWM不要用软件模拟，直接用ESP32内置的LEDC外设输出，改占空比的操作只有几微秒，完全不会挤占推流的CPU时间。
• 推流和读指令直接用原生send()/recv()，不要频繁调用http_server自带的httpd_resp_send_chunk()接口，这个接口内部有锁和协议层处理，会增加不必要的延迟。
• 非阻塞模式一定要开，不然recv()等不到客户端数据的时候会挂起整个任务，直接造成视频卡顿。

方案选型建议 #

你想的在长连接间隙传控制数据的方案，已经是当前场景下延迟最低的方案：

• 比单独开控制接口的方案少了TCP连接建立、HTTP请求解析的开销，不会出现断流卡顿，舵机指令响应延迟可以稳定在10ms以内。
• 不需要引入WebSocket之类的额外协议，你现在Python写的客户端逻辑几乎不用改，只要在收视频帧的同一个socket里定时发控制字节就行。
• 没必要额外搞多任务传指令，单核设备下任务切换反而会增加开销，直接在推流循环里读指令执行就足够流畅。

内容的提问来源于stack exchange，提问作者Nawal