פיתוח אפליקציות מובייל לשליטה ברובוטים

מהנדס עומד בפני האתגר של שליטה מרחוק ברובוט באמצעות מכשיר נייד עם זמן השהיה מתחת ל-100 אלפיות השנייה. בחירת פרוטוקול העברת הנתונים קובעת את מהירות התגובה, הבטיחות ועלות הפיתוח. ארכיטקטורה שגויה עלולה להוביל לאובדן חיבור ולתאונות. אנו מתמחים בפיתוח אפליקציות לשליטה ברובוטים — מ-AGVs ועד זרועות שיתופיות. במשך יותר מ-5 שנים, סיפקנו יותר מ-15 פרויקטים, והשגנו זמני השהיה מתחת ל-100 אלפיות השנייה אפילו על LTE.

באיזה פרוטוקול כדאי לבחור לזמן השהיה מינימלי?

בחירת שכבת התעבורה קובעת את זמן ההשהיה, האמינות ומורכבות הפיתוח. בניסיון שלנו, אנו משתמשים בשלושה פרוטוקולים עיקריים:

UDP מספק זמן השהיה נמוך פי 10 מ-MQTT אך אינו מבטיח מסירה — זהו יתרון בתרחישי זמן אמת שבהם פקודה חדשה חשובה יותר מאמינות. MQTT עם QoS 1 אמין יותר אך מוסיף תקורה. עבור רובוטי ROS, WebSocket דרך rosbridge הוא אופטימלי, אם כי סריאליזציית JSON יכולה להפוך לצוואר בקבוק בתדירויות גבוהות (לפי תיעוד rosbridge_protocol הרשמי).

מדוע watchdog הוא חובה?

תרחיש קריטי הוא אובדן חיבור. ללא הגנה, הרובוט עלול להמשיך לנוע, דבר המסוכן. אנו מיישמים watchdog בשלבים:

1. על הרובוט, הפעל טיימר של 1–2 שניות.
2. אם לא מתקבלת פקודה בתוך זמן זה, הרובוט עובר ל-safe_stop (עצירת כל המנועים) או שומר על מיקום.
3. הטלפון מציג את מצב החיבור ומתחבר מחדש אוטומטית עם מחוון איכות שירות.

בנוסף, אנו משתמשים באימות PIN/QR כדי למנוע שליטה ברובוט אחר.

כיצד להפחית את זמן ההשהיה של הזרמת הווידאו?

עבור זרמי H.264 ממצלמות IP על הרובוט, אנו משתמשים ב-ExoPlayer (אנדרואיד) או AVPlayer עם HLS (iOS). זמן ההשהיה של HLS הוא 5–30 שניות, דבר שאינו מקובל לשליטה. הגישה הנכונה היא WebRTC (זמן השהיה < 200 אלפיות השנייה) או RTSP דרך LibVLC/ffmpeg בצינור MediaCodec (זמן השהיה 100–300 אלפיות השנייה).

WebRTC מורכב יותר להקמה אך מציע את זמן ההשהיה הנמוך ביותר וקצב סיביות אדפטיבי. לשליטה מקומית (Wi-Fi), RTSP מספק איזון אופטימלי.

תעבורה ופרוטוקולים (בפירוט)

ROS 2 + rosbridge (WebSocket)

המחסנית הנפוצה ביותר לרובוטי ROS: על הרובוט, rosbridge_server מופעל; הטלפון מתחבר דרך WebSocket ומפרסם/נרשם לנושאים באמצעות פרוטוקול JSON rosbridge_protocol. עבור לקוחות ניידים, קיימים עטיפות תואמות roslibjs, אך עבור אנדרואיד/iOS מקוריים אנו כותבים את הלקוח בעצמנו — זהו 300–400 שורות קוד עם חיבור מחדש ותור הודעות.

בעיה: rosbridge הוא JSON על WebSocket, דבר איטי לנושאים בתדירות גבוהה. נושא /cmd_vel עם פקודות Twist ב-20 הרץ מייצר כ-40 kbps של תעבורה. אם הרובוט על Wi-Fi עם תפוקה אמיתית של 1 Mbps, זה בסדר. אם על LTE עם jitter, חבילות מגיעות בפרצים, מה שגורם לעיכוב בביצוע פקודות. פתרון: הפחתת תדירות הפקודות ל-10 הרץ והוספת watchdog — אם אין פקודה מהטלפון במשך 500 אלפיות השנייה, הרובוט עובר ל-safe_stop.

MQTT לשליטה קלה

עבור רובוטי IoT ללא ROS (AGVs, ממיינים, פלטפורמות מותאמות) — ברוקר MQTT (Mosquitto או EMQ X) בתוספת פרוטוקול פקודות קל. הטלפון מפרסם ל-robot/{id}/cmd, הרובוט נרשם לנושא זה. טלמטריה הולכת בכיוון ההפוך: robot/{id}/state, robot/{id}/battery. אנו משתמשים ב-MQTT עם QoS 1 (לפחות פעם אחת) לפקודות שליטה — QoS 0 מאבד חבילות על Wi-Fi לא יציב, QoS 2 יוצר סבבים נוספים. הודעת retained עבור robot/{id}/state מאפשרת ללקוח חדש לקבל מיד את המצב הנוכחי מבלי לחכות לעדכון הבא.

