RK3576 Pull-Up Counter คืออะไร?

Project นี้เปลี่ยน RK3576 Edge Computer ให้กลายเป็นระบบนับ Pull-up แบบ Real-Time

Pipeline เริ่มจาก Video แล้วใช้ YOLO11n Pose ตรวจคนและ Pose Skeleton ก่อนส่งข้อมูล Keypoint ไปยัง Logic สำหรับนับ Rep

ระบบเดียวกัน ถูกใช้ทั้งใน Offline Video Processor และ Web Application จึงไม่ต้องมี Counting Logic คนละชุดระหว่าง Demo กับ Live Camera

ทำไม Project นี้ถึงเป็น Edge AI จริง?

จุดสำคัญคือ Inference อยู่บน RK3576 ไม่ได้ส่ง Video ไปให้ Cloud ช่วยวิเคราะห์

Board ทำงานหลัก:

• Decode Video
• Preprocess Frame
• Run YOLO Pose บน NPU
• Post-process Keypoints
• Update Pull-up State Machine
• วาด Bounding Box และ Skeleton
• Encode JPEG
• ส่ง MJPEG ให้ Browser

Browser จึงเป็นหน้าจอแสดงผล มากกว่าจะเป็น AI Compute Client

Hardware มีน้อย แต่ Input เลือกได้ 3 แบบ

Hardware หลักที่หน้า Project ระบุคือ:

ตัว Application รองรับ Input 3 แบบ:

YOLO11n Pose ทำอะไรให้เรา?

Project ใช้ YOLO11n Pose pretrained model แบบมาตรฐาน โดยไม่ได้ Train เพิ่มสำหรับ Pull-up

Model ทำหน้าที่:

• Detect Person
• คืน Bounding Box
• คืน Detection Confidence
• คืน 17 COCO Pose Keypoints

Keypoint ที่เกี่ยวกับ Counting Logic โดยตรง ได้แก่:

• Nose
• Left Shoulder
• Right Shoulder
• Left Wrist
• Right Wrist

ส่วน Skeleton ที่แสดงบนภาพ ยังประกอบด้วย Elbows, Hips, Knees, Ankles และ Landmark อื่นในชุด COCO Pose

Model Spec สำหรับ RK3576 Deployment

Output ของ Pose Model ประกอบด้วย:

• 4 ค่า Bounding Box
• 1 ค่า Person Confidence
• 17 ชุดของ x, y และ Confidence สำหรับ Keypoint

หลัง Inference Post-processing จะเอา Letterbox Padding ออก ก่อน Map Coordinate กลับไปยังขนาด Frame ต้นฉบับ

ทำไมผู้สร้างเลือก FP16 ก่อน INT8?

เพราะการนับ Pull-up ไม่ได้ต้องการแค่ Detect คนได้ แต่ต้องพึ่ง ตำแหน่ง Keypoint ที่ Stable

ผู้สร้างจึงเริ่ม Deployment ด้วย FP16 เพื่อรักษา Pose Quality ก่อน

INT8 อาจช่วยเรื่องความเร็ว แต่ Source เตือนว่า ควร Calibrate ด้วยภาพ Exercise ที่ใกล้เคียงกับการใช้งานจริง แล้ว Validate ผลลัพธ์เทียบกับ FP16

หัวใจของ Project: YOLO ไม่ได้นับ Pull-up ให้เอง

หลัง YOLO คืน Keypoint ผู้สร้างต้องแปลง Coordinate เหล่านั้นเป็น Logic ของการออกกำลังกาย

ขั้นตอนหลักมี 6 ส่วน:

1. ประมาณตำแหน่งบาร์จากข้อมือ
2. Smooth Bar, Nose และ Shoulder
3. Normalize ระยะด้วย Bounding Box Height
4. ใช้ Nose เป็น Top Signal หลัก
5. สร้าง Top / Bottom Threshold แยกกัน
6. ต้อง Stable หลาย Frame ก่อนเปลี่ยน State

แนวคิดนี้ทำให้ Model กับ Application Logic แยกหน้าที่กันชัดเจน:

ขั้นแรก: ใช้ข้อมือประมาณตำแหน่ง Pull-up Bar

ระบบดูตำแหน่งแนวตั้ง ของ:

• Left Wrist
• Right Wrist

แล้วเฉลี่ยค่าของข้อมือ ที่มองเห็นอยู่ เพื่อ Estimate ตำแหน่งแนวตั้งของ Bar

