William Zhang2025-07-23

Détection de chutes multi-scénarios basée sur reComputer RK3576

Détection des comportements de chute dans des scénarios multiples et pour plusieurs cibles à l'aide du modèle YOLOv8n-pose, accélération de l'inférence via reComputer RK3576, et retour d'informations simple via une page Web.

reComputer-RKrk3576yolofall_detectionGithub

Détection de chutes multi-scénarios sur reComputer RK3576

Un projet de détection de chutes basé sur RK3576 / RKNN / YOLO / RGA

Vous pouvez consulter le code source de ce projet à l'adresse: https://github.com/doublelf/fall_detection

Démarrage rapide

Récupérer l'image du projet via Docker

bash
docker pull ghcr.io/doublelf/pose_optimized:v1

Tester le modèle avec l'exemple intégré

bash
sudo docker run --rm --privileged --net=host \
  -e PYTHONUNBUFFERED=1 \
  -e RKNN_LOG_LEVEL=0 \
  --device /dev/video1:/dev/video1 \
  --device /dev/dri/renderD129:/dev/dri/renderD129 \
  -v /proc/device-tree/compatible:/proc/device-tree/compatible \
  -v $(pwd)/video:/app/video \
  seeed/pose_optimized:local \
  python3 web_detection.py --model_path model/yolov8n_pose.rknn --video video/example1.mp4

Où "-v $(pwd)/video:/app/video" mappe le dossier video local vers l'emplacement /app/video dans l'image.

Si vous souhaitez utiliser une vidéo locale pour l'inférence, stockez le fichier local dans le dossier spécifié par $(pwd)/video.

Une fois le projet exécuté avec succès, accédez à http://<board_ip>:8000/ pour voir l'inférence en temps réel.

Développement secondaire basé sur le projet

Récupérer l'image sur la machine locale à l'aide de la commande cp

bash
sudo docker cp pose_optimized:/app/web_detection.py ./

Après avoir modifié le code de web_detection.py, pensez à reconstruire le code local dans l'image

bash
sudo docker build -t seeed/pose_optimized:local

Puis relancez-le.

Utilisation de la caméra pour l'inférence en temps réel

Lors de l'inférence, remplacez le paramètre "--video" par "--camera_id" pour invoquer la caméra.

bash
sudo docker run --rm --privileged --net=host \
  -e PYTHONUNBUFFERED=1 \
  -e RKNN_LOG_LEVEL=0 \
  --device /dev/video1:/dev/video1 \
  --device /dev/dri/renderD129:/dev/dri/renderD129 \
  -v /proc/device-tree/compatible:/proc/device-tree/compatible \
  -v $(pwd)/video:/app/video \
  seeed/pose_optimized:local \
  python3 web_detection.py --model_path model/yolov8n_pose.rknn --camera_id 1

Ici, "--camera_id" est lié au périphérique que vous avez spécifié dans "--device /dev/video1:/dev/video1".

Extensions d'inférence IA

Moteur d'inférence: Encapsulé à partir de l'API RKNN C, avec le point d'entrée principal dans web_detection.py et des appels réels à utils/rknn_wrapper.py, prenant en charge l'accélération matérielle NPU RK3576. Entrée du modèle: Accepte le modèle quantifié yolov8n_pose.rknn avec une taille d'entrée fixe de 640×640. La sortie comprend des boîtes de détection d'objets et 17 coordonnées de points clés. Post-traitement: Analyse les trois cartes de caractéristiques issues de la sortie du modèle, supprime les boîtes dupliquées via NMS et utilise l'algorithme OKS pour optimiser la confiance des points clés, générant finalement des données de pose structurées.

Prétraitement et traitement d'image

Accélération matérielle: Utilise l'unité RGA du RK3576 pour le redimensionnement d'image, la conversion d'espace colorimétrique (YUV→RGB) et la conversion de format, réduisant considérablement la charge CPU. Capture vidéo: Prend en charge la capture directe depuis des caméras V4L2 ou la lecture de fichiers vidéo locaux, en changeant la source d'entrée via les paramètres --camera_id et --video. Contrôle de la fréquence d'images: Le thread de capture et le thread d'inférence sont séparés, utilisant une file d'attente à double tampon pour éviter les pertes d'images et garantir une latence minimale pour les flux en temps réel.

Recommandations de déploiement

Permissions d'exécution: Le mode conteneur --privileged doit être utilisé, avec un mappage explicite de /dev/video*, /dev/dri/renderD* (pour RGA) et du fichier de compatibilité de l'arborescence des périphériques, afin de garantir un accès normal au NPU et au VPU. Empaquetage de l'image: L'image inclut déjà toutes les dépendances (RKNN Runtime, OpenCV, Flask). Il est recommandé d'utiliser --net=host pour éviter la complexité du mappage de ports. Si vous devez conserver des modèles ou des configurations, vous pouvez monter des répertoires externes. Fonctionnement de longue durée: Il est recommandé d'utiliser un service systemd ou supervisor pour surveiller le processus du conteneur, et de définir la politique --restart=always.

Limitations connues

Inférence à flux unique: La conception actuelle ne prend en charge qu'un seul flux vidéo en entrée. La concurrence multi-flux nécessite le développement supplémentaire d'une logique de gestion multithread/multiprocessus. Surcharge de rendu: Bien que RGA accélère le prétraitement, les opérations de dessin d'OpenCV consomment encore des ressources CPU. À haute résolution, la fréquence d'images peut chuter à 15-20 FPS. Prise en charge des flux réseau: Prend actuellement en charge uniquement les caméras ou fichiers locaux ; la récupération de flux réseau RTSP/HTTP n'est pas encore intégrée. Absence de cache persistant: Les résultats de détection ne sont utilisés que pour l'affichage en temps réel et ne sont pas stockés dans une base de données ou un système de fichiers. Les enregistrements historiques nécessitent des extensions personnalisées. Compatibilité matérielle: L'accélération RGA dépend de pilotes spécifiques au RK3576. D'autres puces de la série RK (comme le RK3568) peuvent ne pas fonctionner directement et peuvent nécessiter la recompilation d'OpenCV et l'ajustement de l'interface d'appel RGA.