Détection de chute multi-scénario basée sur reComputer RK3576

Un projet de détection de chute 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érez l'image du projet via Docker

bash

docker pull ghcr.io/doublelf/pose_optimized:v1

Testez l'effet du modèle à l'aide de 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 vidéo local vers l'emplacement /app/video dans l'image.

Si vous souhaitez utiliser une vidéo locale pour l'inférence, placez 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'effet d'inférence en temps réel.

Développement secondaire basé sur le projet

Récupérez 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 web_detection.py, n'oubliez pas de reconstruire le code local dans l'image

bash

sudo docker build -t seeed/pose_optimized:local

Exécutez-le ensuite à nouveau.

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

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

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 de l'inférence IA

Moteur d'inférence : Enveloppé autour de l'API C RKNN, avec l'entrée principale dans web_detection.py et les appels réels vers utils/rknn_wrapper.py, prenant en charge l'accélération matérielle NPU du 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 les boîtes de détection d'objets et 17 coordonnées de points clés. Post-traitement : Analyse les trois cartes de caractéristiques de la sortie du modèle, supprime les boîtes en double 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 la mise à l'échelle d'image, la conversion d'espace colorimétrique (YUV→RGB) et la conversion de format, réduisant considérablement la charge du CPU. Capture vidéo : Prend en charge la capture directe depuis des caméras V4L2 ou la lecture de fichiers vidéo locaux, en commutant les sources 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 : Doit utiliser le mode conteneur --privileged et mapper explicitement /dev/video*, /dev/dri/renderD* (pour RGA), ainsi que le fichier de compatibilité device tree pour 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 à long terme : 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 un développement supplémentaire de la logique de gestion multi-thread/multi-processus. Surcharge de rendu : Bien que RGA accélère le prétraitement, les opérations de dessin d'OpenCV consomment encore une partie des ressources CPU. À haute résolution, la fréquence d'images peut chuter à 15-20 FPS. Prise en charge des flux réseau : Actuellement, seules les caméras ou fichiers locaux sont pris en charge ; la récupération de flux réseau RTSP/HTTP n'est pas encore intégrée. Pas de mise en cache persistante : Les résultats de détection sont uniquement utilisés 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. Les autres puces de la série RK (comme le RK3568) peuvent ne pas fonctionner directement et pourraient nécessiter une recompilation d'OpenCV et un ajustement de l'interface d'appel RGA.