เหตุผลที่วิธีนี้ใช้ได้กับ Setup นี้ คือระหว่าง Pull-up มือของ Athlete อยู่กับ Bar

Bar Estimate จึงกลายเป็น Reference สำหรับเปรียบเทียบว่า Nose หรือ Shoulder อยู่สูงหรือต่ำกว่าบาร์แค่ไหน

Keypoint สั่นได้ — เลยต้องมี EMA มาช่วย

Pose Keypoint ไม่ได้อยู่ Pixel เดิมนิ่ง ๆ ทุก Frame

แม้คนจะอยู่แทบตำแหน่งเดิม Model ก็อาจคืน Coordinate ขยับเล็กน้อยได้

Project ใช้ Exponential Moving Average เพื่อ Smooth:

• Bar Position
• Nose Position
• Shoulder Position

Current Public GitHub Code ยังแสดงแนวคิดนี้ตรง ๆ: Bar ใช้การ Smooth ที่ช้ากว่า ส่วน Nose / Shoulder ตอบสนองเร็วกว่า

ทำไมไม่ใช้ระยะ Pixel แบบตายตัว?

ถ้าใช้ Threshold แบบ:

“Nose ต้องห่าง Bar ไม่เกิน 40 pixels”

เมื่อ Athlete เดินเข้าใกล้หรือไกลจากกล้อง ขนาดคนในภาพจะเปลี่ยน และ 40 pixels จะไม่ได้แทนสัดส่วนร่างกายเท่าเดิม

Project จึง Normalize ระยะในแนวตั้ง ด้วยความสูงของ Person Bounding Box

ทำให้ Threshold อิงกับสัดส่วนของคนใน Frame มากกว่าจำนวน Pixel ล้วน ๆ

Nose เป็นตัวหลัก แต่ Bar บังหน้าได้

ตำแหน่งบนสุด ใช้ Nose เป็น Signal หลัก

แต่ปัญหาคือ ตอนดึงขึ้นสูง Bar อาจบังบริเวณใบหน้า จน Nose Keypoint หายหรือ Confidence ต่ำ

Project จึงใช้ Shoulder Position เป็น Fallback ในกรณีที่ Nose มองไม่เห็น

Hysteresis ช่วยกันอาการ +1 รัว ๆ ตอนค้างอยู่ด้านบน

ถ้าใช้ Threshold เดียว Keypoint ที่สั่นอยู่ใกล้เส้นตัดสิน อาจเด้ง:

ผ่าน → ไม่ผ่าน → ผ่าน → ไม่ผ่าน

แล้วกลายเป็นนับ Rep ซ้ำ

Project เลยใช้:

• Top Threshold
• Bottom Threshold

แยกจากกัน เพื่อสร้าง Dead Zone ระหว่าง Transition

ใน Public GitHub Code ปัจจุบันใช้:

Top Threshold = 0.08
Bottom Threshold = 0.12

State Machine ทำให้ “Pose” กลายเป็น “Rep”

State หลักที่ Project อธิบายมี:

และมี State สำหรับกรณี NO PERSON

Rep ถูกนับเมื่อไร?

ต้องเริ่มจาก Stable Hanging Position แล้วขึ้นไปถึง Stable Top Position

หลัง Count แล้ว ระบบต้องเห็น Athlete กลับลงสู่ HANG ก่อน ถึงจะอนุญาตให้ Count รอบใหม่

Stable Frame ช่วยอีกชั้น

Public GitHub Revision ปัจจุบัน ใช้:

• 3 Stable Frames ก่อนเข้าสู่ HANG
• 2 Stable Frames ที่ Top ก่อนเพิ่ม Count

นั่นหมายความว่า Frame เดียวที่ Keypoint เด้งผิด จะไม่ทำให้ Counter เปลี่ยน State ทันที

ถ้ามีหลายคนใน Frame ระบบเลือกใคร?

Application เลือก Person ที่มี Detection Confidence สูงที่สุด

จุดประสงค์คือ ลดโอกาสที่ระบบ จะสลับไปนับคนที่เดินผ่านไกล ๆ ใน Scene

Web Architecture: เปิดหลาย Browser แต่ไม่ควรโหลด Model หลายรอบ

Web Application ใช้ Background Thread เพียงหนึ่งตัว เป็นเจ้าของ RKNN Runtime

แนวคิดคือ:

Latest JPEG Frame ถูก Share ไปยัง Client ผ่าน Condition Variable

ส่วนหน้า Web Poll JSON Status Endpoint ประมาณ 2 ครั้งต่อวินาที

