פרוייקט QUAD CONTROLLER יוצא לדרך

שלומות,

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

הדרך היחידה שיכולה להושיב אותי מספר שעות בודדות בשבוע סביב זה היא פתיחת שרשור בניה בפורום.
אז הנה התחלנו...

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

איציק - תרומה של בניית הגוף ושאר ירקות מכאניים.
מיכאל אלון (גורו ה-PIC בארץ) -תרומה של Breakout board של dsPIC33FJ256GP710.
חבר פורום בעילום שם - תרומה של IMU 9 DEGREES OF FREEDOM.


אבני הדרך לתקופה הקרובה יהיו:
כתיבת הדרייברים - PWM OUTPUT, PWM CAPTURE, ADC, UART
כתיבת המיקסר הבסיסי.
כתיבת אלגוריתם COMPLEMENTRY FILTER עבור זוית של ציר בודד.
כתיבת חוג בקרה מבוסס PI עבור ציר בודד.
בדיקת נדנדה עבור ציר בודד.

אשמח לקבל עצות/הערות והארות.

שבוע טוב לכולם,
שחר

בהצלחה!

אני כרגע משקיע מעט מאד מאמץ ב-QUAD שלי, היות וכל פיתוח רציני מחייב השקעה גדולה מאד. ה-features הבסיסיים של טיסה יציבה עובדים יפה.

במקום זה החלטתי ללכת על ArduCopter. מדובר בפרוייקט Open Source שתופס פופולריות. נראה לי שלהתחיל מבסיס מוצק של תוכנה וחומרה שכבר תומכת ב-Altitude Hold, GPS ושאר דברים מעניינים יהיה יותר חכם. אני בשלב איסוף החומרה כרגע והעבודה תיקח את הזמן שלה...

דרור

נשמע מאוד מעניין, רק שלא תתעייף במהלך הפיתוח ... :)

תציץ כאן :
http://code.google.com/p/gentlenav/
לא מעט מהדרייברים כבר מוכנים
והחלק הכי מעניין הוא קונספציית HILSIM

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

עדכון ראשון.

כתיבת דריבר PWM הושלמה. הרכיב תומך ב-8 יצאות PWM, אני כרגע משתמש ב-4.
משימה הבאה - כתיבת דריבר CAPTURE עבור דגימת 6 ערוצי מקלט. 4 עבור הסטיקים + 2 ערוצים עבור PAN/TILT.

דרור - תודה. אני בטוח שעל הרבה שאלות שכבר יש לי תוכל לעזור בהמשך הדרך.

צביקה - התחלתי את הפיתוח עייף.

יגאל - תודה על הלינק. המווווון אינפורמציה!

איציק - לא ברור לי איך אתה מקליד כשהידיים שלך צריכות להיות דביקות מתיבנות הגוף????

שבוע טוב,
שחר

עוד הצעות ליציאות/כניסות PWM
למצלמה תזדקק גם לROLL אם תרצה להוסיף אופציית יצוב או TARGETING
כמובן לא לשכוח כניסת MODE לפחות אחת בטח תזדקק לה בשלב זה או אחר.
יציאת TRIGGER שימושי להפעלת מצלמה שחרור מטענים.

עדכון.

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

OK, אז השאלות מתחילות...

כתיבת המיקסר - למרות שהכוונה הראשונית היתה לכתוב את יחס המיקס ע"י מקדמים שנקבעים באמצעות פוטנציומטרים. האם מנסיונכם יש יחס שטוב להתחיל איתו? למשל בהטיית PITCH, האם להוסיף/להחסיר ביחס של 1:1 את דלתא הפולס מ1.5 מילישניה של הסטיק ל-PWM שמזין את בקרי המהירות של ציר ה-PITCH? לחילופין, האם זה נכון לקבע את יחס המיקס על 1:1 ולסתמך על פונקצית ה-EXPO בשלט ולוותר על הפוטנציומטרים?

שאלת C כללית - עד עכשיו כתבתי הכל ב-FIXED POINT כיוון שהחומרה, בעיקר TIMERים, הם התקני FIXED POINT.
האם יש דרך יעילה להמיר בין FLOAT ל INT ? אני אצטרך זאת בהמרת מוצא ה-PID ל-PWM.

תודה,
שחר

ציטוט:

---

נכתב במקור על ידי ShaharBD

שאלת C כללית - עד עכשיו כתבתי הכל ב-FIXED POINT כיוון שהחומרה, בעיקר TIMERים, הם התקני FIXED POINT.
האם יש דרך יעילה להמיר בין FLOAT ל INT ? אני אצטרך זאת בהמרת מוצא ה-PID ל-PWM.

תודה,
שחר

---

בעיקרון הצבה פשוטה בין float ל-int אמורה לעשות את זה, אם הקומפיילר יודע מה הוא עושה. חשוב מאד לבדוק overflow כלומר עוד כשהמשתנה הוא float לכתוב קוד קצר שבודק אם הוא בתחום הדרוש לפני ההמרה!
חוץ מזה, אפשר גם לעשות את ה-PID ב-int, בזהירות. אני ממליץ להתחיל מ-float ולעשות אופטמיזציה אח"כ.

בנוסף - אם אתה מתבסס על PIC קח את הקוד של UAVX כדוגמא. לא מתועד כל כך אבל עובד ומוכח ויכול להיות שתמצא בו הרבה דברים שימושיים.

דרור

עוד דבר אחד מאד חשוב.

מי שבא מעולם ה-32 ביט ומעלה נוטה לפספס את זה ובגדול. ל-C יש כל מיני כללים באיזו רזולוציה הוא עושה את החישובים, חלקם לא ממש פשוטים וקל לטעות. למשל אם הקומפיילר יחליט שהוא עושה חישוב ביניים ב-8 ביט ויקרה overflow שלא ציפית לו. אם תסתכל בקוד שלי תראה שכמעט בכל מקום הגדרתי באופן מפורש את הרזולוציה (ע"י type casting). אני מקווה שמה שאני כותב הוא ברור, אם לא שאל.

דרור

דרור תודה.

נראה לי שאנסה לכתוב את רוב הקוד כולל ה-PID ב-FIXED POINT. כיוון שמדובר ברכיב DSP אני מניח שיש לו סוכמים שנכנסים לרוויה (המילה הטובה ביותר שאיש חומרה יכול למצוא ל-NO OVERFLOW) אבל טרם חיפשתי בדף הנתונים. אשמח גם לשלוח לך קטעי קוד לבדיקה והצעות שיפור ובכך לשפר את סגנון הקידוד שלי.

בקוד שלך, אתה זוכר את יחס המיקס?

תודה,
שחר

שחר, PIC? אתה יודע שאפשר יותר טוב מזה. היית מדבר איתי...

אני ממליץ לך לכתוב הכל בfixed point, זו הדרך היחידה שלא תקבל כלמיני rounding errors ובלאגן אחר (מה גם שעבודה בfloat זה דבר די איטי על מעבדים שעושים את זה בתוכנה, מה שאני כמעט בטוח שהPIC עושה).

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

צבי, שאלתי אותו גם והוא מעדיף להתחיל מהתחלה :rolleyes:
אני עוד תקוע למעלה בשישה ערוצים:eek: למה המספר הז?

ציטוט:

---

נכתב במקור על ידי ShaharBD

בקוד שלך, אתה זוכר את יחס המיקס?

תודה,
שחר

---

לא ממש ברור לי למה אתה מתכוון?
יש כמה פרמטרים:
1. כשאתה מקבל החלטה על תיקון באחד מ-3 הצירים, אתה צריך לתרגם לפקודות ל-4 מנועים. ב-QUAD זה נוסחה פשוטה של + או -
2. האם אתה מתכוון למקדם הגברה של ערך התיקון? זה נשלט בקלות על ידי מקדמי PID של חוג הבקרה. במקרים הפשוטים שולטים על P בלבד.
3. בדרך כלל יש עוד פרמטר שקובע את רגישות הסטיקים

הסבר ונמק ...

דרור

טוב,
קיבלתי טלפון מאיים מהלטאה המעופפת...
הוא דחק אותי לפינה ושכנע אותי להפסיק לעבוד על ה-PIC ולעבור ל-CORTEX.
לא רק זה, הוא גם איים שהוא תורם EVAL BOARD + IDE + JTAG + RTOS :)
הוא גם יעזור ע"פ יכולות הזמן שלו בכתיבה.
השבוע נתחיל להעביר את מעט העבודה שנעשתה ל-MCU החדש.

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

