COTS FPV כפלטפורמת R&D: מה לבדוק לפני הזמנה

השאלה מגיעה בצורות שונות, אבל התוכן זהה: "יש לנו קונספט לבחון, צריכים פלטפורמה לטיסות ניסוי, מה לוקחים?" הצוות בדרך כלל מסתכל על שלוש אפשרויות: לבנות מאפס (חודשים עד שנים), לרכוש פלטפורמה צבאית מאושרת (ITAR, תקציב של מיליונים, לוחות זמנים של רכש ממשלתי), או COTS. רוב הצוותות שאני פוגש בוחרים COTS לשלב ה-Proof-of-Concept. זה המאמר שמסביר למה זה הגיוני, מה הסיכונים, ומה לבדוק לפני שמוציאים הזמנה.

מה זה COTS ולמה זה רלוונטי ל-R&D

COTS, Commercial Off-The-Shelf, הוא מונח שמתאר רכיבים או מערכות שנמכרות לשוק הכללי, לא מיוצרות לדרישות ספציפיות של לקוח. ההבחנה המעשית: COTS לא עובר MIL-SPEC, לא בנוי לדרישות גריסה צבאית, ולרוב לא מסומן לאישורי ייצוא ספציפיים.

אז למה מחלקות R&D ביטחוניות משתמשות בו? כי שלב ה-Proof-of-Concept לרוב לא דורש MIL-SPEC. הדרישה היא לבחון אם הרעיון עובד, לאמת אלגוריתם, לבדוק אינטגרציה בין מערכות. לעשות את זה על פלטפורמה שעלתה מיליון שקל וממתינה חצי שנה בין כל ניסוי היא בזבוז. COTS מאפשר לזוז מהר.

דוגמאות לרכיבים COTS שמשמשים בפרויקטי R&D בפועל: DJI O4 Pro Air Unit כמערכת וידאו, SpeedyBee F405 V3 ו-Matek H743 כ-Flight Controllers, T-Motor F90, XING, ו-EMAX מנועים, GNB סוללות LiPo, iFlight ו-TBS שלדות. אלה לא רכיבי MIL-SPEC, אבל הם מוכחים בקטגוריה, מתועדים היטב, וזמינים בפחות מחודש.

שלושה יתרונות עיקריים של COTS לפרויקטי R&D

Iteration cycle מהיר

זה היתרון שלא מדברים עליו מספיק בשיחות הרכש. כשבוחנים קונספט, הניסוי הראשון כמעט תמיד חושף משהו שדורש שינוי. אם כל שינוי ב-spec מחייב מחזור רכש של חצי שנה, הפרויקט מת לפני שהתחיל.

COTS מאפשר תצוגה אחרת לחלוטין: רכיב ספציפי לא מתאים? מזמינים גרסה אחרת ב-2-4 שבועות. פרמטר הכוח צריך עדכון? מחליפים מנוע. ה-iteration cycle הקצר הוא מה שמאפשר לצוות לבחון חמש גרסאות שונות תוך הזמן שבו פלטפורמה רגולרית עוברת אישור ראשוני.

עלות נמוכה לפרוטוטייפ

לבחון חמש גרסאות שונות של פלטפורמת FPV עם COTS עולה עשרות אחוזים ממחיר גרסה אחת של פלטפורמה צבאית מאושרת. זה לא רק שאלת תקציב. זה שאלת כמה ניסויים אפשר לבצע בטרם מחליטים על ה-spec הסופי. ב-R&D, מספר האיטרציות הוא לעיתים קרובות הגורם שקובע אם פרויקט מצליח.

קהילת תיעוד עצומה

Betaflight, INAV ו-ArduPilot (ראו את המאמר המלא על השוואת Firmware) מגובים בקהילות פיתוח גדולות עם תיעוד פומבי: GitHub, forums, Discord, wiki. כשמהנדס נתקל בבעיה עם FC ספציפי, התשובה בדרך כלל כבר קיימת במקום כלשהו. אין NDA שחוסם גישה לתיעוד, אין tech support שעובד בשעות מוגבלות, אין "פנו לנציג האזורי".

עבור צוות R&D שעמוד בלחץ לוחות זמנים, זה הבדל מהותי.

שלושה סיכונים שחייבים להבין מראש

Supply chain volatility