เตรียม RK3576 Deployment Package ตาม Hackster

หน้า Hackster อธิบาย Deployment Folder ที่เตรียมสำหรับ RK3576 โดยรวม:

• RKNN Model
• Python Programs
• Test Video
• Launch Scripts
• Integrity Manifest
• Python 3.11 AArch64 Wheels

เป้าหมายของชุดนี้คือ ให้ติดตั้ง Board ได้แบบ Offline โดยไม่ต้องเข้า PyPI

Copy Package ไป Board

ใช้ SCP ส่ง Folder ไปยัง /home/seeed/

Run Offline Installer

Installer จะสร้าง .venv, ติดตั้ง Dependency จาก Wheel ที่ Bundled มา และทดสอบ NPU ด้วยหนึ่ง Frame

ถ้าสำเร็จ Source ระบุว่าควรเห็น:

Environment check: PASS

ตรวจ Integrity

สามารถใช้ MANIFEST.sha256 ตรวจไฟล์หลัง Transfer ได้

เริ่มจาก Offline Video Demo ก่อน Live Camera

Hackster Package มี Test Video และ Script:

run_demo.sh

เมื่อทำงานเสร็จ จะสร้าง:

• video/output/test_counted.mp4
• video/output/test_counted.csv

MP4 เอาไว้ดูภาพ

Output Video มี Bounding Box, Skeleton, State และ Count วาดอยู่บน Frame

CSV เอาไว้ Debug Logic

CSV เก็บข้อมูลราย Frame เช่น:

• Frame Number
• Timestamp
• Rep Count
• Current State
• Person Confidence
• Estimated Bar Position
• Nose Position
• Normalized Nose-to-Bar Distance

Web Dashboard ดูอะไรได้บ้าง?

ตาม Hackster Deployment เมื่อ Start Web Application ให้เปิด:

http://BOARD_IP:8000

จากโทรศัพท์หรือคอมพิวเตอร์ ที่อยู่ Network เดียวกัน

Dashboard แสดง:

• Annotated Live Video
• Repetition Count
• Current State
• Stream Frame Rate
• NPU Inference Latency
• Person Confidence
• Video Progress
• Pause / Resume
• Reset Count

USB Camera

ใช้ Device Index เช่น 0

RTSP Camera

สามารถส่ง RTSP URL เข้าเป็น Source ตาม Command ของ Project

Port 8000 ถูกใช้แล้ว?

ถ้าเจอ:

Address already in use

Source ระบุว่า Service เดิมอาจยังรันอยู่ หรือสามารถเปลี่ยนไปใช้ Port อื่น เช่น 8080

Performance ที่ผู้สร้างวัดได้

Test Environment ที่หน้า Project ระบุ:

• AArch64 Linux
• Python 3.11
• RKNNLite2 2.3.2
• RKNN Runtime 2.3.0
• RKNPU Driver 0.9.8

Public GitHub ปัจจุบันเป็นอีก Package หนึ่ง

Public Repository inteintegrity/yolo-pullup-counter ที่เปิดอยู่ปัจจุบัน มี Main Script:

pullup_counter.py

และ Dependency:

• Ultralytics
• OpenCV
• NumPy

README อธิบายการรันด้วย yolo11n-pose.pt และระบุว่า Default Version รองรับ CPU Inference

ครั้งแรก Ultralytics สามารถ Download Weight ให้โดยอัตโนมัติ ตาม Workflow ใน README

Public README ยังระบุทางเลือก:

• เปลี่ยนเป็น yolo11s-pose.pt เพื่อเพิ่ม Pose Accuracy
• เพิ่ม --imgsz 960 หากคนใน Frame เล็ก
• ปรับ --keypoint-conf ลงเป็น 0.25 หาก Keypoint ไม่ Stable
• เปิด --debug เพื่อดูความสัมพันธ์ Bar / Head

Commands และ Code Snippets จาก Source

เนื่องจาก Source มีทั้ง Hackster RK3576 Package และ Public GitHub Version จึงแยก Command ตามต้นทางให้ชัด

scp -r "Exercise count" seeed@BOARD_IP:/home/seeed/

ssh seeed@BOARD_IP
cd "/home/seeed/Exercise count"
bash install.sh

sha256sum -c MANIFEST.sha256

cd "/home/seeed/Exercise count"
bash run_demo.sh

cd "/home/seeed/Exercise count"
bash run_web.sh

bash run_web.sh --source 0

bash run_web.sh --source 'rtsp://user:password@camera/stream'