שחר

ציטוט:

---

נכתב במקור על ידי dror

לא ממש ברור לי למה אתה מתכוון?
יש כמה פרמטרים:
1. כשאתה מקבל החלטה על תיקון באחד מ-3 הצירים, אתה צריך לתרגם לפקודות ל-4 מנועים. ב-QUAD זה נוסחה פשוטה של + או -
2. האם אתה מתכוון למקדם הגברה של ערך התיקון? זה נשלט בקלות על ידי מקדמי PID של חוג הבקרה. במקרים הפשוטים שולטים על P בלבד.
3. בדרך כלל יש עוד פרמטר שקובע את רגישות הסטיקים

הסבר ונמק ...

דרור

---

השאלה שלי היתה, האם מדובר בחיבור/חיסור פשוט או שצריך לעשות SCALING לפני החיבור/חיסור בשביל לשנות רגישות סטיקים.
השכבה שאני מדבר עליה היא לפני תיקון ה-PID ורק מתרגמת תנועת סטיק ל-PWM.

האם הזזת סטיק מהמרכז מנטרלת את תיקון ה-PID רגעית בכדי שה-PID לא יתנגד לתנועת הסטיק?

שחר

ציטוט:

---

נכתב במקור על ידי ShaharBD

טוב,
קיבלתי טלפון מאיים מהלטאה המעופפת...
הוא דחק אותי לפינה ושכנע אותי להפסיק לעבוד על ה-PIC ולעבור ל-CORTEX.
לא רק זה, הוא גם איים שהוא תורם EVAL BOARD + IDE + JTAG + RTOS :)
הוא גם יעזור ע"פ יכולות הזמן שלו בכתיבה.
השבוע נתחיל להעביר את מעט העבודה שנעשתה ל-MCU החדש.

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

שחר

---

עכשיו אנחנו מדברים. PIC, גם כן...

ציטוט:

---

נכתב במקור על ידי ShaharBD

השאלה שלי היתה, האם מדובר בחיבור/חיסור פשוט או שצריך לעשות SCALING לפני החיבור/חיסור בשביל לשנות רגישות סטיקים.
השכבה שאני מדבר עליה היא לפני תיקון ה-PID ורק מתרגמת תנועת סטיק ל-PWM.

האם הזזת סטיק מהמרכז מנטרלת את תיקון ה-PID רגעית בכדי שה-PID לא יתנגד לתנועת הסטיק?

שחר

---

PID עובד על שגיאה מדודה, כלומר מצב רצוי (סטיק) מול מצוי (מדידות). למשל אם אתה רוצה שהסטיק ישלוט על קצב גלגול, אתה מחסר את זה ממדידת הג'יירו של קצב הגילגול בפועל ומקבל שגיאת קצב גילגול. מכאן שהסטיק תמיד נלקח בחשבון.

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

דרור

ציטוט:

---

נכתב במקור על ידי ShaharBD

השאלה שלי היתה, האם מדובר בחיבור/חיסור פשוט או שצריך לעשות SCALING לפני החיבור/חיסור בשביל לשנות רגישות סטיקים.
השכבה שאני מדבר עליה היא לפני תיקון ה-PID ורק מתרגמת תנועת סטיק ל-PWM.

האם הזזת סטיק מהמרכז מנטרלת את תיקון ה-PID רגעית בכדי שה-PID לא יתנגד לתנועת הסטיק?

שחר

---

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

ציטוט:

---

נכתב במקור על ידי flyinglizard

עכשיו אנחנו מדברים. PIC, גם כן...

---

הצעה (מעשית או לא - אתם תחליטו):ל- TMS320F28335 של TI יש את כל הפריפריה הדרושה על הרכיב, הוא pseudo floating point וניתן לצריבה ישירות מ-Simulink ... לא כדאי לשקול אותו?

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

אני יכול להפנות לחומר על PID ב-fixed אם צריך ...

אם תצטרכו מכשירי מדידה מתקדמים - יש לנו.

ציטוט:

---

נכתב במקור על ידי ShaharBD

השאלה שלי היתה, האם מדובר בחיבור/חיסור פשוט או שצריך לעשות SCALING לפני החיבור/חיסור בשביל לשנות רגישות סטיקים.
השכבה שאני מדבר עליה היא לפני תיקון ה-PID ורק מתרגמת תנועת סטיק ל-PWM.