יצרני COTS לא מחויבים להודיע לכם על שינויים ב-BOM, ה-Bill of Materials, שלהם. FC שהזמנתם בגרסה ראשונה עלול להגיע בגרסה שנייה עם שבב אחר, bus שונה, או firmware אחר כברירת מחדל. אם הפרויקט נסמך על consistency בין יחידות לצרכי ניסוי, זה בעיה אמיתית.

הפתרון: או לעבוד מול ספק שמתחייב על BOM קפוא לאורך הפרויקט, או לרכוש batch שלמה מראש. ראו גם את ההשוואה בין custom build ל-BNF, שם מוסבר בפירוט למה consistency של BOM קריטית לניסויים.

ITAR, EAR, ומגבלות ייצוא

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

מה שכן אפשר לומר בצורה כללית: לא כל COTS הוא "חופשי" לייצוא. רכיבים אמריקאים עשויים להיות בפיקוח ה-EAR (Export Administration Regulations). מערכות שנבנו מרכיבים COTS עלולות להיות מוגדרות כ-ITAR-controlled בגלל מטרת השימוש שלהן, גם אם הרכיבים עצמם מסחריים. כלל ה-"see-through" ב-ITAR אומר שאם רכיב בודד מבוקר, המערכת כולה עלולה להפוך ITAR-controlled.

למי שמפתח מערכות שיוצאות מישראל לשותפים בחו"ל, גם אם לשותפים ידידותיים: בדקו מראש, לא בדיעבד.

לא בנוי לסביבות קיצון

MIL-STD-810 מגדיר תנאי ויברציה, חום, לחות, מלח, גובה ועוד. COTS לא מסומן כעומד בתקן הזה. לשלב ה-R&D, שרוב הניסויים נעשים בתנאים מבוקרים, זה לרוב לא מגביל. אבל אם הפרויקט מתכנן יציאה לניסויי שטח בתנאים קיצוניים (מדבר, ים, קור קיצוני), צריך להתחשב בזה מראש.

הפתרון בדרך כלל הוא שיריון ותיעום מנוקד, לא החלפת הפלטפורמה בשלב ה-R&D. אבל לדעת מה הציפיות מהפלטפורמה לפני שמזמינים.

צ'קליסט טכני לפני הזמנה

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

Payload capacity

מה המשקל הנטו של ה-payload שלכם, כולל מארז, כבלים וחיבורים? עבדו אחורה מ-thrust-to-weight ratio של 1.8 לפחות אחרי הוספת הפיילוד. פלטפורמה שנבנתה ל-AUW של 600 גרם עם פיילוד של 250 גרם על גבה תטוס, אבל לא תיתן זמן טיסה שימושי ותתקשה להתמודד עם רוח.

Flight time עם payload

הזמן הנקוב על ידי הספק הוא בלי פיילוד, בתנאי אוויר אידיאליים. עם פיילוד של 200 גרם, הזמן יקטן ב-30-50% בהתאם לפלטפורמה. בקשו נתוני מדידה בפועל או חשבו בעצמכם לפי נוסחת thrust ועומס.

Control link

ELRS, Crossfire, או TBS? באיזה תדר הם פועלים, ובאיזה הספק? האם התדר ומהות הקישור עומדים בדרישות הסביבה שלכם? גם לבדוק תאימות למודל ה-GCS שלכם אם יש.

Video link

DJI O4, Walksnail Avatar, HDZero, או אנלוגי? כל מערכת שונה ב-latency, טווח, ורגישות ל-jamming. DJI O4 Pro Air Unit נותנת latency נמוך ותמונה איכותית, אבל יש לה data stream שעובר דרך שרתי DJI בניתוח מסוים של השיטות. לפרויקטים עם דרישות תקשורת מוגבלות, אנלוג או Walksnail עשויים להיות מתאימים יותר. [צריך אישור מיעקב לגבי אם יש לו עמדה מוגדרת לפרויקטי R&D לגבי DJI vs. אנלוג]

Frequency band

2.4GHz ו-5.8GHz מותרים בישראל לשימוש כללי בהספקים מוגבלים (בהתאם לתקנות משרד התקשורת). 900MHz ו-433MHz דורשים בדיקה מול הרשות הרלוונטית לגבי אישורי שימוש. לפני בחירת band, ודאו שהפעולה בשטח המתוכנן אינה מחייבת אישור נוסף. [מומלץ לאמת ישירות מול אתר משרד התקשורת לפני שימוש ב-900MHz/433MHz]

Firmware support