bash run_web.sh --port 8080

python -m pip install -r requirements.txt

python pullup_counter.py --source video/input/test.mp4

python pullup_counter.py --source video/input/test.mp4 --debug

top_threshold = 0.08
bottom_threshold = 0.12

ข้อจำกัดที่ต้องรู้ก่อนเอาไปวางใน Gym จริง

1. Threshold ถูก Tune กับกล้องค่อนข้าง Fixed

Source ระบุว่า Setup ปัจจุบัน เน้นกล้องมุม Front-facing ที่ค่อนข้างคงที่

2. Wrist ควรมองเห็นใกล้ Bar

เพราะตำแหน่ง Wrist ถูกใช้ Estimate ตำแหน่ง Pull-up Bar

3. Occlusion มีผลต่อ Stability

ถ้าแขน, หน้า หรือ Landmark ถูกบังหนัก Keypoint อาจไม่ Stable

4. Camera ขยับทำให้ Reference เปลี่ยน

ระบบเหมาะกับกล้อง ที่ติดตั้งค่อนข้างนิ่ง มากกว่ากล้อง Handheld ที่ขยับตลอดเวลา

5. คนเล็กมากใน Frame ทำให้ Pose ยากขึ้น

เมื่อ Athlete กินพื้นที่ภาพน้อยมาก Keypoint Stability สามารถลดลงได้

6. Multi-person ยังไม่ใช่เป้าหมายหลัก

Highest-confidence-person เหมาะกับ Scene ที่มี Athlete หลักเพียงคนเดียว

7. Flask Built-in Server สำหรับ Local Demo

Source ระบุว่า Flask Built-in Server เหมาะกับ Local Demo หากจะนำไป Production ควรใช้ Production WSGI Server และมี Network Access Control ที่เหมาะสม

YOLO ตัวเดิม เปลี่ยน State Machine ก็ไป Exercise อื่นได้

Future Improvement ใน Source เสนอว่า Pose Pipeline เดิม สามารถนำไปใช้กับ:

• Push-up
• Squat
• Sit-up
• Exercise อื่น

สิ่งที่ต้องเปลี่ยนหลัก ๆ คือ Counting State Machine และ Landmark / Threshold ที่ใช้ตัดสินท่านั้น

Source ยังเสนอแนวทางพัฒนา:

• Person Tracking สำหรับ Multi-athlete
• Representative INT8 Calibration Dataset
• User-selectable Exercise Modes
• Session History
• Automatic Camera-angle Calibration

ภาพ System และผลลัพธ์เพิ่มเติม

Hero แสดง Demo หลักทันที ส่วนภาพอื่นจาก Source ถูกซ่อนไว้ใน View more เพื่อลดความยาวหน้า ตอนเปิดบนมือถือ

View more — ดูภาพเพิ่มเติม View less — ซ่อนภาพ

Project นี้ค่อนข้างลึก — Build จริงควรอ่านต้นฉบับควบคู่กัน

โดยเฉพาะเรื่อง:

• RKNN Deployment Package
• Model Conversion
• NPU Runtime Version
• Threshold Tuning
• Camera Angle
• Web Server Deployment
• Public GitHub vs Hackster Package

FAQ: RK3576 YOLO Pull-Up Counter

บทเรียนจาก Project นี้: AI เห็น Pose แต่ Application ต้องเข้าใจเวลา

ถ้ามองแค่ Screenshot อาจรู้สึกว่าเป็น “YOLO ดูคนแล้วนับ 1, 2, 3”

แต่พอแกะ Architecture จริง จะเห็นว่ามีหลายชั้น:

Camera → YOLO Pose → Keypoints → Smoothing → Normalization → Hysteresis → State Machine → Rep Count

YOLO เป็นเพียงส่วนหนึ่งของระบบ

สิ่งที่ทำให้ Counter ใช้งานได้จริงขึ้น คือการเอา Pose Landmark ไปเชื่อมกับ Temporal Logic เพื่อเข้าใจว่า Athlete เริ่มจากตรงไหน, ขึ้นถึงไหน และกลับลงมาแล้วหรือยัง

นี่จึงเป็นตัวอย่างที่ดีมาก สำหรับ Maker ที่อยากขยับจาก “ลองรัน AI Model” ไปสู่ “สร้าง Application จากผลของ AI”

References / แหล่งข้อมูลต้นฉบับ

• Hackster — Real-Time Pull-Up Counter on RK3576 with YOLO Pose
• GitHub — inteintegrity/yolo-pullup-counter