סיפורו של תלמיד בית ספר קוריאני שקיבל פרס מהמשרד על מערכת ניטור תורים

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

בעיה ראשונה: המתנה בתור יותר מדי זמן

איזו בעיה ראיתי? ככה:

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

בעיה שנייה: תנאים לא שוויוניים לממתינים

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

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

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

פתרונות נפוצים לבעיה

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

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

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

Eureka - הרעיון של יצירת מערכת ניטור קנטינה

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

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

עיצוב מערכת ניטור קנטינה

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

תוכנית מערכת ראשונית (ספטמבר 2017)

בחירת ציוד (אוקטובר 2017)

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

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

אב טיפוס ופיתוח (אוקטובר 2017)

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

עבור התוכנה שכתבתי ב-C++, הצבתי את המטרות הבאות:

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

כדי להשיג אותם הייתי צריך לעשות את הפעולות הבאות:

1. השתמש במודול RTC (שעון זמן אמת) כדי לפקח באופן רציף על השעה ולקבוע מתי האוכל מוגש בקפיטריה.
2. השתמש בשיטת דחיסת נתונים כדי לתעד את מצב המגן בתו אחד. בהתייחס לנתונים כקוד בינארי של חמישה סיביות, מיפיתי את הערכים השונים לתווי ASCII כך שהם ייצגו את רכיבי הנתונים.
3. השתמש ב-ThingSpeak (כלי IoT לניתוח ותרשימים מקוונים) על ידי שליחת בקשות HTTP בשיטת POST.

כמובן, היו כמה באגים. לדוגמה, לא ידעתי שהאופרטור sizeof( ) מחזיר את הערך 4 עבור אובייקט char *, ולא את אורך המחרוזת (מכיוון שזה לא מערך ולכן, המהדר לא מחשב את האורך) והופתעתי מאוד מדוע בקשות ה-HTTP שלי הכילו רק ארבעה תווים מכל כתובות האתרים!

גם לא כללתי סוגריים בשלב #define, מה שהוביל לתוצאות בלתי צפויות. טוב נגיד:

#define _A    2 * 5 
int a = _A / 3;

כאן אפשר היה לצפות ש-A יהיה שווה ל-3 (10 / 3 = 3), אבל למעשה זה חושב אחרת: 2 (2 * 5/ 3 = 2).

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

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

חומרה (לוחות רגל)

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

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

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

עשיתי את פריסת המגן באוטוקאד; מידות – 400 על 400 מילימטר.

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

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

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

ובכן, לאיטום השתמשתי בסרט חשמלי. הרבה סרט חשמלי.

והכל עבד!

תקופה מהחמישי בנובמבר עד השנים עשר בדצמבר

תמונה של המערכת - כל חמשת המגנים נראים כאן. בצד שמאל נמצאת האלקטרוניקה (D1-mini / Bluetooth / RTC)

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

באגים בתוכנה במהלך הבדיקה

כמובן, היו הרבה באגים במערכת. הנה אלה שאני זוכר.

התוכנית לא בדקה נקודות Wi-Fi זמינות כאשר ניסתה לחבר את הלקוח ל-ThingSpeak API. כדי לתקן את השגיאה, הוספתי שלב נוסף לבדיקת זמינות ה-Wi-Fi.

בפונקציית ההגדרה, קראתי שוב ושוב "WiFi.begin" עד שהופיע חיבור. מאוחר יותר גיליתי שהחיבור נוצר על ידי הקושחה ESP8266, ופונקציית ההתחלה משמשת רק בעת הגדרת Wi-Fi. תיקנתי את המצב על ידי קריאה לפונקציה פעם אחת בלבד, במהלך ההגדרה.

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

אודה לכלב השמירה

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

איך הבנתי את WDT

קטע קוד שנאבקתי איתו

מצאתי תוכנית, או ליתר דיוק הרחבה עבור Arduino, שמנתחת את מבנה הנתונים של התוכנה כאשר מתרחש Wdt-reset, ניגשת לקובץ ELF של הקוד המהודר (קורלציות בין פונקציות ומצביעים). כשזה נעשה, התברר שניתן לבטל את השגיאה באופן הבא:

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

בעיות בחומרה במהלך הבדיקה

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

ב-XNUMX בנובמבר, במהלך ארוחת הצהריים, המתג בפאנל השלישי נתקע

לעיל סיפקתי צילום מסך של תרשים מקוון מאתר ThingSpeak. כפי שניתן לראות, משהו קרה בסביבות השעה 12:25, ולאחר מכן נכשל מגן מספר שלוש. כתוצאה מכך, אורך התור נקבע ל-3 (הערך הוא 3*100), גם כשלמעשה הוא לא הגיע למגן השלישי. התיקון היה שהוספתי עוד ריפוד (כן, סרט דביק) כדי לתת למתג יותר מקום.

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

הפצת מידע על המערכת ברחבי בית הספר

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

התגובה הייתה פרועה!

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

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

אתה יודע מה מצחיק? המערכת הזו עדיין חיה (https://thingspeak.com/channels/346781)! התחברתי לחשבון שבו השתמשתי בעבר וראיתי את זה:

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

איך קיבלתי את הפרס הראשון ממשרד החינוך הקוריאני עבור הפרויקט שלי

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

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

שינויים ברעיון המקורי לתחרות

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

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

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

לכן, למרות שהייתי צריך להגיש את הבקשה שלי במהירות, חשבתי היטב כיצד אוכל להתאים אותה לשימוש רחב יותר.

הודעה שזכיתי בפרס הראשון!

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

תחילת המצגת (קיצוני משמאל - שר)

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

מסקנה

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

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

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

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

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

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

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

להלן מספר קישורים הקשורים לפרויקט:

• הערות על הוראות
• הקוד שכתבתי לפרויקט
• אותם תרשימים (חמישה עשר הימים האחרונים)
• גרפים שפרסמתי לציבור ב-2017
• כמה מזכירים על הפרוייקט על משאבי חדשות

מקור: www.habr.com