Creating a protocol for collaborative mobile applications for kids between 4 and 6 years old
•Als PPTX, PDF herunterladen•
1 gefällt mir•162 views
Track 6 - Mobile Apps and computational systems as learning tools Authors: Kryscia Ramírez-Benavides, Franklin García and Luis A. Guerrero https://www.youtube.com/watch?v=8_DPIKxf9fo&list=PLboNOuyyzZ85H9KngzY-R31GbiqFcOQbH&index=4
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (14)
Ähnlich wie Creating a protocol for collaborative mobile applications for kids between 4 and 6 years old
Ähnlich wie Creating a protocol for collaborative mobile applications for kids between 4 and 6 years old (20)
Mehr von Technological Ecosystems for Enhancing Multiculturality
Mehr von Technological Ecosystems for Enhancing Multiculturality (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Creating a protocol for collaborative mobile applications for kids between 4 and 6 years old
- 1. Creating a protocol for collaborative mobile applications for kids between 4 and 6 years old Ph.D(c) Kryscia Ramírez-Benavides Eng. Franklin García Ph.D Luis A. Guerrero Escuela de Ciencias de la Computación e Informática
- 2. Overview Who we are Introduction Protocol Design Protocol Implementation Conclusions and future work Acknowledgements
- 3. Who we are Ph.D(c) Kryscia Ramirez Professor at School of Computer Science and Informatics (ECCI-UCR) Researcher at Research Center for Communication and Information Technologies (CITIC-UCR) Eng. Franklin García Software Engineer, 12 years of experience on mobile technologies Current position as Lead Android Engineer at Log(n) (www.logn.co)
- 4. Introduction Digital Natives Today’s children are digital natives Surrounded by technology. Better access to it. STEM Science, Technology, Engineering, Mathematics Usage of Robotics as a method to improve these areas
- 5. Collaborative Learning “Work together to achieve a common goal” Introduction
- 7. Introduction
- 8. Introduction TITIBOTS Colab One robot, multiple children Every child has a tablet and belongs to a group (2-3 students)
- 9. Protocol Design Centralized vs Distributed Pros and Cons analysis Decision made based on available resources
- 10. Protocol Design Distributed approach More difficult to implement Distributes connections (resources) across all devices (easier to scale) Reduces risk of bottlenecks
- 11. Protocol Design Centralized approach Only one device connects to the robot There is no communication between students devices. All handled by one device
- 13. Protocol Design In-Process Send board status to students Handle timeout of actions Monitoring groups progress.
- 14. Protocol Design Post-Process Receive message when group is ready (vote successful) Verify solution correctness and send commands to robot
- 15. Protocol Implementation Message ID Type Timestamp Data { "id": 1, "type": <message_type>, "timestamp": 12345678990", “data": { <structurespecificpertype> } }
- 16. Protocol Implementation Message Types ASSIGN ID READY CHECK READY RESPONSE BOARD STATUS ACTION REQUEST VOTE VOTE RESPONSE*
- 17. Conclusions and Future Work JSON as message format for easier marshalling/unmarshalling Android devices were able to handle multiple connections on centralized approach
- 18. Find a more compact format for messages Expand messages in order to support more features such as assistants monitoring Conclusions and Future Work
- 19. Acknowledgments Research Center for Communication and Information Technologies (Centro de Investigaciones en Tecnologías de la Información y Comunicación, CITIC-UCR), School of Computer Science and Informatics (Escuela de Ciencias de la Computación e Información, ECCI-UCR) Postgraduate Program on Computers and Informatics (Posgrado en Computación e Informática, PCI-UCR) Remote Experimentation Laboratory at the Federal University of Santa Catarina (Laboratório de Experimentação Remota da Universidade Federal de Santa Catarina, RExLab-UFSC).
- 20. Q&A
- 21. ¡Pura Vida! Thank you! Gracias! Obrigado!
Hinweis der Redaktion
- In order to explain better the purpose of the protocol that we created, is important to explain first few concepts. STEM (Science, technology, engineering and mathematics) are important concepts that can be introduced to children in early ages and through technology, specially with robotics. Nowadays, children from 4 to 6 years are digital natives, making easier to them to use technologies during class.
- Based on Johnson & Johnson theory about collaborative learning we can resume it as how we can achieve common goals working together. To accomplish this, is important that every member has its role well defined, feels motivated to work with other team members, knowing that its parts is required to achieve the group’s goal.
- Cesar Collazos divides in three phases the tasks related to collaborative learning. Pre-process where basically everything is set up and defined, for example the size of the groups, roles of each member, activities rules. On In-Process stage, Collazos groups tasks for the students and the facilitator, such as monitoring, test of success criteria, intra-group collaboration, problems resolution. Finally, on Post-Process we have success criteria inspection, closure activities and quality of learning evaluation.
- This concepts are important becuase the protocol that we defined in the paper is part of the results of the ongoing research of Kryscia Ramirez, for her Ph.D thesis. We built an application called “TITIBOTS” a mobile application that allows students to create programs and send them to a robot. On this first approach, every child has access to a tablet and a robot, meaning an interaction 1-1-1. This application helped to test the concepts of using a tablet to program a robot in a very basic approach.
- After the first version, we traveled to Brazil in order to apply TITIBOTS to the students, were we found that we only had access to one robot, and several tablets. This situation made us to move forward to implement a collaborative environment, based on the resources available. We gave a tablet to every student, and group them, so all groups can have access to the same robot. Here is where a mediator is really important, monitoring groups progress and he or she can decide which group send the solution to the robot. Every member of a group is given a sub set of commands, meaning that every student is required if the group wants to find the solution of a given problem. The application presents a Board, where all students can see the current status of the board, therefore, they can interact and discuss about it.
- In order to implement a collaborative environment, we had to define a protocol for the devices to communicate each other. We looked first the pros and cons of a centralized and distributed architecture. We also had to take into account the devices which we have availabe at the moment.
- A distributed approach is Harder to implement since it needs to tackle all the possible flaws of connectivity on different points and propagate the information across all devices 1) how to access the robot, 2) which device is going to send the commands to the robot and what happen during a disconnection.
- A centralized approach relies in one device to communicate the commands to the robot and keeps the other devices updated, meaning that they don’t communicate each other directly. We choose the centralized approach in order to facilitate facilitator and students their interaction, since only one device will handle any error or problem. We took a high risk decision, since we didn’t know if one tablet were able to handle multiple connections at once.
- We defined the protocol following Collazos collaborative learining task division. On pre-process stage, the protocol must provide the ability to setup the groups, define which commands each member will have. Also the timeout for every turn is defined and groups are assemble.
- For the In-Process stage, the protocol must facilitate the “board status” data propagation so every student has the must up-to-date version. It also must handle the timeout for student actions and allow the facilitator to monitor every group progress.
- For the Post-Process, it needs also to allow students let the facilitator know when they think they are ready so he or she can verify the solution correctness and decide if sends or not the solution to the robot.
- The implementation of the protocol consisted on defining the messages sent back and foward between the “master” device and the “students”. The base structure is an ID which is a unique value used to identify every message. The type consists in a constant that helps to categorize the meaning of the message. The timestamp is the time when the message was sent from the device (also used to synchronize clocks across devices using facilitator’s device time) and finally a Data which structure will depend on the message type. We decide to use JSON as message format, since there are plenty of libraries available on Java and Android to marshalling and unmarshalling objects.
- With this structure we could implement the messages based on the definition done during the design.