מה זה GetTable?

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

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

אז איך זה עובד?

כל "שולחן-חכם" מצויד למעשה ברכיב חומרה מסוג raspberry pi (להלן: RPI). ה-RPI מספק חיווי על סטטוס השולחן ברחבי הספריה באמצעות הנורות המצורפות, וכן מאפשר לעדכן ב-DB את מצב הספריה מבחינת שולחנות פנויים, זאת באמצעות חיישן תנועה מסוג PIR (או: passive InfraRed sensor) שמזהה נוכחות של אדם בקרבת השולחן.

לכל שולחן מחובר RPI משלו, המצויד בסנסור PIR שכזה, באמצעותו ניתן לזהות אדם המתיישב בעמדה ותופס את השולחן לעצמו, או קם ממנה ומשחרר את השולחן לטובת משתמשים אחרים. בפרט, כאשר משתמש מתיישב על שולחן המסומן כ'פנוי' (אור ירוק), ה-raspberry pi משנה את סטטוס השולחן ל'תפוס' ע"י פניה לשרת והדלקת ה-לד (led) האדום. כתוצאה מכך, משתמשים באפליקציה יראו את השולחן כתפוס, ולא יוכלו להזמין אותו על שמם. סנסור PIR מזהה תנועה עד לטווח של מטרים ספורים, וכאשר תנועה כזו מזוהה, נשלח אירוע ל-raspberry pi. תוכנית ה-raspberry pi מנטרת אירועים אלו וקובעת את סטטוס השולחן, ובהתאם אילו לדים להדליק ואילו הודעות לשלוח לשרת. בנוסף, המערכת כוללת גם כפתור "השהייה", שמאפשר למשתמש המאייש שולחן לעזוב את השולחן למשך 10 דק, מבלי שהשולחן יוצג כ'פנוי' באפליקציה או שיודלק אור ירוק בלד. תוסף זה נועד לאפשר למשתמש לקום לזמן קצר (לשירותים, או לטובת הדפסת חומרי לימוד, שאילת ספר וכיו"ב) מבלי לחשוש לאיבוד זכותו על השולחן למשך פרק הזמן הקצר הזה.

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

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

בצד המשתמש יושבת האפליקציה (Mobile application), שמתפקדת כממשק משתמש לצפיה בשולחנות פנויים, הזמנת שולחן וצפיה בהזמנה קיימת, כל זאת לאחר ביצוע אותנטיקציה של המשתמש אל מול השרת. בחרנו באפליקציית Cross-Platform שבנויה באמצעות קורדובה ופותחה ב-JavaScript. האפליקציה רצה על ה-Native Browser של מכשיר המובייל ומתקשרת עם השרת באמצעות HTTP Client.

השרת (server) מספק ומנהל את הממשק בין הDB לבין משתמשי הקצה (גם האפליקציה וגם השולחנות). השתמשנו בשרת על פלטפורמת אז'ור של מייקרוסופט. בפרט, השרת מספק מתודות לתקשורת end-to-end בין האפליקציה והשולחן החכם, כמו למשל הזמנת שולחן מצד האפליקציה, כך שה-RPI (בהמשך) "יידע" שהשולחן הוזמן וידליק את האור האדום, או תפיסת שולחן מצד השולחן החכם כך שהאפליקציה "תדע" שהשולחן מאוכלס ולא תציע אותו למשתמשים כפנוי להזמנה. המתודות העיקריות שמאפשרות פעולה חלקה של המערכת כוללות קבלת רשימת שולחנות או משתמשים לפי ספסיפיקציות שונות (למשל, שולחנות פנויים בלבד, שולחנות לפי מספר ספריה/קומה/חדר), הזמנת שולחן פנוי וביטול הזמנה (מצד המשתמש), ותפיסת שולחן או שחרורו (מצד השולחן). בנוסף, השרת מנהל את התקשורת מול ה-DB. השתמשנו ב-MongoDB כמסד נתונים. בפרט, במסגרת השירותים של אז'ור השתמשנו בשירות webApp עליו פרסנו את השרת שכתבנו ב-nodejs עם express.js, וכן השתמשנו במכונה וירטואלית שהרמנו על azure מתוך תבנית מוכנה מראש שמריצה MongoDB.

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

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

למשל כשהתחלנו את הפרוייקט התחלנו בהרמת שירות IOThub של Azure, אבל נתקלנו במספר בעיות לא קטן עם השירות הזה, החל מתיעוד מאוד לא מסודר ועדכני ועד שירותים שלא התאימו לנו (כך שיתכן וIOThub מתאים לאפליקציות מסויימות אך לאפליקציה שלנו לא הצלחנו להרים שירות שיחבר את החומרה עם דאטה-ביס ושירות אפליקציות). לאחר זמן לא קצר שבו הסתבכנו הומלץ לנו על ידי צוות הקורס לחפש שירותים אחרים של Azure, לכן בהמשך השתמשנו בשירות mobileApp. יש לציין שככה'נ שירותי mobileApp הם שירותים יותר יקרים כך שבכל חודש אפילו אם לא השתמשנו בקריאה אחת לAzure - נרשם חיוב בחשבון, בשל כך היו חודשים בהם הסכום החודשי שלנו תם ולא יכלנו להשתמש בשירותי הAzure לשארית אותו החודש. לבסוף עברנו לשימוש בשירות web app של azure לשם הרמת השרת, מה שמתבטא בחיוב נמוך הרבה יותר.

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

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

מבט קדימה

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