UDP לזמן אמת (< 50 אלפיות השנייה)

אם נדרש זמן השהיה מינימלי, השתמש ב-socket UDP ישיר על יציאת השליטה. באנדרואיד: DatagramSocket ב-CoroutineScope(Dispatchers.IO), שליחה כל 50 אלפיות השנייה. אין הבטחות מסירה — זהו יתרון: פקודות ישנות אינן חוסמות חדשות בתור. משמש לשליטה בזרועות שבהן זמן השהיה של פקודה חשוב יותר מהבטחת מסירה.

robot/{id}/cmd — команды управления (velocity, gripper)
robot/{id}/state — телеметрия (position, battery)
robot/{id}/video — метаданные потока (URL, кодек)

ארכיטקטורת לקוח נייד

class RobotControlViewModel(
    private val robotRepository: RobotRepository
) : ViewModel() {
    private val _robotState = MutableStateFlow<RobotState>(RobotState.Disconnected)
    val robotState: StateFlow<RobotState> = _robotState

    fun sendVelocityCommand(linear: Float, angular: Float) {
        viewModelScope.launch {
            robotRepository.publishVelocity(
                TwistCommand(
                    linear = linear,
                    angular = angular
                )
            )
        }
    }

    fun connect(robotIp: String) {
        viewModelScope.launch {
            robotRepository.connect(robotIp)
                .onEach { state -> _robotState.value = state }
                .launchIn(this)
        }
    }
}

robot/{id}/cmd — команды управления (velocity, gripper) robot/{id}/state — телеметрия (position, battery) robot/{id}/video — метаданные потока (URL, кодек) מכיל את שכבת התעבורה הספציפית — WebSocket, MQTT או UDP. שינוי שכבת התעבורה אינו משפיע על ViewModel או על ממשק המשתמש. זה קריטי: בפרויקטים אמיתיים, החומרה או הפרוטוקול משתנים לעתים קרובות בין אב טיפוס לייצור.

ג'ויסטיק וירטואלי וטיפול בקלט

class RobotControlViewModel( private val robotRepository: RobotRepository ) : ViewModel() { private val _robotState = MutableStateFlow<RobotState>(RobotState.Disconnected) val robotState: StateFlow<RobotState> = _robotState fun sendVelocityCommand(linear: Float, angular: Float) { viewModelScope.launch { robotRepository.publishVelocity( TwistCommand(linear = linear, angular = angular) ) } } fun connect(robotIp: String) { viewModelScope.launch { robotRepository.connect(robotIp) .onEach { state -> _robotState.value = state } .launchIn(this) } } } מופעל עד 60 פעמים בשנייה במהלך תנועת אצבע מהירה. שליחת פקודה על כל אירוע מעמיסה על הערוץ. אנו משתמשים ב-RobotRepository מ-Kotlin Coroutines Flow — הוא לוקח את הערך העדכני ביותר בתוך חלון של 50 אלפיות השנייה. ערכים ישנים ובינוניים נזרקים, וזמן תגובת ההשהיה נשאר מתחת ל-50 אלפיות השנייה.

אזור מת במרכז הג'ויסטיק: אנו מסננים 10–15% מהרדיוס לאפס. ללא זאת, רעידות מיקרו גורמות לפקודות מהירות נמוכה קבועות, מה שגורם לרובוט "לקפוץ" במנוחה.

מה כלול בפיתוח?

אנו מספקים חבילת שירות מלאה:

• עיצוב ארכיטקטורת פרוטוקול (בחירת שכבת תעבורה, סכימת פקודות)
• פיתוח אפליקציה ניידת מקורית לאנדרואיד ו/או iOS
• שילוב הזרמת וידאו דרך WebRTC או RTSP
• פיתוח תרחישי watchdog ושחזור חירום
• בדיקות על רובוט אמיתי בתנאים קרובים לתפעול
• תיעוד טכני והדרכת מפעילים

לוחות זמנים

לקוח בסיסי עם ג'ויסטיק, טלמטריה והזרמת וידאו בפלטפורמה אחת — 3–5 שבועות. פתרון חוצה פלטפורמות התומך במספר פרוטוקולים, מפת מתקן ומשימות אוטונומיות — 2–4 חודשים. לוחות זמנים מדויקים נקבעים לאחר ניתוח פלטפורמת הרובוט ודרישות זמן ההשהיה.

אנו נעריך את הפרויקט שלך ונציע פתרון אופטימלי. קבל ייעוץ על ארכיטקטורת פרוטוקול. צור קשר לדיון מפורט.