האם הזזת סטיק מהמרכז מנטרלת את תיקון ה-PID רגעית בכדי שה-PID לא יתנגד לתנועת הסטיק?

שחר

---

האם יש מצב לראות את האלגוריתם הכללי? האם תוכלו להפנות אותי לחומר?

יש לנו קוד פלטפורמה מאוד חזק לCortex (דרייברים, סטאקים וכו') וגם את כלי הפיתוח. אני מעריך שמה שיש לTI נופל משמעותית מבחינת ההיקף. זה לא כלכך משנה לאלגוריתמיקה הבסיסית, אבל כן אם שחר יחליט להרחיב את היכולות של הבקר לכיוונים אחרים.

תקנו אותי אם אני טועה, אבל חוג בקרה בתדרים האלה לא אמור לאכול יותר מכמה MIPS בודדים, עם מעבד 100 מגה הרץ הפרוייקט מכוסה היטב.

ציטוט:

---

נכתב במקור על ידי flyinglizard

יש לנו קוד פלטפורמה מאוד חזק לCortex (דרייברים, סטאקים וכו') וגם את כלי הפיתוח. אני מעריך שמה שיש לTI נופל משמעותית מבחינת ההיקף. זה לא כלכך משנה לאלגוריתמיקה הבסיסית, אבל כן אם שחר יחליט להרחיב את היכולות של הבקר לכיוונים אחרים.

תקנו אותי אם אני טועה, אבל חוג בקרה בתדרים האלה לא אמור לאכול יותר מכמה MIPS בודדים, עם מעבד 100 מגה הרץ הפרוייקט מכוסה היטב.

---

TI שהזכרתי יעודי לבקרה רב צירית ... ביצועים סוף ... מהו רוחב פס הרצוי של הבקרים?

מבחינת דרייברים, סביבת פיתוח וכו', כולם היום מגיעים עם החבילה המלאה ... האם ל-ARM יש את כל הפריפריה on-board?
PID הןא אלגוריתם בקרה בסיסי ביותר ... אם תשלחו לי את האלגוריתם, אולי בקר מתקדם יותר ישפר ביצועים משמעותית...

אלון,

לא כל כך הבנתי איזה אלגוריתם אתה רוצה לראות.
רוחב הפס עם בקרים סטנדרטיים הוא 50HZ, עם בקרי מהירות I2C רוחב הפס גבוה משמעותית.
אני צריך לחפש את הגרמני שכתב I2C לבקרים של HOBBY WING ולראות אם פרסם SOURCE CODE.
מי עוזר למצוא את הלינק?

שחר

הנה ההמרה של הבקר:
http://www.rcgroups.com/forums/showthread.php?t=766589

לטאה, עשית לי את היום!

אם רק היה לי שקל על כל פעם שהייתי שומע את זה

ציטוט:

---

נכתב במקור על ידי ShaharBD

אלון,

לא כל כך הבנתי איזה אלגוריתם אתה רוצה לראות.
רוחב הפס עם בקרים סטנדרטיים הוא 50HZ, עם בקרי מהירות I2C רוחב הפס גבוה משמעותית.
אני צריך לחפש את הגרמני שכתב I2C לבקרים של HOBBY WING ולראות אם פרסם SOURCE CODE.
מי עוזר למצוא את הלינק?

שחר

---

כמעט כל בקר מצוי יודע לעבוד בקצב עידכון PWM של כמעט 500Hz, ואתה צריך את זה. לא צריך I2C, סתם יקר.

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

דרור

ציטוט:

---

נכתב במקור על ידי flyinglizard

הנה ההמרה של הבקר:
http://www.rcgroups.com/forums/showthread.php?t=766589

---

קבלו עוד מנה
http://www.rcgroups.com/forums/showt...hlight=nunchuk

http://www.rcgroups.com/forums/showthread.php?t=1039852

http://www.rcgroups.com/forums/showt...m#post15540574

http://shrediquette.blogspot.com/201...erter-and.html

מוטי

ציטוט:

---

נכתב במקור על ידי ShaharBD

אלון,

לא כל כך הבנתי איזה אלגוריתם אתה רוצה לראות.
רוחב הפס עם בקרים סטנדרטיים הוא 50HZ, עם בקרי מהירות I2C רוחב הפס גבוה משמעותית.
אני צריך לחפש את הגרמני שכתב I2C לבקרים של HOBBY WING ולראות אם פרסם SOURCE CODE.
מי עוזר למצוא את הלינק?

שחר

---

אני לא מתחום הטיסנאות - אני הייתי רוצה להבין ברמה כזאת: יש 4 מנועים, שכמו שאני מבין הבקרה שלהם הנה בקרת מהירות בלבד על כל אחד. על הבקר לזהות את פקודת השלט ולתרגם אותה לפקודות מהירות סיבוב לכל מנוע. האם זה נכון? אם כן, כיצד נכנסים לסיפור ה-gyros וה-accelerometers וחיישנים נוספים?

בעיקרון אפשר להסתדר גם בלי החיישנים, אם תעשה מיקס בשלט שמתרגם פקודות aileron\elevator\pitch לשליטה נפרדת למנועים (כמו ששולטים בסרבואים), פשוט זה יהיה כלי הרבה יותר קשה לשליטה. תחשוב שזה בסך הכל fly by wire ששומר על הכלי מיוצב.

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

אין חוגים פתוחים בfly by wire לדעתי, אחרת אתה מבטל את כל היתרון שלו. תחשוב שכך הקלט מהמשתמש הופך לאבסולוטי, ללא תלות ברוח או חוסר היציבות של הכלי. נתת פקודה לX מעלות סיבוב? זה בדיוק מה שיקרה. הPID משווה את הקלט מהמשתמש לעומת הביצוע בפועל. בתנאים סטריליים לגמרי (אוויר עומד, מנועים מסונכרנים בצורה מושלמת, CG מדוייק וכו') לא היית צריך PID, במציאות בשביל שהכלי ירחף במקום בלי עזרת המשתמש ויטוס בצורה מדוייקת אתה חייב.

המיקרו דוגם את החיישנים, נותן פיקוד למנועים ובעזרת חוג סגור (PID וכו') מבצע תיקונים.

ציטוט:

---

נכתב במקור על ידי flyinglizard

אין חוגים פתוחים בfly by wire לדעתי, אחרת אתה מבטל את כל היתרון שלו. תחשוב שכך הקלט מהמשתמש הופך לאבסולוטי, ללא תלות ברוח או חוסר היציבות של הכלי. נתת פקודה לX מעלות סיבוב? זה בדיוק מה שיקרה. הPID משווה את הקלט מהמשתמש לעומת הביצוע בפועל. בתנאים סטריליים לגמרי (אוויר עומד, מנועים מסונכרנים בצורה מושלמת, CG מדוייק וכו') לא היית צריך PID, במציאות בשביל שהכלי ירחף במקום בלי עזרת המשתמש ויטוס בצורה מדוייקת אתה חייב.

המיקרו דוגם את החיישנים, נותן פיקוד למנועים ובעזרת חוג סגור (PID וכו') מבצע תיקונים.

---

ok, אז זה כן fly-by-wire (מוגדר כחוג סגור) ... אז ללא ג'רו ומדי תאוצה עדיין סוגרים את החוג ע"פי הפקודה מהסטיק, אך עם אינפורמציה מוגבלת של משוב מהירות בלבד?

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

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

במקרה של חוג סגור, כולם פועלים במקביל או שיש עדיפות לחוג מסוים?

ציטוט:

---

נכתב במקור על ידי alonk

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

במקרה של חוג סגור, כולם פועלים במקביל או שיש עדיפות לחוג מסוים?

---

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

מבחינת עדיפות, אני לא יודע מה תכנן מר BD, ההגיון שלי אומר שמבחינת שכבות תיקון הזווית (באמצעות הג'יירוסקופים) נעשה ברמה "ראשונית" יותר בשביל לשמור את הכלי מאוזן, בעוד שהתיקון לפי מדי התאוצה (תיקון הסחיפה במרחב) נעשה ברמה גבוהה יותר כחלק מקביעת המיקום.

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

הבנתי אתך.
האם קיים מודל דינאמי של הכלי, על מנת למצוא את פונקציות התמסורת שלו ולתכנן בקר מתאים?