מעקב שליטה אחר מחשב רכב מרחוק D1 מגישים

Download Report

Transcript מעקב שליטה אחר מחשב רכב מרחוק D1 מגישים

‫הצגת פרויקט שנתי ‪ -‬סוף חלק ב'‬
‫מעקב שליטה אחר מחשב רכב מרחוק ‪D1‬‬
‫מגישים‪:‬‬
‫מיקיו פרדו‬
‫יותם לוי‬
‫מנחה‪ :‬בועז מזרחי‬
‫מטרות הפרויקט‬
‫מציאת שיפוע הכביש ב‪ 2-‬גישות‪:‬‬
‫◦ הראשונה בעזרת נתונים שאנו מקבלים מברומטר ומנתונים המגיעים ממחשב הרכב‪.‬‬
‫◦ השנייה תבוצע ע"י נתונים המתקבלים מאקסלרומטר וממחשב הרכב‪.‬‬
‫עבודת ‪ RT‬במכשיר אנדרואיד ‪ -‬נתונים מגיעים באינטרוולים מסוימים למכשיר מבוסס אנדרואיד ואנו‬
‫צריכים לעבד את הנתונים ולחשב את שיפוע הכביש ב‪.RT-‬‬
‫התאמת האפליקציה משלב א'‬
‫לקבלת נתונים נוספים –‬
‫אקסלרומטר ומהירות הרכב‬
‫שלבי הפרויקט‪:‬‬
‫מחקר על היתכנות המודלים‬
‫הפיזיקליים‬
‫הוכחת היתכנות עבור המודלים‬
‫הפיזיקאליים – מטלב‬
‫אפיון תוכנית המטלב – ברומטר‬
‫תוכנית המטלב – תוצאות‬
‫הערות ומסקנות – מודל הברומטר‬
‫התאמת האפליקציה לעיבוד נתונים‬
‫נוספים‬
‫התאמת האפליקציה משלב א' לקבלת נתונים נוספים –‬
‫אקסלרומטר ומהירות הרכב‬
‫• הרחבת הטיפול בזיהוי המחרוזות התואמות את מדידות האקסלרומטר‬
‫והמהירויות‪.‬‬
‫• עיבוד המחרוזות לתוך המודל הפיזיקאלי‪.‬‬
‫• הבעיות שנתקלנו בהן‪:‬‬
‫• כאשר שידרנו את כל הקריאות (ברומטר‪ ,‬אקסלרומטר ומהירות)‪ ,‬האפליקציה‬
‫שלנו לא הצליחה לעמוד בקצב קבלת הנתונים‪.‬‬
‫• הקוד לדוגמא עליו התבססנו אינו מנהל את הפעילויות אלה מסתמך‬
‫על ‪ INTERRUPTS‬מהבלוטות' כדי לבצע את הקריאה לפעילויות‪.‬‬
‫התאמת האפליקציה משלב א' לקבלת נתונים נוספים –‬
‫אקסלרומטר ומהירות הרכב‬
‫• המשמעות של הדבר היא שבמידה ונשלחת אל האפליקציה כמות רבה של‬
‫קריאות בתדירות גבוהה‪ ,‬לא נספיק לעבד אותן לפני ה ‪ INTERUPT‬הבא של‬
‫הבלוטות'‪.‬‬
‫• בצורה זו ה ‪ BUFFER‬שהגדרנו ילך ויתמלא עד שנקבל את הקריסה של‬
‫האפליקציה‪.‬‬
‫• לכן בשלב זה החלטנו שכדי שנוכל להמשיך עם עיקר הפרויקט‪ ,‬נעבור לשלב‬
‫הוכחת ההיתכנות של המודלים ולאחר מכן נחזור לעיבוד הנתונים באנדרואיד‪.‬‬
‫מחקר על היתכנות המודלים הפיזיקליים‬
‫• התמקדנו בהצעת פתרונות למציאת שיפוע עבור מודל האקסלרומטר ונתוני מהירות‬
‫הרכב‪.‬‬
‫• מודל מטריצת המעבר היה אחד המודלים אותם ניסינו להוכיח‪ ,‬ממחקר שפורסם בנושא‬
‫זה (ראה ביבליוגרפיה) הבנו כי קשה מאוד להגיע לפתרון מלא בשל הקומפלקסיות של‬
‫המודל‪.‬‬
‫• חקרנו כיוונים נוספים והצענו מספר מודלים אשר משתמשים בנתוני האקסלרומטר‬
‫למציאת שיפוע כביש ‪ -‬מודלים אלו נפסלו עקב בעיות שגיאה מצטברת‪.‬‬
‫הוכחת היתכנות עבור המודלים הפיזיקאליים ‪ -‬מטלב‬
‫• החלטנו לבצע הוכחת היתכנות עבור מודל הברומטר כיוון שהוא יחסית פשוט‬
‫ואינטואיטיבי‪.‬‬
‫• ביצענו נסיעת מבחן והקלטנו את נתוני הקריאות ע"י ה ‪ TERA TERM‬לתוך קובץ ‪LOG.‬‬
‫• בחרנו את מקטעי נסיעות המבחן במסלולים שידועים לנו מראש השיפועים ( באחוזים )‬
‫של הכביש‪.‬‬
‫• מקטע חיפה עתלית – בעל שיפוע משתנה סביב לאפס אחוז‪.‬‬
‫• מקטע מנהרות הכרמל – גראנד קניון – חיפה מערב – ירידה ‪ +‬עליה – שיפוע של ‪3-4%‬‬
‫אפיון תוכנת המטלב – ברומטר‬
‫• קיימים שני שלבים בתוכנית‪:‬‬
‫• קליטת הנתונים – בשלב זה הנתונים מגיעים מקובץ ה ‪ LOG,‬הנתונים הינם גולמיים‪.‬‬
‫עלינו לחלק את קובץ המדידות לנתוני ברומטר‪ ,‬מהירות‪.‬‬
‫• עיבוד הנתונים – בשלב זה יש לרשותנו מטריצות של גובה (בפסקל) ומהירות (קמ"ש)‪.‬‬
‫היה עלינו להמיר את נתוני הגובה למטרים ונתוני המהירות לדרך במטרים‪.‬‬
‫• לחישוב הזווית היה עלינו לחשב‪:‬‬
‫•‬
‫𝑚 𝑡‪∆𝐻𝑖𝑔ℎ‬‬
‫𝑚 𝑡∆𝑉‬
‫‪= arcsin‬‬
‫𝑡‪∆𝐻𝑖𝑔ℎ‬‬
‫‪∆𝐿𝑒𝑛𝑔𝑡ℎ‬‬
‫𝑡‪∆𝐻𝑖𝑔ℎ‬‬
‫‪𝑆𝑖𝑛 𝜃 = ∆𝐿𝑒𝑛𝑔𝑡ℎ => 𝜃 = arcsin‬‬
‫עיבוד תוכנת המטלב – ברומטר‬
‫• כאשר טענו את המדידות לתוך החישוב‪ ,‬קיבלנו גרף שיפוע רועש ולא מדויק (עקב‬
‫חישוב דלתאות)‪.‬‬
‫• קצב הדגימה כ ‪ 4‬דגימות לשנייה‪.‬‬
‫• את הבעיה הזו פתרנו ע"י ניקוי רעשים ‪ LPF‬עם תדר קטעון ב ‪8Hz‬‬
‫תוכנית המטלב – תוצאות ‪ -‬גראנד קניון – חיפה מערב‬
‫תוכנית המטלב – תוצאות‬
‫•ניתן להבחין כי תדר הקטעון של המסנן משפיע דרסטי על התנהגות השיפוע‪.‬‬
‫•נוצרים רעשים רבים שנובעים מרגישותו של הברומטר (עקב מדידת דלתאות)‬
‫•קיבלנו שגיאה קבועה בשיפוע‪ .‬השיפוע שהיה אמור להתקבל היה ‪3-4%‬‬
‫ואנחנו קיבלנו שיפוע של ‪.1%‬‬
‫•קל לראות כי ההתנהגות של השיפוע תואמת את תוואי הכביש ולכן אנו הסקנו‬
‫כי שימוש ב ‪ LPF‬גורר שגיאה קבועה בחישוב הזויות‪.‬‬
‫תוכנית המטלב – תוצאות ‪ -‬כביש עתלית חיפה‬
‫תוכנית המטלב – תוצאות ‪ -‬ירידה במנהרה ועלייה לאחר‬
‫מספר דקות‬
‫הערות ומסקנות – מודל הברומטר‬
‫•הערות‪:‬‬
‫•שמנו לב שבמקומות בהם עמדנו במקום‪ ,‬הזווית התפוצצה‪.‬‬
‫•לכן היה עלינו לקבוע סף מהירות שממנו הרעש במערכת הינו סביר כדי לחלץ‬
‫זוויות‪.‬‬
‫•המהירות המינימלית שקיבלנו הייתה ‪ 30‬קמ"ש – ככל הנראה במהירויות‬
‫נמוכות יותר‪ ,‬הקריאות אינן מספיק מדויקות ומכניסות רעש רב למערכת‪.‬‬
‫הערות ומסקנות – מודל הברומטר‬
‫•מסקנות‪:‬‬
‫•כפי שניתן לראות קיבלנו את הזוויות הצפויות (בסטייה קבועה) והתנהגות‬
‫הזויות תואמת את תוואי הכביש‪.‬‬
‫•השימוש במטלב יעיל ומהיר יחסית לפיתוח באנדרואיד ומכיוון שיש לנו נגישות‬
‫לכל הקריאות לאורך הנסיעה‪ ,‬קיבלנו את התוצאות הרצויות‪.‬‬
‫•ע"י שימוש במיקום ‪ ,GPS‬ומפות של גוגל‪ ,‬נוכל לקבל מפה תלת ממדית‬
‫התואמת לתוואי האמתי של הכבישים‪.‬‬
‫•הוכחת ההיתכנות במודל זה מראה כי ניתן לקבל את שיפוע הכביש בקלות‬
‫יחסית אם כי חישוב בזמן אמת דורש התאמות רבות שלאו דווקא טריוויאליות‪.‬‬
‫התאמת האפליקציה לעיבוד נתונים נוספים‬
‫•כפי שנאמר בפתיחה של פרק זה‪ ,‬נדרש ידע ופיתוח של ניהול פעילויות‬
‫בסביבת אנדרואיד‪.‬‬
‫•הידע בתחום זה חסר לנו ויידרש לנו זמן למידה שחוצה את לוחות הזמנים‬
‫שהוקצבו לפרויקט זה ולכן חלק זה אינו הושלם‪.‬‬
‫סיכום‬
‫•בפרויקט השנתי הזה למדנו כיצד יש לבחון רעיון תאורטי‪ ,‬משלב בניית מודלים‬
‫אפשריים > בניית סביבת בדיקה > קבלת הנתונים וניתוחם‪.‬‬
‫•הפרויקט התמקד במציאת פתרון לבעיה שחברות רבות בתעשייה מנסות‬
‫למצוא לו פתרון‪.‬‬
‫ביבליוגרפיה‬
http://www.tkt.cs.tut.fi/research/nappo_files/ParviainenIAIN09.pdf•
http://www.diva-portal.org/smash/get/diva2:495853/FULLTEXT01.pdf•
http://www.diva-portal.org/smash/get/diva2:380350/FULLTEXT01.pdf•