Betaflight, INAV, או ArduPilot? הבחירה קריטית לפרויקט. אם צריך GPS waypoints ו-mission planning בסיסי, INAV. אם צריך MAVLink, אינטגרציה עם GCS חיצוני, ו-full mission control, ArduPilot. כל firmware דורש חומרה מותאמת. לא כל FC עובד עם כל firmware.

MAVLink

האם הפלטפורמה תומכת ב-MAVLink? זה נדרש לכל אינטגרציה רצינית עם Ground Control Station חיצוני. ArduPilot תומך ב-MAVLink מלא, INAV תומך חלקית, Betaflight כמעט בלא. אם GCS חיצוני הוא חלק מהפרויקט, בדקו שהפלטפורמה ו-firmware תומכים ב-MAVLink לפני שמבנים סביב ה-spec.

Telemetry bandwidth

כמה bytes/sec של telemetry הפלטפורמה יכולה לשדר? האם זה מספיק לחיישנים שאתם מתכננים להוסיף? FC שמריץ ArduPilot עם MAVLink ו-GPS + IMU + חיישנים נוספים שולח כמות גדולה של data. ה-radio link חייב לתמוך בזה.

Mounting options

מה אפשרויות ה-mounting החיצוניות? screw holes, rails, standoffs? האם יש payload mount ייעודי? פלטפורמות COTS סטנדרטיות לרוב לא כוללות payload mount. תצטרכו לתכנן ולהוסיף אחד. ודאו שיש מקום פיזי, שהאיזון לא נפגע, ושיש גישה נוחה לחיווט.

BOM availability

האם הספק יכול לתת את ה-BOM המלא? לא רק "מה רכיבי הקידוד הראשי" אלא כל רכיב: FC, ESC, מנועים עם גרסה מדויקת, סוללות, מקלט, VTX. בלי BOM מלא אי אפשר לתחזק, לשחזר, או לתעד לרגולציה. ספק שמסרב לתת BOM הוא דגל אדום.

Lead time

1-3 שבועות הוא lead time סביר לרכיבים. חודשיים זה דגל אדום שמעיד על בעיית מלאי או תלות ביצרן שאינו בשליטה. לפרויקטי R&D עם לוחות זמנים, lead time של רכיב חלופי הוא פרמטר קריטי.

שש שאלות שחייבים לשאול את הספק

האם תוכל לחתום על NDA לפני שיחת ה-spec?

לפרויקטים עם מידע רגיש, זה שאלת פתיחה. ספק COTS שעובד עם חברות ביטחוניות צריך להיות רגיל לבקשה הזו.

מה ה-warranty על הבנייה וכמה זמן?

בנייה ממוינת ב-30 יום מסירה הוא סטנדרט סביר. שאלו מה כלול: רק עבודת הרכבה, או גם כיוון PID ו-firmware setup?

האם תוכל לתת BOM מלא כחלק מהמסירה?

לא כשאלה לנוחות, כשאלה שמסננת ספקים. מי שלא יכול לתת BOM מלא לא מתאים לפרויקט R&D שדורש תיעוד.

איזה firmware מותקן, ואתה תומך ב-flash לפירמוור אחר?

אם הפרויקט דורש ArduPilot ואתם מקבלים FC עם Betaflight, צריך לדעת מראש אם ה-FC נתמך ב-ArduPilot ומי עושה את ה-flashing.

מה זמן האספקה ליחידה אחת? לסדרה של עשר?

שאלה שחושפת את המגבלות האמיתיות של הספק. ספק שיכול לספק יחידה אחת ב-2 שבועות אבל לא יכול לאשר מתי יסיים עשרה, לא מתאים לניסוי שדורש יחידות זהות.

אם רכיב ספציפי משנה זמינות, מה התהליך?

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

תרחיש להמחשה

התרחיש הבא הוא להמחשה, לא לקוח ספציפי.

נניח לרגע שצוות R&D מפתח אלגוריתם counter-UAV ומחפש פלטפורמה שתשחק את תפקיד ה"יעד המתוכנן". הדרישות שנשמעות בשיחה כזו: זמן טיסה של 8 דקות לפחות עם payload קטן, GPS waypoints ל-mission planning (הרחפן צריך לטוס בקווי טיסה מוגדרים מראש כדי לבחון את האלגוריתם), MAVLink לחיבור GCS חיצוני, מהירות מקסימלית של 80 קמ"ש, ואפשרות לפיילוד של כ-200 גרם בעתיד.

ה-spec שמתאים לתרחיש כזה: רחפן 7 אינץ' עם FC מבוסס H7 (כמו Matek H743 Mini), ArduCopter כ-firmware (לתמיכה מלאה ב-MAVLink ו-GPS waypoints), GPS module עם magnetometer מובנה, mounting plate מתחת למסגרת לפיילוד עתידי, ו-6S LiPo ב-1800-2200mAh לזמן טיסה של 8-10 דקות. זה ה-spec שיכול לעבוד לדרישות האלה.

שאלות נפוצות

האם פלטפורמת COTS מתאימה ל-production או רק ל-R&D?

COTS מתאים מצוין ל-R&D, Proof-of-Concept, ולאינטגרציה ראשונית. מעבר ל-production של מערכת ביטחונית בדרך כלל ידרוש הסמכות, עמידה ב-MIL-SPEC, ו-supply chain מבוקר שלא קיים ב-COTS. אבל הרבה פרויקטים מוצלחים מתחילים ב-COTS ואז עוברים ל-hardened platform רק אחרי שהפרויקט הוכח.

מה ההבדל בין COTS ל-NDAA-compliant?

NDAA, National Defense Authorization Act, הוא מסגרת רגולטורית אמריקאית שמגבילה שימוש בציוד ממדינות מסוימות (בעיקר סין) בפרויקטים פדרליים בארצות הברית. NDAA-compliant הוא מונח שנוגע בעיקר לרכש ממשלתי אמריקאי. COTS הוא פשוט "מוכן מהמדף", ללא קשר למדינת ייצור. המושגים שונים ואינם מחייבים אחד את השני.

האם DJI O4 Pro Air Unit חוקי לשימוש R&D ביטחוני בישראל?

לשימוש פנים-ארגוני במסגרת מחקר ופיתוח, DJI O4 Pro Air Unit הוא רכיב מסחרי שנמכר בחופשיות. לא ידוע לי על איסור ישראלי ספציפי על שימוש פנים-ארגוני בו. אבל: אם הפרויקט כולל ייצוא לחו"ל, שיתוף עם שותפים בינלאומיים, או דרישות אבטחת מידע ספציפיות, חובה לבדוק עם יועץ משפטי. DJI היא חברה סינית, ויש ארגונים בישראל שמדיניות האבטחה שלהם מגבילה שימוש ברכיבים מסינים בפרויקטים מסוימים.

מה האלטרנטיבה אם פרויקט שמתחיל ב-COTS צריך לעבור ל-MIL-STD?

זהו מהלך שתוכנן מראש ולא מהלך שעושים בזעם. הדרך הנכונה: לתעד כל גרסת COTS היטב (BOM, firmware, הגדרות, תוצאות ניסוי), ולהשתמש בתיעוד הזה כ-spec בסיס לפרויקט ה-hardened. הארכיטקטורה שהוכחה ב-COTS מתרגמת בדרך כלל לפלטפורמה מוסמכת, לא מפותחת מחדש מאפס.

איך להעריך אם ספק COTS אמין?

שאלו על ניסיון קודם עם לקוחות מחלקות R&D. בקשו BOM של בנייה קודמת. שאלו על זמן תגובה לתמיכה טכנית אחרי מסירה. ספק שנשמע בטוח רק בשלב המכירה ולא יכול לענות על שאלות BOM ולוחות זמנים ספציפיות הוא ספק שחוזרים אליו פעם אחת.

לאן מכאן

לחברות R&D וצוותי פיתוח שמחפשים פלטפורמת COTS FPV: עמוד שירותי תעשייה של TAKE-FPV מפרט את הגישה שלנו לפרויקטים ביטחוניים ו-R&D, כולל אספקת custom build עם BOM מלא, תמיכה ב-firmware לפי בחירה, ו-NDA לפני שיחת ה-spec.

למהנדסים שרוצים להבין את הפלטפורמה לעומק, כולל ארכיטקטורת FC, בחירת firmware ועבודה עם MAVLink, קורס הבנייה שלנו מכסה את כל ה-stack מחומרה ועד פירמוור. הבנה מעמיקה של הפלטפורמה מקצרת משמעותית את זמן האינטגרציה.

נכתב על ידי יעקב חביב, מייסד TAKE-FPV ומנהל קהילת FPV הגדולה בישראל.