https://cstwiki.wtb.tue.nl/api.php?action=feedcontributions&user=S127922&feedformat=atomControl Systems Technology Group - User contributions [en]2024-03-29T10:17:19ZUser contributionsMediaWiki 1.39.5https://cstwiki.wtb.tue.nl/index.php?title=File:EMC17-G3_CC_Align.gif&diff=44009File:EMC17-G3 CC Align.gif2017-06-21T10:46:18Z<p>S127922: </p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Corridor_Challenge&diff=44008Embedded Motion Control 2017 Group 3 / Corridor Challenge2017-06-21T10:46:04Z<p>S127922: </p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.<br />
<br />
[[File:EMC17-G3_CC_Corridor.png|thumb|250px|right|Figure 1: Typical Corridor]]<br />
This page is about the design made from the initial design up to the moment of the the Corridor Challenge. For this challenge is PICO should drive itself through a corridor which is constructed with parallel walls, detect the first exit and take a turn. First the design steps are described, followed by notable algorithms used and there software implementation and concluding with the functioning of the code in the simulation. In figure 1, a typical corridor used in the Corridor Challenge is visible, however, the opening could also be at the left side.<br />
<br />
== Design steps == <br />
<br />
From the requirements we designed we wanted PICO to never hit any walls, but also prevent PICO from going into deadlocks. With this decision we excluded the use of the potential field, where the walls give a distance dependent rejecting force towards PICO. Although this is a very robust way to avoid walls, it will have a lot of deadlocks problems (mostly for the maze). In stead we used a PID controller to keep PICO always in the middle of a corridor, which is more in line with the Pledge algorithm that uses wall following. We used the filtered information from the laser data for this.<br />
<br />
This controller only operates in the actual corridors, when PICO moved out of a corridor, PID is be turned off and he would turn 90 degrees (left or right). After turning, PICO would move back into the corridor, back in the corridor the PID controller turn back on.<br />
<br />
Because turning on odometry data gave no guarantees about turned angle in real life, we couldn't just turn without looking. By use of a corner detection, we could PICO align in the middle of the new corridor after turning.<br />
<br />
== Notable Algorithms == <br />
<br />
In this section a few algorithms used for the corridor challenge are described, together with there software implementation, to show how our code differentiated from the other groups. <br />
<br />
=== Initial Alignment === <br />
<br />
[[File:EMC17-G3_CC_Align.gif|thumb|250px|right|Figure 2]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Corridor_Challenge&diff=43987Embedded Motion Control 2017 Group 3 / Corridor Challenge2017-06-21T10:20:51Z<p>S127922: /* Design steps */</p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.<br />
<br />
[[File:EMC17-G3_CC_Corridor.png|thumb|250px|right|Figure 1: Typical Corridor]]<br />
This page is about the design made from the initial design up to the moment of the the Corridor Challenge. For this challenge is PICO should drive itself through a corridor which is constructed with parallel walls, detect the first exit and take a turn. First the design steps are described, followed by notable algorithms used and there software implementation and concluding with the functioning of the code in the simulation. In figure 1, a typical corridor used in the Corridor Challenge is visible, however, the opening could also be at the left side.<br />
<br />
== Design steps == <br />
<br />
From the requirements we designed we wanted PICO to never hit any walls, but also prevent PICO from going into deadlocks. With this decision we excluded the use of the potential field, where the walls give a distance dependent rejecting force towards PICO. Although this is a very robust way to avoid walls, it will have a lot of deadlocks problems (mostly for the maze). In stead we used a PID controller to keep PICO always in the middle of a corridor, which is more in line with the Pledge algorithm that uses wall following. We used the filtered information from the laser data for this.<br />
<br />
This controller only operates in the actual corridors, when PICO moved out of a corridor, PID is be turned off and he would turn 90 degrees (left or right). After turning, PICO would move back into the corridor, back in the corridor the PID controller turn back on.<br />
<br />
Because turning on odometry data gave no guarantees about turned angle in real life, we couldn't just turn without looking. By use of a corner detection, we could PICO align in the middle of the new corridor after turning.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Corridor_Challenge&diff=43983Embedded Motion Control 2017 Group 3 / Corridor Challenge2017-06-21T10:18:18Z<p>S127922: /* Design steps */</p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.<br />
<br />
[[File:EMC17-G3_CC_Corridor.png|thumb|250px|right|Figure 1: Typical Corridor]]<br />
This page is about the design made from the initial design up to the moment of the the Corridor Challenge. For this challenge is PICO should drive itself through a corridor which is constructed with parallel walls, detect the first exit and take a turn. First the design steps are described, followed by notable algorithms used and there software implementation and concluding with the functioning of the code in the simulation. In figure 1, a typical corridor used in the Corridor Challenge is visible, however, the opening could also be at the left side.<br />
<br />
== Design steps == <br />
<br />
From the requirements we designed we wanted PICO to never hit any walls, but also prevent PICO from going into deadlocks. With this decision we excluded the use of the potential field, where the walls give a distance dependent rejecting force towards PICO. Although this is a very robust way to avoid walls, it will have a lot of deadlocks problems (mostly for the maze). In stead we used a PID controller to keep PICO always in the middle of a corridor, which is more in line with the Pledge algorithm that uses wall following.<br />
<br />
This controller only operates in the actual corridors, when PICO moved out of a corridor, PID is be turned off and he would turn 90 degrees (left or right). After turning, PICO would move back into the corridor, back in the corridor the PID controller turn back on.<br />
<br />
Because turning on odometry data gave no guarantees about turned angle in real life, we couldn't just turn without looking.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Corridor_Challenge&diff=43982Embedded Motion Control 2017 Group 3 / Corridor Challenge2017-06-21T10:17:34Z<p>S127922: </p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.<br />
<br />
[[File:EMC17-G3_CC_Corridor.png|thumb|250px|right|Figure 1: Typical Corridor]]<br />
This page is about the design made from the initial design up to the moment of the the Corridor Challenge. For this challenge is PICO should drive itself through a corridor which is constructed with parallel walls, detect the first exit and take a turn. First the design steps are described, followed by notable algorithms used and there software implementation and concluding with the functioning of the code in the simulation. In figure 1, a typical corridor used in the Corridor Challenge is visible, however, the opening could also be at the left side.<br />
<br />
== Design steps == <br />
<br />
From the requirements we designed we wanted PICO to never hit any walls, but also prevent PICO from going into deadlocks. With this decision we excluded the use of the potential field, where the walls give a distance dependent rejecting force towards PICO. Although this is a very robust way to avoid walls, it will have a lot of deadlocks problems. In stead we used a PID controller to keep PICO always in the middle of a corridor, which is more in line with the Pledge algorithm that uses wall following.<br />
<br />
This controller only operates in the actual corridors, when PICO moved out of a corridor, PID is be turned off and he would turn 90 degrees (left or right). After turning, PICO would move back into the corridor, back in the corridor the PID controller turn back on.<br />
<br />
Because turning on odometry data gave no guarantees about turned angle in real life, we couldn't just turn without looking.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=File:EMC17-G3_CC_Corridor.png&diff=43976File:EMC17-G3 CC Corridor.png2017-06-21T09:55:38Z<p>S127922: uploaded a new version of "File:EMC17-G3 CC Corridor.png"</p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=File:EMC17-G3_CC_Corridor.png&diff=43975File:EMC17-G3 CC Corridor.png2017-06-21T09:53:54Z<p>S127922: </p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Corridor_Challenge&diff=43974Embedded Motion Control 2017 Group 3 / Corridor Challenge2017-06-21T09:53:34Z<p>S127922: </p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.<br />
<br />
[[File:EMC17-G3_CC_Corridor.png|thumb|250px|right|Initial Control Hierarchy]]<br />
This page is about the design made from the initial design up to the moment of the the Corridor Challenge. For this challenge is PICO should drive itself through a corridor which is constructed with parallel walls, detect the first exit and take a turn. First the design steps are described, followed by notable algorithms used and there software implementation and concluding with the functioning of the code in the simulation.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Corridor_Challenge&diff=43973Embedded Motion Control 2017 Group 3 / Corridor Challenge2017-06-21T09:52:30Z<p>S127922: </p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.<br />
<br />
This page is about the design made from the initial design up to the moment of the the Corridor Challenge. For this challenge is PICO should drive itself through a corridor which is constructed with parallel walls, detect the first exit and take a turn. First the design steps are described, followed by notable algorithms used and there software implementation and concluding with the functioning of the code in the simulation.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3&diff=43594Embedded Motion Control 2017 Group 32017-06-20T13:58:40Z<p>S127922: </p>
<hr />
<div>{| border="1" cellpadding="5" cellspacing="0" style="float:right;"<br />
|+ ''' Group Members '''<br />
! TU/e Number<br />
! Name<br />
! E-mail<br />
|- <br />
| 1032791<br />
| Ayisha wafa <br />
| ayisha.wafa@student.tue.nl<br />
|-<br />
| 1033848<br />
| Aparnasri Sekar<br />
| a.sekar@student.tue.nl <br />
|-<br />
| 0742670<br />
| Nick Peters<br />
| n.k.peters@student.tue.nl<br />
|-<br />
| 0811091<br />
| Jelte Borsboom<br />
| j.j.borsboom@student.tue.nl <br />
|-<br />
| Tutor<br />
| Wouter Kuijpers<br />
| w.j.p.kuijpers@tue.nl<br />
|-<br />
|}<br />
<br />
This is the WIKI page of group 3 of the [[Embedded Motion Control 2017 | Embedded Motion Control]] course of 2017. The Team members and their contact information are found on the right side of this page. On this page, we will discuss the design and implementation choices we have made during this course and reflect on the results.<br />
<br />
<br />
__TOC__<br />
<br />
= Design =<br />
<br />
The Initial Design was the design step to identify the requirements and the higher level design are bulit over it for the Corridor and Maze Challenges.<br />
<br />
[[File:EMC17-G3_Control.png|thumb|250px|right|Initial Control Hierarchy]]<br />
The following functions were conceived, as a starting point for further design:<br />
# The ''' Path Finding ''' Supervisor, responsible for finding the path PICO should follow.<br />
# The ''' Wall Detection ''', responsible for finding information about the walls around PICO.<br />
# The ''' Motion ''' Supervisor, responsible for making the higher level movements of PICO.<br />
# The ''' Door''' Supervisor, responsible for taking over the system in a system with a (potential) door.<br />
# The ''' Actuator ''' Supervisor, responsible for the actual setting of all PICO's actuators.<br />
# The ''' Main Loop''', the actual program, calling every supervisor once every time step (Time-division multiplexing). <br />
<br />
The interactions between these functionalities are explained in the [[Embedded Motion Control 2017 Group 3 / Initial Design| Initial Design page]], together with more in-depth information about this design step.<br />
== Corridor Design ==<br />
<br />
For the corridor challenge, implementing the Door Supervisor was not necessary yet. The Actuator Supervisor was found redundant and was therefore included in the Motion Supervisor. The three remaining supervisors were designed separately.<br />
=== Wall Detection ===<br />
The Wall Detection had the responsibility to give information about the world around PICO. After the complete design step, the functionalities of the Wall Detection during the Corridor Challenge included:<br />
# It calculated the initial angle to the walls (not actually used, because redundant for corridor Challenge).<br />
# It calculated the filtered distance to the right and left wall, assuming PICO was aligned parallel to the walls.<br />
# It made the conclusion if any of PICO's known sides (left, front and right) there is space for PICO to move in this direction.<br />
# During turning the corner points of the new corner were found using the Laser Data.<br />
<br />
=== Path Finding === <br />
During the Corridor Challenge the Path Finding used the space information of the Wall Detection to find the corridor to turn in. <br />
<br />
If this supervisor detected an open space either left or right it would:<br />
# Alert the Motion Supervisor to go to a turning state.<br />
# Alert the Wall Detection to detect corner points for the new corridor.<br />
<br />
=== Motion Supervisor ===<br />
The Motion Supervisor had the responsibility to do all the movements using the information from Wall Detection and Path Finding. After the complete design step, the functionalities of the Motion Supervisor during the Corridor Challenge included:<br />
# Stabilizing PID controller to keep the left and right wall at equal size from PICO, keeping PICO in the middle of the corridor at all times.<br />
# Move in the middle of a new corridor.<br />
# Move straight forward when no walls were detected in any of PICO's known sides.<br />
# Making a 90 degrees turn, either left of right. <br />
<br />
The software implementation and more in-depth information about this design step are given in the [[Embedded Motion Control 2017 Group 3 / Corridor Challenge | Corridor Design page]], together with simulation results throughout the process.<br />
<br />
== Maze Design ==<br />
<br />
For the Maze Challenge big changes were made to the approach of our program. Besides that the Wall Detection was renamed to the World Interpreter Supervisor to better reflect its functionality. The Door Supervisor was also implemented in this design step. The four supervisors were redesigned to:<br />
<br />
=== World Interpreter === <br />
<br />
The World Interpreter was designed as a virtual circle around PICO. After the complete design step, the functionalities of the World Interpreter during the Maze Challenge included:<br />
# Find the closest distance that is inside the right side of the virtual circle, including the angle with respect to PICO. <br />
# Detect a dead end and with that a potential door.<br />
# Count all the 90 degrees corners that PICO made.<br />
# Find obstacles in front of PICO (to prevent collisions).<br />
<br />
=== Path Finding === <br />
<br />
For the Path Finding the Pledge Algorithm was implemented using the difference between the left and right corners counted by the World Interpreter. Path finding could be in 2 states:<br />
# Right-wall following, if difference is non-zero or an obstacle is in front of PICO.<br />
# Moving straight forward, if difference is zero, until a obstacle is in front of PICO.<br />
<br />
=== Motion Supervisor ===<br />
<br />
The Motion Supervisor was redesigned to create continuous turning behaviour. After the complete design step, the functionalities of the Motion Supervisor during the Maze Challenge included:<br />
# Stabilizing PID controller to keep the smallest right distance inside the virtual circle at a pre-set distance (inside the virtual circle) from PICO.<br />
# Stabilizing PID controller (separate) to keep the angle of PICO to the smallest point always around 0.5 PI radians right of PICO.<br />
# Slowing down if there are obstacles in front of PICO.<br />
<br />
=== Door Handling Supervisor ===<br />
<br />
The Door Handling was designed to stop everything and do the Door procedure if a potential door is detected. After the procedure, normal operation is resumed.<br />
The functionalities were:<br />
# Ring the doorbell<br />
# Stop all other supervisors from doing anything<br />
# Count the time PICO has been waiting.<br />
# Prevent ringing for the same dead end twice.<br />
<br />
The software implementation and more in-depth information about this design step are given in the [[Embedded Motion Control 2017 Group 3 / Maze Design | Maze Design page]], together with simulation results throughout the process.<br />
<br />
= Results = <br />
During the little testing hours we quickly found out that simulation is nothing in respect to real life operation. It took us for instance quite a long time to figure out that the inertia of PICO was the reason behind the overshoot problems we encountered during testing.<br />
<br />
Our strategy was to test our program to as many different corridors / mazes as possible. But that didn't gave any guarantees that it would work in real life. Every iteration step for the code took a week, resulting in very slow progress. <br />
<br />
== Corridor Challenge == <br />
<br />
In the corridor Challenge, we crashed PICO into a wall two times. Which was of course sad, but we tried to learn from this experience the best we could. We will discuss the positive and the less positive points of the behaviour of our program:<br />
<br />
=== Positive === <br />
<br />
The PID control of keeping PICO in the middle worked very robust, it only oscillated a little bit and it was certainly working as designed in the corridor. We can only say that PICO did wonderful up to the moment it tried to do a corner. <br />
<br />
=== Negative ===<br />
<br />
The problem happened at the moment PICO wanted to make a turn. Reality and simulation were not the same at this situation. <br />
This is best explained in a animation, in figure XX a, we see the simulation as it was supposed to go, as explained further in the [[Embedded Motion Control 2017 Group 3 / Corridor Challenge | Corridor Design page]] and in figure XX b, we made an animation of the behaviour that was seen during the Corridor Challenge.<br />
<br />
The cause of the crash can be traced back to the PID contoller, unlike in simulation, PICO was pushed inside by the last PID action. This put PICO in a different state than we anticipated, our code still tried to find the corner points even though the were behind PICO. The results of the corner detection were of course meaningless and this caused the crash of PICO to the wall.<br />
<br />
The problem of our code was that we made assumptions about the state it is in. This resulted in non-robustness to changes happening in real life, which resulted in a crash itself. Besides that, we turned only on odometry sensor, which in itself is not a robust solution.<br />
<br />
=== Conclusion === <br />
<br />
We concluded that major changes should made to the design of the code, we therefore redesigned our controller, further information on that can be found in [[Embedded Motion Control 2017 Group 3 / Maze Design | Maze Design page]]. The basic idea was to do better state estimation and go back to one controller that can handle all the states.<br />
<br />
== Maze Challenge ==<br />
<br />
During the maze challenge the maze visible in figure XX was used. The maze was a bit bigger than originally anticipated, but we had great confidence that we could finish this maze. Using the pledge algorithm in our heads we saw that we could easily solve this. The correct way pico had to go is visible in figure XX, first we discuss the behaviour in simulation, followed by the real challenge.<br />
<br />
=== Simulation === <br />
<br />
Looking at the simulation, we see that PICO walks like it is supposed to go, going trough the maze effortless. However, PICO is very eager to find the door and it tries to this many times. We knew from testing that in an actual maze, this happens a lot less and decided to keep it this way.<br />
<br />
=== Real Maze ===<br />
<br />
During the real challenge, we only had one good try. The first time PICO started the counted started with an initial value which wasn't zero and therefore PICO couldn't detach from the inner loop. We immediately reset PICO and retried, the mysterious error luckily only happened once.<br />
<br />
Sadly, in the second attempt, we did not make it to the finish-line either. This was due to a number of reasons, but in the end we failed on the time-limit. PICO was nearing the finish line when the 5 minutes deadline was passed. PICO did move effortless trough the maze, but to leave the outer loop of the maze, PICO had to go all the way around the right side of the maze, visible in figure XX. <br />
<br />
The reason can be tracked back to the turn counter, the 'desired' direction of PICO was changes from North to West, between the origin and point A, resulting in detaching from the wall at point A, instead of a right turn. Although this was inconvenient, we know the pledge algorithm can still find the exit, but, unlucky for us, with the 'desired' direction to the west, the pledge path to the exit is a very sub-optimal solution.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3&diff=42130Embedded Motion Control 2017 Group 32017-06-16T18:11:36Z<p>S127922: </p>
<hr />
<div>{| border="1" cellpadding="5" cellspacing="0" style="float:right;"<br />
|+ ''' Group Members '''<br />
! TU/e Number<br />
! Name<br />
! E-mail<br />
|- <br />
| 1032791<br />
| Ayisha wafa <br />
| ayisha.wafa 'at' student.tue.nl<br />
|-<br />
| 0980790<br />
| Aparnasri Sekar<br />
| a.sekar 'at' student.tue.nl <br />
|-<br />
| 0976940<br />
| Nick Peters<br />
| n.peters 'at' student.tue.nl<br />
|-<br />
| 0811091<br />
| Jelte Borsboom<br />
| j.j.borsboom 'at'student.tue.nl <br />
|-<br />
| Tutor<br />
| Wouter Kuijpers<br />
| w.j.p.kuijpers 'at' tue.nl<br />
|-<br />
|}<br />
<br />
This is the WIKI page of group 3 of the Embedded Motion Control. The Team members and their contact information are found on the right side of this page. On this page we will discuss the design and implementation choices we have made during this course and reflect on the results.<br />
<br />
<br />
__TOC__<br />
<br />
= Design =<br />
<br />
The Initial Design was the design step to identify the requirement and the higher level design used for the Corridor and Maze Challenge.<br />
<br />
[[File:EMC17-G3_Control.png|thumb|250px|right|Initial Control Hierarchy]]<br />
The following functions were conceived, as a starting point for further design:<br />
# The ''' Path Finding ''' Supervisor, reponsible for finding the path PICO should follow.<br />
# The ''' Wall Detection ''', responsible for finding information about the walls around PICO.<br />
# The ''' Motion ''' Supervisor, responsible for making the higher level movements of PICO.<br />
# The ''' Door''' Supervisor, responsible for taking over the system in a system with a (potential) door.<br />
# The ''' Actuater ''' Supervisor, responsible for the actual setting of all PICO's actuators.<br />
# The ''' Main Loop''', the actual program, calling every supervisor once every timestep (Time-division multiplexing). <br />
<br />
The interactions between these functionalities are explained in the [[Embedded Motion Control 2017 Group 3 / Initial Design| Initial Design page]], together with more in-depth information about this design step.<br />
== Corridor Design ==<br />
<br />
For the corridor challenge, implementing the Door Supervisor was not necessary yet. The Actuator Supervisor was found redundant and was therefore included in the Motion Supervisor. The three remaining supervisors were designed separately.<br />
=== Wall Detection ===<br />
The Wall Detection had the responsibility to give information about the world around PICO. After the complete design step, the functionalities of the Wall Detection during the Corridor Challenge included:<br />
# It calculated the initial angle to the walls (not actually used, because redundant for corridor Challenge).<br />
# It calculated the filtered distance to the right and left wall, assuming PICO was aligned parallel to the walls.<br />
# It made the conclusion if any of PICO's known sides (left, front and right) there is space for PICO to move in this direction.<br />
# During turning the corner points of the new corner were found using the Laser Data.<br />
<br />
=== Path Finding === <br />
During the Corridor Challenge the Path Finding used the space information of the Wall Detection to find the corridor to turn in. <br />
<br />
If this supervisor detected an open space either left or right it would:<br />
# Alert the Motion Supervisor to go to a turning state.<br />
# Alert the Wall Detection to detect corner points for the new corridor.<br />
<br />
=== Motion Supervisor ===<br />
The Motion Supervisor had the responsibility to do all the movements using the information from Wall Detection and Path Finding. After the complete design step, the functionalities of the Motion Supervisor during the Corridor Challenge included:<br />
# Stabilizing PID controller to keep the left and right wall at equal size from PICO, keeping PICO in the middle of the corridor at all times.<br />
# Move in the middle of a new corridor.<br />
# Move straight forward when no walls were detected in any of PICO's known sides.<br />
# Making a 90 degrees turn, either left of right. <br />
<br />
The software implementation and more in-depth information about this design step are given in the [[Embedded Motion Control 2017 Group 3 / Corridor Challenge | Corridor Design page]], together with simulation results throughout the process.<br />
<br />
== Maze Design ==<br />
<br />
For the Maze Challenge big changes were made to the approach of our program. Besides that the Wall Detection was renamed to the World Interpreter Supervisor to better reflect its functionality. The Door Supervisor was also implemented in this design step. The four supervisors were redesigned to:<br />
<br />
=== World Interpreter === <br />
<br />
The World Interpreter was designed as a virtual circle around PICO. After the complete design step, the functionalities of the World Interpreter during the Maze Challenge included:<br />
# Find the closest distance that is inside the right side of the virtual circle, including the angle with respect to PICO. <br />
# Detect a dead end and with that a potential door.<br />
# Count all the 90 degrees corners that PICO made.<br />
# Find obstacles in front of PICO (to prevent collisions).<br />
<br />
=== Path Finding === <br />
<br />
For the Path Finding the Pledge Algorithm was implemented using the difference between the left and right corners counted by the World Interpreter. Path finding could be in 2 states:<br />
# Right-wall following, if difference is non-zero or an obstacle is in front of PICO.<br />
# Moving straight forward, if difference is zero, until a obstacle is in front of PICO.<br />
<br />
=== Motion Supervisor ===<br />
<br />
The Motion Supervisor was redesigned to create continuous turning behaviour. After the complete design step, the functionalities of the Motion Supervisor during the Maze Challenge included:<br />
# Stabilizing PID controller to keep the smallest right distance inside the virtual circle at a pre-set distance (inside the virtual circle) from PICO.<br />
# Stabilizing PID controller (separate) to keep the angle of PICO to the smallest point always around 0.5 PI radians right of PICO.<br />
# Slowing down if there are obstacles in front of PICO.<br />
<br />
=== Door Handling Supervisor ===<br />
<br />
The Door Handling was designed to stop everything and do the Door procedure if a potential door is detected. After the procedure, normal operation is resumed.<br />
The functionalities were:<br />
# Ring the doorbell<br />
# Stop all other supervisors from doing anything<br />
# Count the time PICO has been waiting.<br />
# Prevent ringing for the same dead end twice.<br />
<br />
The software implementation and more in-depth information about this design step are given in the [[Embedded Motion Control 2017 Group 3 / Maze Design | Maze Design page]], together with simulation results throughout the process. <br />
<br />
= Results = <br />
During the little testing hours we quickly found out that simulation is nothing in respect to real life operation. It took us for instance quite a long time to figure out that the inertia of PICO was the reason behind the overshoot problems we encountered during testing.<br />
<br />
Our strategy was to test our program to as many different corridors / mazes as possible. But that didn't gave any guarantees that it would work in real life. Every iteration step for the code took a week, resulting in very slow progress. <br />
<br />
== Corridor Challenge == <br />
<br />
In the corridor Challenge, we crashed PICO into a wall two times. Which was of course sad, but we tried to learn from this experience the best we could. We will discuss the positive and the less positive points of the behaviour of our program:<br />
<br />
=== Positive === <br />
The <br />
<br />
== Maze Challenge ==</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3&diff=42129Embedded Motion Control 2017 Group 32017-06-16T18:07:42Z<p>S127922: </p>
<hr />
<div>{| border="1" cellpadding="5" cellspacing="0" style="float:right;"<br />
|+ ''' Group Members '''<br />
! TU/e Number<br />
! Name<br />
! E-mail<br />
|- <br />
| 1032791<br />
| Ayisha wafa <br />
| ayisha.wafa 'at' student.tue.nl<br />
|-<br />
| 0980790<br />
| Aparnasri Sekar<br />
| a.sekar 'at' student.tue.nl <br />
|-<br />
| 0976940<br />
| Nick Peters<br />
| n.peters 'at' student.tue.nl<br />
|-<br />
| 0811091<br />
| Jelte Borsboom<br />
| j.j.borsboom 'at'student.tue.nl <br />
|-<br />
| Tutor<br />
| Wouter Kuijpers<br />
| w.j.p.kuijpers 'at' tue.nl<br />
|-<br />
|}<br />
<br />
This is the WIKI page of group 3 of the Embedded Motion Control. The Team members and their contact information are found on the right side of this page. On this page we will discuss the design and implementation choices we have made during this course and reflect on the results.<br />
<br />
<br />
__TOC__<br />
<br />
= Design =<br />
<br />
== Initial Design ==<br />
The Initial Design was the design step to identify the requirement and the higher level design used for the Corridor and Maze Challenge.<br />
<br />
[[File:EMC17-G3_Control.png|thumb|250px|right|Initial Control Hierarchy]]<br />
The following functions were conceived, as a starting point for further design:<br />
# The ''' Path Finding ''' Supervisor, reponsible for finding the path PICO should follow.<br />
# The ''' Wall Detection ''', responsible for finding information about the walls around PICO.<br />
# The ''' Motion ''' Supervisor, responsible for making the higher level movements of PICO.<br />
# The ''' Door''' Supervisor, responsible for taking over the system in a system with a (potential) door.<br />
# The ''' Actuater ''' Supervisor, responsible for the actual setting of all PICO's actuators.<br />
# The ''' Main Loop''', the actual program, calling every supervisor once every timestep (Time-division multiplexing). <br />
<br />
The interactions between these functionalities are explained in the [[Embedded Motion Control 2017 Group 3 / Initial Design| Initial Design page]], together with more in-depth information about this design step.<br />
== Corridor Design ==<br />
<br />
For the corridor challenge, implementing the Door Supervisor was not necessary yet. The Actuator Supervisor was found redundant and was therefore included in the Motion Supervisor. The three remaining supervisors were designed separately.<br />
=== Wall Detection ===<br />
The Wall Detection had the responsibility to give information about the world around PICO. After the complete design step, the functionalities of the Wall Detection during the Corridor Challenge included:<br />
# It calculated the initial angle to the walls (not actually used, because redundant for corridor Challenge).<br />
# It calculated the filtered distance to the right and left wall, assuming PICO was aligned parallel to the walls.<br />
# It made the conclusion if any of PICO's known sides (left, front and right) there is space for PICO to move in this direction.<br />
# During turning the corner points of the new corner were found using the Laser Data.<br />
<br />
=== Path Finding === <br />
During the Corridor Challenge the Path Finding used the space information of the Wall Detection to find the corridor to turn in. <br />
<br />
If this supervisor detected an open space either left or right it would:<br />
# Alert the Motion Supervisor to go to a turning state.<br />
# Alert the Wall Detection to detect corner points for the new corridor.<br />
<br />
=== Motion Supervisor ===<br />
The Motion Supervisor had the responsibility to do all the movements using the information from Wall Detection and Path Finding. After the complete design step, the functionalities of the Motion Supervisor during the Corridor Challenge included:<br />
# Stabilizing PID controller to keep the left and right wall at equal size from PICO, keeping PICO in the middle of the corridor at all times.<br />
# Move in the middle of a new corridor.<br />
# Move straight forward when no walls were detected in any of PICO's known sides.<br />
# Making a 90 degrees turn, either left of right. <br />
<br />
The software implementation and more in-depth information about this design step are given in the [[Embedded Motion Control 2017 Group 3 / Corridor Challenge | Corridor Design page]], together with simulation results throughout the process.<br />
<br />
== Maze Design ==<br />
<br />
For the Maze Challenge big changes were made to the approach of our program. Besides that the Wall Detection was renamed to the World Interpreter Supervisor to better reflect its functionality. The Door Supervisor was also implemented in this design step. The four supervisors were redesigned to:<br />
<br />
=== World Interpreter === <br />
<br />
The World Interpreter was designed as a virtual circle around PICO. After the complete design step, the functionalities of the World Interpreter during the Maze Challenge included:<br />
# Find the closest distance that is inside the right side of the virtual circle, including the angle with respect to PICO. <br />
# Detect a dead end and with that a potential door.<br />
# Count all the 90 degrees corners that PICO made.<br />
# Find obstacles in front of PICO (to prevent collisions).<br />
<br />
=== Path Finding === <br />
<br />
For the Path Finding the Pledge Algorithm was implemented using the difference between the left and right corners counted by the World Interpreter. Path finding could be in 2 states:<br />
# Right-wall following, if difference is non-zero or an obstacle is in front of PICO.<br />
# Moving straight forward, if difference is zero, until a obstacle is in front of PICO.<br />
<br />
=== Motion Supervisor ===<br />
<br />
The Motion Supervisor was redesigned to create continuous turning behaviour. After the complete design step, the functionalities of the Motion Supervisor during the Maze Challenge included:<br />
# Stabilizing PID controller to keep the smallest right distance inside the virtual circle at a pre-set distance (inside the virtual circle) from PICO.<br />
# Stabilizing PID controller (separate) to keep the angle of PICO to the smallest point always around 0.5 PI radians right of PICO.<br />
# Slowing down if there are obstacles in front of PICO.<br />
<br />
=== Door Handling Supervisor ===<br />
<br />
The Door Handling was designed to stop everything and do the Door procedure if a potential door is detected. After the procedure, normal operation is resumed.<br />
The functionalities were:<br />
# Ring the doorbell<br />
# Stop all other supervisors from doing anything<br />
# Count the time PICO has been waiting.<br />
# Prevent ringing for the same dead end twice.<br />
<br />
The software implementation and more in-depth information about this design step are given in the [[Embedded Motion Control 2017 Group 3 / Maze Design | Maze Design page]], together with simulation results throughout the process. <br />
<br />
= Results = <br />
During the little testing hours we quickly found out that simulation is nothing in respect to real life operation. It took us for instance quite a long time to figure out that the inertia of PICO was the reason behind the overshoot problems we encountered during testing.<br />
<br />
Our strategy was to test our program to as many different corridors / mazes as possible. But that didn't gave any guarantees that it would work in real life. Every iteration step for the code took a week, resulting in very slow progress. <br />
<br />
== Corridor Challenge == <br />
<br />
In the corridor Challenge, we crashed PICO into a wall two times. Which was of course sad, but we tried to learn from this experience the best we could. We will discuss the positive and the less positive points of the behaviour of our program:<br />
<br />
=== Positive === <br />
The <br />
<br />
== Maze Challenge ==</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=File:EMC17-G3_Control.png&diff=42113File:EMC17-G3 Control.png2017-06-16T16:02:12Z<p>S127922: </p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Corridor_Challenge&diff=42112Embedded Motion Control 2017 Group 3 / Corridor Challenge2017-06-16T15:15:27Z<p>S127922: </p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.<br />
<br />
==The Corridor Challenge ==<br />
The challenge is that PICO should drive itself through a corridor which is constructed with parallel walls, detect the first exit and take a turn. The Laser data (LRF) is used to detect the wall and space in corridor. This data is communicated among other supervisors such that the decision of turning at first exit is made by the path finding supervisor which then instructs the motion supervisor to move accordingly.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Corridor_Challenge&diff=42111Embedded Motion Control 2017 Group 3 / Corridor Challenge2017-06-16T15:14:55Z<p>S127922: Created page with 'This page is part of the Embedded Motion Control Group 3 of 2017.'</p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Initial_Design&diff=42110Embedded Motion Control 2017 Group 3 / Initial Design2017-06-16T15:12:32Z<p>S127922: </p>
<hr />
<div>This page is part of the Embedded Motion Control [[Embedded_Motion_Control_2017_Group_3 | Group 3]] of 2017.<br />
<br />
==Documents==<br />
The initial design document [[file:Emc-design-specification.pdf]] briefly indicates the approach taken towards the problem of solving the maze by the PICO robot, the algorithm used and the system design.<br />
<br />
The slides for the initial design presentation can be found here: [[File:group3_2017_Initial_design_presentation.pdf]]<br />
<br />
==Overview==<br />
There are 2 main goals for the PICO robot. <br />
# Corridor competition: To navigate through a corridor and take the first exit without colliding with the walls.<br />
# Maze competition: To solve and exit an unknown maze through a door without colliding with the walls.<br />
<br />
The overall design of the project is mentioned in the following section:<br />
# Requirements<br />
# Specifications<br />
# Functions<br />
# Components<br />
# Interfaces<br />
<br />
==Requirements==<br />
The following requirements are listed for the robot (PICO) to complete maze successfully:<br />
# PICO may not touch the walls or any other obstacle in the maze at any time<br />
# PICO must operate fully autonomous (i.e. without input from the team)<br />
# PICO may not be idle for more than 3 seconds from the start of program unless it has passed the exit<br />
# PICO must be able to detect available space using the Laser Range Finder (LRF) and move to the detected space according to the motion planning algorithm<br />
# PICO must be able to find the exit in finite time (≤ 7 sec for maze and ≤ 5 sec for corridor.)<br />
# PICO must be able to detect the objects (dead ends) that have a high probability of being a door<br />
# PICO must be able to open the door in the maze and pass through it<br />
<br />
==Functions==<br />
The functions are separate modules called supervisors where, the supervisor unknown of what is inside the other supervisor. This approach makes software architecture simpler, it is also easier to edit and error count will be less since no direct interaction of modules. Supervisors are listed below:<br />
<br />
# Path-finding Supervisor<br />
# Door Handling Supervisor<br />
# Wall / Path Detection<br />
# Motion Supervisor<br />
# Actuator Supervisor<br />
<br />
===Path-finding Supervisor===<br />
1-'''Pledge Algorithm:'''<br />
Takes in the extracted wall information as input and sets a movement goal for the PICO and move towards it. This algorithm is useful when the robot is challenged to solve loop inside the maze. The algorithm functions as a continuous loop. (Maze challenge)<br />
<br />
2- '''Cornering:'''<br />
Take the corner using the wall information as input. (Corridor challenge)<br />
<br />
===Door Supervisor===<br />
<br />
1-'''Ring Bell:'''<br />
Ring the bell if it detect the door possible deadends<br />
<br />
2-'''Standstill:'''<br />
Wait for 5 sec to for the door openingsequence.<br />
<br />
===Wall / Path Detection===<br />
<br />
1-'''Read LRF data:'''<br />
Gets raw data from the LRF sensor<br />
<br />
2-'''Filter LRF data:'''<br />
Reduces noise from raw LRF data and splits it into 3 directions (left, right and front).<br />
<br />
3-'''Transform data:'''<br />
Calculate one distance approximation for the 3 directions.<br />
<br />
4-'''Possiblity checker:'''<br />
Calculate for all directions if movement in that direction is possible, taking a ‘safe’ zone around PICO into account.<br />
<br />
===Motion Supervisor===<br />
<br />
1-'''Position stabilizing:'''<br />
Feedback loop that keep PICO approximately in the center of the corridor by implementing a feedback controller for the distance to the walls on the left and right of the robot.<br />
<br />
2-'''Turn Corner:'''<br />
Make a 90 degree turn either on left or on right<br />
<br />
===Actuator Supervisor===<br />
<br />
1-'''Steady PICO:'''<br />
Keep the front of the PICO aligned to the direction of movement.<br />
<br />
2-'''Omniwheels handeling:'''<br />
Set speed and angle of Omniwheels<br />
<br />
==Interfaces==<br />
The interfaces are defined as the movement/flow of data between the functions that are defined in above section.<br />
The different interfaces are described below.<br />
<br />
1- Sending information about current state, which is the distance to walls at -90 degrees, 0 degrees and 90 degrees from the center point and whether it has potential from moving forward and turning left or right. <''Struct with float values and booleans''>.<br />
<br />
2- Forward information about potential movement.<''Struct of Boolean''>.<br />
<br />
3- Forward information about wall distances.<''Struct of floats''>.<br />
<br />
4- Turning command, which is either 1 (turning left) or 2(turning right). <''integer''>.<br />
<br />
5- Send information about the possibility of a door.<''Boolean''>.<br />
<br />
6- Confirmation that door handling is finished <''Boolean''>.<br />
<br />
7- Setting the values for actuator.<''Struct of floats''><br />
<br />
==Components==<br />
<br />
1- '''Sensors:''' Laser Range Finder (LRF), Odometry (Wheel Encoder).<br />
<br />
2- '''Holonomic base (omni-wheels):''' Maximum translational speed of 0.5 m/s , Max angular speed of 1.2 rad/s.<br />
<br />
3- '''Embedded platform''' Computer with Ubuntu 14.04 on an Intel i7 (other specifications are unknown)<br />
<br />
4- '''Bell:''' To produce sound from PICO so as to open the door.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017_Group_3_/_Initial_Design&diff=42109Embedded Motion Control 2017 Group 3 / Initial Design2017-06-16T15:11:36Z<p>S127922: Created page with 'This page is part of the Embedded Motion Control Group 3 of 2017. ==Documents== The initial design document file:Emc-design-specification.pdf briefly indicates the appro…'</p>
<hr />
<div>This page is part of the Embedded Motion Control [[Group 3]] of 2017.<br />
<br />
==Documents==<br />
The initial design document [[file:Emc-design-specification.pdf]] briefly indicates the approach taken towards the problem of solving the maze by the PICO robot, the algorithm used and the system design.<br />
<br />
The slides for the initial design presentation can be found here: [[File:group3_2017_Initial_design_presentation.pdf]]<br />
<br />
==Overview==<br />
There are 2 main goals for the PICO robot. <br />
# Corridor competition: To navigate through a corridor and take the first exit without colliding with the walls.<br />
# Maze competition: To solve and exit an unknown maze through a door without colliding with the walls.<br />
<br />
The overall design of the project is mentioned in the following section:<br />
# Requirements<br />
# Specifications<br />
# Functions<br />
# Components<br />
# Interfaces<br />
<br />
==Requirements==<br />
The following requirements are listed for the robot (PICO) to complete maze successfully:<br />
# PICO may not touch the walls or any other obstacle in the maze at any time<br />
# PICO must operate fully autonomous (i.e. without input from the team)<br />
# PICO may not be idle for more than 3 seconds from the start of program unless it has passed the exit<br />
# PICO must be able to detect available space using the Laser Range Finder (LRF) and move to the detected space according to the motion planning algorithm<br />
# PICO must be able to find the exit in finite time (≤ 7 sec for maze and ≤ 5 sec for corridor.)<br />
# PICO must be able to detect the objects (dead ends) that have a high probability of being a door<br />
# PICO must be able to open the door in the maze and pass through it<br />
<br />
==Functions==<br />
The functions are separate modules called supervisors where, the supervisor unknown of what is inside the other supervisor. This approach makes software architecture simpler, it is also easier to edit and error count will be less since no direct interaction of modules. Supervisors are listed below:<br />
<br />
# Path-finding Supervisor<br />
# Door Handling Supervisor<br />
# Wall / Path Detection<br />
# Motion Supervisor<br />
# Actuator Supervisor<br />
<br />
===Path-finding Supervisor===<br />
1-'''Pledge Algorithm:'''<br />
Takes in the extracted wall information as input and sets a movement goal for the PICO and move towards it. This algorithm is useful when the robot is challenged to solve loop inside the maze. The algorithm functions as a continuous loop. (Maze challenge)<br />
<br />
2- '''Cornering:'''<br />
Take the corner using the wall information as input. (Corridor challenge)<br />
<br />
===Door Supervisor===<br />
<br />
1-'''Ring Bell:'''<br />
Ring the bell if it detect the door possible deadends<br />
<br />
2-'''Standstill:'''<br />
Wait for 5 sec to for the door openingsequence.<br />
<br />
===Wall / Path Detection===<br />
<br />
1-'''Read LRF data:'''<br />
Gets raw data from the LRF sensor<br />
<br />
2-'''Filter LRF data:'''<br />
Reduces noise from raw LRF data and splits it into 3 directions (left, right and front).<br />
<br />
3-'''Transform data:'''<br />
Calculate one distance approximation for the 3 directions.<br />
<br />
4-'''Possiblity checker:'''<br />
Calculate for all directions if movement in that direction is possible, taking a ‘safe’ zone around PICO into account.<br />
<br />
===Motion Supervisor===<br />
<br />
1-'''Position stabilizing:'''<br />
Feedback loop that keep PICO approximately in the center of the corridor by implementing a feedback controller for the distance to the walls on the left and right of the robot.<br />
<br />
2-'''Turn Corner:'''<br />
Make a 90 degree turn either on left or on right<br />
<br />
===Actuator Supervisor===<br />
<br />
1-'''Steady PICO:'''<br />
Keep the front of the PICO aligned to the direction of movement.<br />
<br />
2-'''Omniwheels handeling:'''<br />
Set speed and angle of Omniwheels<br />
<br />
==Interfaces==<br />
The interfaces are defined as the movement/flow of data between the functions that are defined in above section.<br />
The different interfaces are described below.<br />
<br />
1- Sending information about current state, which is the distance to walls at -90 degrees, 0 degrees and 90 degrees from the center point and whether it has potential from moving forward and turning left or right. <''Struct with float values and booleans''>.<br />
<br />
2- Forward information about potential movement.<''Struct of Boolean''>.<br />
<br />
3- Forward information about wall distances.<''Struct of floats''>.<br />
<br />
4- Turning command, which is either 1 (turning left) or 2(turning right). <''integer''>.<br />
<br />
5- Send information about the possibility of a door.<''Boolean''>.<br />
<br />
6- Confirmation that door handling is finished <''Boolean''>.<br />
<br />
7- Setting the values for actuator.<''Struct of floats''><br />
<br />
==Components==<br />
<br />
1- '''Sensors:''' Laser Range Finder (LRF), Odometry (Wheel Encoder).<br />
<br />
2- '''Holonomic base (omni-wheels):''' Maximum translational speed of 0.5 m/s , Max angular speed of 1.2 rad/s.<br />
<br />
3- '''Embedded platform''' Computer with Ubuntu 14.04 on an Intel i7 (other specifications are unknown)<br />
<br />
4- '''Bell:''' To produce sound from PICO so as to open the door.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Group3_2017_Initial_Design&diff=42108Group3 2017 Initial Design2017-06-16T15:10:25Z<p>S127922: Blanked the page</p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Group3_2017_Initial_Design&diff=42107Group3 2017 Initial Design2017-06-16T15:05:23Z<p>S127922: Created page with '==Documents== The initial design document file:Emc-design-specification.pdf briefly indicates the approach taken towards the problem of solving the maze by the PICO robot, th…'</p>
<hr />
<div>==Documents==<br />
The initial design document [[file:Emc-design-specification.pdf]] briefly indicates the approach taken towards the problem of solving the maze by the PICO robot, the algorithm used and the system design.<br />
<br />
The slides for the initial design presentation can be found here: [[File:group3_2017_Initial_design_presentation.pdf]]<br />
<br />
==Overview==<br />
There are 2 main goals for the PICO robot. <br />
# Corridor competition: To navigate through a corridor and take the first exit without colliding with the walls.<br />
# Maze competition: To solve and exit an unknown maze through a door without colliding with the walls.<br />
<br />
The overall design of the project is mentioned in the following section:<br />
# Requirements<br />
# Specifications<br />
# Functions<br />
# Components<br />
# Interfaces<br />
<br />
==Requirements==<br />
The following requirements are listed for the robot (PICO) to complete maze successfully:<br />
# PICO may not touch the walls or any other obstacle in the maze at any time<br />
# PICO must operate fully autonomous (i.e. without input from the team)<br />
# PICO may not be idle for more than 3 seconds from the start of program unless it has passed the exit<br />
# PICO must be able to detect available space using the Laser Range Finder (LRF) and move to the detected space according to the motion planning algorithm<br />
# PICO must be able to find the exit in finite time (≤ 7 sec for maze and ≤ 5 sec for corridor.)<br />
# PICO must be able to detect the objects (dead ends) that have a high probability of being a door<br />
# PICO must be able to open the door in the maze and pass through it<br />
<br />
==Functions==<br />
The functions are separate modules called supervisors where, the supervisor unknown of what is inside the other supervisor. This approach makes software architecture simpler, it is also easier to edit and error count will be less since no direct interaction of modules. Supervisors are listed below:<br />
<br />
# Path-finding Supervisor<br />
# Door Handling Supervisor<br />
# Wall / Path Detection<br />
# Motion Supervisor<br />
# Actuator Supervisor<br />
<br />
===Path-finding Supervisor===<br />
1-'''Pledge Algorithm:'''<br />
Takes in the extracted wall information as input and sets a movement goal for the PICO and move towards it. This algorithm is useful when the robot is challenged to solve loop inside the maze. The algorithm functions as a continuous loop. (Maze challenge)<br />
<br />
2- '''Cornering:'''<br />
Take the corner using the wall information as input. (Corridor challenge)<br />
<br />
===Door Supervisor===<br />
<br />
1-'''Ring Bell:'''<br />
Ring the bell if it detect the door possible deadends<br />
<br />
2-'''Standstill:'''<br />
Wait for 5 sec to for the door openingsequence.<br />
<br />
===Wall / Path Detection===<br />
<br />
1-'''Read LRF data:'''<br />
Gets raw data from the LRF sensor<br />
<br />
2-'''Filter LRF data:'''<br />
Reduces noise from raw LRF data and splits it into 3 directions (left, right and front).<br />
<br />
3-'''Transform data:'''<br />
Calculate one distance approximation for the 3 directions.<br />
<br />
4-'''Possiblity checker:'''<br />
Calculate for all directions if movement in that direction is possible, taking a ‘safe’ zone around PICO into account.<br />
<br />
===Motion Supervisor===<br />
<br />
1-'''Position stabilizing:'''<br />
Feedback loop that keep PICO approximately in the center of the corridor by implementing a feedback controller for the distance to the walls on the left and right of the robot.<br />
<br />
2-'''Turn Corner:'''<br />
Make a 90 degree turn either on left or on right<br />
<br />
===Actuator Supervisor===<br />
<br />
1-'''Steady PICO:'''<br />
Keep the front of the PICO aligned to the direction of movement.<br />
<br />
2-'''Omniwheels handeling:'''<br />
Set speed and angle of Omniwheels<br />
<br />
==Interfaces==<br />
The interfaces are defined as the movement/flow of data between the functions that are defined in above section.<br />
The different interfaces are described below.<br />
<br />
1- Sending information about current state, which is the distance to walls at -90 degrees, 0 degrees and 90 degrees from the center point and whether it has potential from moving forward and turning left or right. <''Struct with float values and booleans''>.<br />
<br />
2- Forward information about potential movement.<''Struct of Boolean''>.<br />
<br />
3- Forward information about wall distances.<''Struct of floats''>.<br />
<br />
4- Turning command, which is either 1 (turning left) or 2(turning right). <''integer''>.<br />
<br />
5- Send information about the possibility of a door.<''Boolean''>.<br />
<br />
6- Confirmation that door handling is finished <''Boolean''>.<br />
<br />
7- Setting the values for actuator.<''Struct of floats''><br />
<br />
==Components==<br />
<br />
1- '''Sensors:''' Laser Range Finder (LRF), Odometry (Wheel Encoder).<br />
<br />
2- '''Holonomic base (omni-wheels):''' Maximum translational speed of 0.5 m/s , Max angular speed of 1.2 rad/s.<br />
<br />
3- '''Embedded platform''' Computer with Ubuntu 14.04 on an Intel i7 (other specifications are unknown)<br />
<br />
4- '''Bell:''' To produce sound from PICO so as to open the door.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Initial_Design&diff=42105Initial Design2017-06-16T15:03:33Z<p>S127922: Blanked the page</p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Initial_Design&diff=42104Initial Design2017-06-16T15:03:05Z<p>S127922: Created page with '==Documents== The initial design document file:Emc-design-specification.pdf briefly indicates the approach taken towards the problem of solving the maze by the PICO robot, th…'</p>
<hr />
<div>==Documents==<br />
The initial design document [[file:Emc-design-specification.pdf]] briefly indicates the approach taken towards the problem of solving the maze by the PICO robot, the algorithm used and the system design.<br />
<br />
The slides for the initial design presentation can be found here: [[File:group3_2017_Initial_design_presentation.pdf]]<br />
<br />
==Overview==<br />
There are 2 main goals for the PICO robot. <br />
# Corridor competition: To navigate through a corridor and take the first exit without colliding with the walls.<br />
# Maze competition: To solve and exit an unknown maze through a door without colliding with the walls.<br />
<br />
The overall design of the project is mentioned in the following section:<br />
# Requirements<br />
# Specifications<br />
# Functions<br />
# Components<br />
# Interfaces<br />
<br />
==Requirements==<br />
The following requirements are listed for the robot (PICO) to complete maze successfully:<br />
# PICO may not touch the walls or any other obstacle in the maze at any time<br />
# PICO must operate fully autonomous (i.e. without input from the team)<br />
# PICO may not be idle for more than 3 seconds from the start of program unless it has passed the exit<br />
# PICO must be able to detect available space using the Laser Range Finder (LRF) and move to the detected space according to the motion planning algorithm<br />
# PICO must be able to find the exit in finite time (≤ 7 sec for maze and ≤ 5 sec for corridor.)<br />
# PICO must be able to detect the objects (dead ends) that have a high probability of being a door<br />
# PICO must be able to open the door in the maze and pass through it<br />
<br />
==Functions==<br />
The functions are separate modules called supervisors where, the supervisor unknown of what is inside the other supervisor. This approach makes software architecture simpler, it is also easier to edit and error count will be less since no direct interaction of modules. Supervisors are listed below:<br />
<br />
# Path-finding Supervisor<br />
# Door Handling Supervisor<br />
# Wall / Path Detection<br />
# Motion Supervisor<br />
# Actuator Supervisor<br />
<br />
===Path-finding Supervisor===<br />
1-'''Pledge Algorithm:'''<br />
Takes in the extracted wall information as input and sets a movement goal for the PICO and move towards it. This algorithm is useful when the robot is challenged to solve loop inside the maze. The algorithm functions as a continuous loop. (Maze challenge)<br />
<br />
2- '''Cornering:'''<br />
Take the corner using the wall information as input. (Corridor challenge)<br />
<br />
===Door Supervisor===<br />
<br />
1-'''Ring Bell:'''<br />
Ring the bell if it detect the door possible deadends<br />
<br />
2-'''Standstill:'''<br />
Wait for 5 sec to for the door openingsequence.<br />
<br />
===Wall / Path Detection===<br />
<br />
1-'''Read LRF data:'''<br />
Gets raw data from the LRF sensor<br />
<br />
2-'''Filter LRF data:'''<br />
Reduces noise from raw LRF data and splits it into 3 directions (left, right and front).<br />
<br />
3-'''Transform data:'''<br />
Calculate one distance approximation for the 3 directions.<br />
<br />
4-'''Possiblity checker:'''<br />
Calculate for all directions if movement in that direction is possible, taking a ‘safe’ zone around PICO into account.<br />
<br />
===Motion Supervisor===<br />
<br />
1-'''Position stabilizing:'''<br />
Feedback loop that keep PICO approximately in the center of the corridor by implementing a feedback controller for the distance to the walls on the left and right of the robot.<br />
<br />
2-'''Turn Corner:'''<br />
Make a 90 degree turn either on left or on right<br />
<br />
===Actuator Supervisor===<br />
<br />
1-'''Steady PICO:'''<br />
Keep the front of the PICO aligned to the direction of movement.<br />
<br />
2-'''Omniwheels handeling:'''<br />
Set speed and angle of Omniwheels<br />
<br />
==Interfaces==<br />
The interfaces are defined as the movement/flow of data between the functions that are defined in above section.<br />
The different interfaces are described below.<br />
<br />
1- Sending information about current state, which is the distance to walls at -90 degrees, 0 degrees and 90 degrees from the center point and whether it has potential from moving forward and turning left or right. <''Struct with float values and booleans''>.<br />
<br />
2- Forward information about potential movement.<''Struct of Boolean''>.<br />
<br />
3- Forward information about wall distances.<''Struct of floats''>.<br />
<br />
4- Turning command, which is either 1 (turning left) or 2(turning right). <''integer''>.<br />
<br />
5- Send information about the possibility of a door.<''Boolean''>.<br />
<br />
6- Confirmation that door handling is finished <''Boolean''>.<br />
<br />
7- Setting the values for actuator.<''Struct of floats''><br />
<br />
==Components==<br />
<br />
1- '''Sensors:''' Laser Range Finder (LRF), Odometry (Wheel Encoder).<br />
<br />
2- '''Holonomic base (omni-wheels):''' Maximum translational speed of 0.5 m/s , Max angular speed of 1.2 rad/s.<br />
<br />
3- '''Embedded platform''' Computer with Ubuntu 14.04 on an Intel i7 (other specifications are unknown)<br />
<br />
4- '''Bell:''' To produce sound from PICO so as to open the door.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017&diff=40688Embedded Motion Control 20172017-05-27T12:54:10Z<p>S127922: /* Pico test schedule */</p>
<hr />
<div><div align="center"><br />
<font size="5">Guide towards the assignment</font><br /><br />
<font size="4">'A-MAZE-ING PICO'</font><br />
</div><br />
[[File:Gostai-Jazz-500x500.jpg|center|thumb|350px]]<br />
<br />
----<br />
<br />
= Introduction =<br />
This course is about software design and how to apply this in the context of autonomous robots. The accompanying assignment is about applying this knowledge to a real-life robotics task.<br />
<br />
= Course Schedule and Lecture Slides =<br />
Lectures will be given on Wednesdays from 15.45 - 17.30 in Auditorium 14. The preliminary course schedule is as follows:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" align="center" style="margin-left: 3em;"<br />
|-<br />
| width="150" | April 26<br />
| colspan="2" | '''No Lecture: Ubuntu Installation & Tutorials''' (see Canvas!)<br />
|-<br />
| May 3<br />
| width="325" | Introduction by ''René van de Molengraft'' (see Canvas!)<br />
| width="325" | [[Media:Emc-2017-05-03-tools-and-infrastructure.pdf | Tooling and Infrastructure by ''Wouter Kuijpers'' ]]<br />
|-<br />
| May 10<br />
| colspan="2" | Best Practices in System Design for Robot Control by ''Nico Huebel'': [[Media:EmbeddedMotionControl-2017-Lecture2-part1.pdf | Part 1]] & [[Media:EmbeddedMotionControl-2017-Lecture2-part2.pdf | Part 2]]<br />
|-<br />
| May 17<br />
| colspan="2" | First presentation of the design by ''the groups''. 6-minute presentation, about the group's initial design. Afterwards 4 minutes for questions.<br />
|-<br />
| May 24<br />
| '''Corridor competition'''<br />
|No Lecture<br />
|-<br />
| May 31<br />
| colspan="2" | Invited talk by ''invited speaker''.<br />
|-<br />
| June 7<br />
| colspan="2" | Presentation of final design by the ''groups''.<br />
|-<br />
| June 14<br />
| colspan="2" | '''Final Competition'''<br />
|-<br />
| June 21<br />
| colspan="2" | '''Deadline Wiki Pages'''<br />
|-<br />
|}<br />
<br />
= Assignment =<br />
Design and implement a robotic software system that will let robots Pico/Taco solve a maze in the robotics lab. The maze can contain doors that automatically open and close.<br />
<br />
= Corridor Competition =<br />
{{:Embedded_Motion_Control/Corridor_competition_2017}}<br />
<br />
= Maze Competition =<br />
{{:Embedded_Motion_Control/Maze_competition_2017}}<br />
<br />
= Getting Started =<br />
<br />
To get started, please do the tutorials on the [[Embedded Motion Control/Tutorials | Tutorial Page]]. Please note:<br />
<br />
* '''Do all tutorials, and all steps. Missing one step may cause a different behavior or incorrect working system later'''. If something is not working as expected, make sure you correctly did all previous steps.<br />
* Of course, things may still go wrong. If so, do not hesitate to contact us.<br />
<br />
* See [[Embedded_Motion_Control/Using_Pico | Using Pico]] for a quick overview of how to use Pico.<br />
<br />
= FAQ =<br />
[[Embedded_Motion_Control_2017/FAQ | Here]] you can find a collection of Frequently Asked Questions. Please check this page before contacting the student assistants or the tutors! If you find any issues or questions you had to deal with, please add them as well so your colleagues don't run into the same problems.<br />
<br />
=Group Wiki Pages=<br />
<br />
Group 1 - [[Embedded Motion Control 2017 Group 1 | visit wiki ]] - '''Tutor''': Yanick Douven (first week: Wouter Kuijpers)<br />
<br />
Group 2 - [[Embedded Motion Control 2017 Group 2 | visit wiki ]] - '''Tutor''': Yanick Douven (first week: Wouter Houtman)<br />
<br />
Group 3 - [[Embedded Motion Control 2017 Group 3 | visit wiki ]] - '''Tutor''': Wouter Kuijpers<br />
<br />
Group 4 - [[Embedded Motion Control 2017 Group 4 | visit wiki ]] - '''Tutor''': Wouter Kuijpers<br />
<br />
Group 5 - [[Embedded Motion Control 2017 Group 5 | visit wiki ]] - '''Tutor''': Wouter Houtman<br />
<br />
Group 6 - [[Embedded Motion Control 2017 Group 6 | visit wiki ]] - '''Tutor''': Wouter Houtman<br />
<br />
Group 9 - [[Embedded Motion Control 2017 Group 9 | visit wiki ]] - '''Tutor''': Nico Huebel<br />
<br />
Group 10 - [[Embedded Motion Control 2017 Group 10 | visit wiki ]] - '''Tutor''': René van de Molengraft & Herman Bruyninckx<br />
<br />
= Pico test schedule =<br />
Be sure you have your software on git before coming to the test session so that you only have to git clone/git pull to get your code on the robot!<br />
<br />
Please charge the robot whenever possible so there is no down time due to empty batteries.<br />
<br />
Submissions are last checked the day before at 22:00.<br />
<!-- <br />
It is possible to test on the robot outside of the scheduled time, but know that this is unsupported. Make sure that when you want to test on the robot outside the schedule you add your time to the schedule and put an asterix after the time. Know that other people need to use the field as well (Tech United etc.) and outside the scheduled time these parties have precedence over you. Also know that you can only test once a week, so scheduling twice in a week is not allowed. --><br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 20'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 15-05-2017 || 10:45 - 12:30 || Group 5<br />
|-<br />
| 15-05-2017 || 13:45 - 15:30 || DO NOT BOOK!<br />
|-<br />
| 15-05-2017 || 15:45 - 17:30 || DO NOT BOOK!<br />
|-<br />
| 16-05-2017 || 11:15 - 13:00 || Group 2<br />
|-<br />
| 16-05-2017 || 13:45 - 15:30 || Group 6<br />
|-<br />
| 16-05-2017 || 15:45 - 17:30 || Group 3<br />
|-<br />
| 17-05-2017 || 8:45 - 10:30 || Group 4<br />
|-<br />
| 17-05-2017 || 10:45 - 12:30 || Group 1<br />
|-<br />
| 17-05-2017 || 13:45 - 15:30 || Group 10<br />
|-<br />
| 17-05-2017 || 15:45 - 17:30 || Group 9<br />
|}<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 21'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 22-05-2017 || 8:45 - 10:30 || Group 2<br />
|-<br />
| 22-05-2017 || 10:45 - 12:30 || Group 4<br />
|-<br />
| 22-05-2017 || 13:45 - 15:30 || Group 10<br />
|-<br />
| 22-05-2017 || 15:45 - 17:30 || Group 1<br />
|-<br />
| 23-05-2017 || 8:45 - 10:30 || Group 5<br />
|-<br />
| 23-05-2017 || 10:45 - 12:30 || Group 3<br />
|-<br />
| 23-05-2017 || 13:45 - 15:30 || Group 6<br />
|-<br />
| 23-05-2017 || 15:45 - 17:30 || Group 9<br />
|-<br />
| 24-05-2017 || 8:45 - 10:30 || DO NOT BOOK!<br />
|-<br />
| 24-05-2017 || 10:45 - 12:30 || DO NOT BOOK!<br />
|}<br />
<br />
<div style="clear:both"></div><br />
<br><br />
For week 22 you can choose 2 time slots. These can be separate or connecting. Choose wisely.<br />
<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 22 Monday'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 29-05-2017 || 8:45 - 9:35 ||<br />
|-<br />
| 29-05-2017 || 9:45 - 10:35 || <br />
|-<br />
| 29-05-2017 || 10:45 - 11:35 || Group 9<br />
|-<br />
| 29-05-2017 || 11:45 - 12:35 || Group 4<br />
|-<br />
| 29-05-2017 || 13:45 - 14:35 || Group 3 ovb<br />
|-<br />
| 29-05-2017 || 14:45 - 15:35 || <br />
|-<br />
| 29-05-2017 || 15:45 - 16:35 || Group 1<br />
|-<br />
| 29-05-2017 || 16:45 - 17:35 || <br />
|}<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 22 Tuesday'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 30-05-2017 || 8:45 - 9:35 || <br />
|-<br />
| 30-05-2017 || 9:45 - 10:35 || <br />
|-<br />
| 30-05-2017 || 10:45 - 11:35 || Group 9<br />
|-<br />
| 30-05-2017 || 11:45 - 12:35 || Group 5<br />
|-<br />
| 30-05-2017 || 13:45 - 14:35 || Group 2<br />
|-<br />
| 30-05-2017 || 14:45 - 15:35 || Group 2<br />
|-<br />
| 30-05-2017 || 15:45 - 16:35 || Group 6<br />
|-<br />
| 30-05-2017 || 16:45 - 17:35 || Group 3 ovb<br />
|}<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 22 Wednesday'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 31-05-2017 || 8:45 - 9:35 || Group 5<br />
|-<br />
| 31-05-2017 || 9:45 - 10:35 || Group 4<br />
|-<br />
| 31-05-2017 || 10:45 - 11:35 || Group 1 <br />
|-<br />
| 31-05-2017 || 11:45 - 12:35 || Group 6<br />
|}<br />
<br />
<br />
<br />
<div style="clear:both"></div><br />
<br />
=Contact Details=<br />
{{:Embedded_Motion_Control_2017/Contact_Details}}</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017&diff=40686Embedded Motion Control 20172017-05-27T12:36:27Z<p>S127922: /* Pico test schedule */</p>
<hr />
<div><div align="center"><br />
<font size="5">Guide towards the assignment</font><br /><br />
<font size="4">'A-MAZE-ING PICO'</font><br />
</div><br />
[[File:Gostai-Jazz-500x500.jpg|center|thumb|350px]]<br />
<br />
----<br />
<br />
= Introduction =<br />
This course is about software design and how to apply this in the context of autonomous robots. The accompanying assignment is about applying this knowledge to a real-life robotics task.<br />
<br />
= Course Schedule and Lecture Slides =<br />
Lectures will be given on Wednesdays from 15.45 - 17.30 in Auditorium 14. The preliminary course schedule is as follows:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" align="center" style="margin-left: 3em;"<br />
|-<br />
| width="150" | April 26<br />
| colspan="2" | '''No Lecture: Ubuntu Installation & Tutorials''' (see Canvas!)<br />
|-<br />
| May 3<br />
| width="325" | Introduction by ''René van de Molengraft'' (see Canvas!)<br />
| width="325" | [[Media:Emc-2017-05-03-tools-and-infrastructure.pdf | Tooling and Infrastructure by ''Wouter Kuijpers'' ]]<br />
|-<br />
| May 10<br />
| colspan="2" | Best Practices in System Design for Robot Control by ''Nico Huebel'': [[Media:EmbeddedMotionControl-2017-Lecture2-part1.pdf | Part 1]] & [[Media:EmbeddedMotionControl-2017-Lecture2-part2.pdf | Part 2]]<br />
|-<br />
| May 17<br />
| colspan="2" | First presentation of the design by ''the groups''. 6-minute presentation, about the group's initial design. Afterwards 4 minutes for questions.<br />
|-<br />
| May 24<br />
| '''Corridor competition'''<br />
|No Lecture<br />
|-<br />
| May 31<br />
| colspan="2" | Invited talk by ''invited speaker''.<br />
|-<br />
| June 7<br />
| colspan="2" | Presentation of final design by the ''groups''.<br />
|-<br />
| June 14<br />
| colspan="2" | '''Final Competition'''<br />
|-<br />
| June 21<br />
| colspan="2" | '''Deadline Wiki Pages'''<br />
|-<br />
|}<br />
<br />
= Assignment =<br />
Design and implement a robotic software system that will let robots Pico/Taco solve a maze in the robotics lab. The maze can contain doors that automatically open and close.<br />
<br />
= Corridor Competition =<br />
{{:Embedded_Motion_Control/Corridor_competition_2017}}<br />
<br />
= Maze Competition =<br />
{{:Embedded_Motion_Control/Maze_competition_2017}}<br />
<br />
= Getting Started =<br />
<br />
To get started, please do the tutorials on the [[Embedded Motion Control/Tutorials | Tutorial Page]]. Please note:<br />
<br />
* '''Do all tutorials, and all steps. Missing one step may cause a different behavior or incorrect working system later'''. If something is not working as expected, make sure you correctly did all previous steps.<br />
* Of course, things may still go wrong. If so, do not hesitate to contact us.<br />
<br />
* See [[Embedded_Motion_Control/Using_Pico | Using Pico]] for a quick overview of how to use Pico.<br />
<br />
= FAQ =<br />
[[Embedded_Motion_Control_2017/FAQ | Here]] you can find a collection of Frequently Asked Questions. Please check this page before contacting the student assistants or the tutors! If you find any issues or questions you had to deal with, please add them as well so your colleagues don't run into the same problems.<br />
<br />
=Group Wiki Pages=<br />
<br />
Group 1 - [[Embedded Motion Control 2017 Group 1 | visit wiki ]] - '''Tutor''': Yanick Douven (first week: Wouter Kuijpers)<br />
<br />
Group 2 - [[Embedded Motion Control 2017 Group 2 | visit wiki ]] - '''Tutor''': Yanick Douven (first week: Wouter Houtman)<br />
<br />
Group 3 - [[Embedded Motion Control 2017 Group 3 | visit wiki ]] - '''Tutor''': Wouter Kuijpers<br />
<br />
Group 4 - [[Embedded Motion Control 2017 Group 4 | visit wiki ]] - '''Tutor''': Wouter Kuijpers<br />
<br />
Group 5 - [[Embedded Motion Control 2017 Group 5 | visit wiki ]] - '''Tutor''': Wouter Houtman<br />
<br />
Group 6 - [[Embedded Motion Control 2017 Group 6 | visit wiki ]] - '''Tutor''': Wouter Houtman<br />
<br />
Group 9 - [[Embedded Motion Control 2017 Group 9 | visit wiki ]] - '''Tutor''': Nico Huebel<br />
<br />
Group 10 - [[Embedded Motion Control 2017 Group 10 | visit wiki ]] - '''Tutor''': René van de Molengraft & Herman Bruyninckx<br />
<br />
= Pico test schedule =<br />
Be sure you have your software on git before coming to the test session so that you only have to git clone/git pull to get your code on the robot!<br />
<br />
Please charge the robot whenever possible so there is no down time due to empty batteries.<br />
<br />
Submissions are last checked the day before at 22:00.<br />
<!-- <br />
It is possible to test on the robot outside of the scheduled time, but know that this is unsupported. Make sure that when you want to test on the robot outside the schedule you add your time to the schedule and put an asterix after the time. Know that other people need to use the field as well (Tech United etc.) and outside the scheduled time these parties have precedence over you. Also know that you can only test once a week, so scheduling twice in a week is not allowed. --><br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 20'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 15-05-2017 || 10:45 - 12:30 || Group 5<br />
|-<br />
| 15-05-2017 || 13:45 - 15:30 || DO NOT BOOK!<br />
|-<br />
| 15-05-2017 || 15:45 - 17:30 || DO NOT BOOK!<br />
|-<br />
| 16-05-2017 || 11:15 - 13:00 || Group 2<br />
|-<br />
| 16-05-2017 || 13:45 - 15:30 || Group 6<br />
|-<br />
| 16-05-2017 || 15:45 - 17:30 || Group 3<br />
|-<br />
| 17-05-2017 || 8:45 - 10:30 || Group 4<br />
|-<br />
| 17-05-2017 || 10:45 - 12:30 || Group 1<br />
|-<br />
| 17-05-2017 || 13:45 - 15:30 || Group 10<br />
|-<br />
| 17-05-2017 || 15:45 - 17:30 || Group 9<br />
|}<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 21'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 22-05-2017 || 8:45 - 10:30 || Group 2<br />
|-<br />
| 22-05-2017 || 10:45 - 12:30 || Group 4<br />
|-<br />
| 22-05-2017 || 13:45 - 15:30 || Group 10<br />
|-<br />
| 22-05-2017 || 15:45 - 17:30 || Group 1<br />
|-<br />
| 23-05-2017 || 8:45 - 10:30 || Group 5<br />
|-<br />
| 23-05-2017 || 10:45 - 12:30 || Group 3<br />
|-<br />
| 23-05-2017 || 13:45 - 15:30 || Group 6<br />
|-<br />
| 23-05-2017 || 15:45 - 17:30 || Group 9<br />
|-<br />
| 24-05-2017 || 8:45 - 10:30 || DO NOT BOOK!<br />
|-<br />
| 24-05-2017 || 10:45 - 12:30 || DO NOT BOOK!<br />
|}<br />
<br />
<div style="clear:both"></div><br />
<br><br />
For week 22 you can choose 2 time slots. These can be separate or connecting. Choose wisely.<br />
<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 22 Monday'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 29-05-2017 || 8:45 - 9:35 ||<br />
|-<br />
| 29-05-2017 || 9:45 - 10:35 || <br />
|-<br />
| 29-05-2017 || 10:45 - 11:35 ||<br />
|-<br />
| 29-05-2017 || 11:45 - 12:35 || Group 4<br />
|-<br />
| 29-05-2017 || 13:45 - 14:35 || Group 3<br />
|-<br />
| 29-05-2017 || 14:45 - 15:35 || <br />
|-<br />
| 29-05-2017 || 15:45 - 16:35 || Group 1<br />
|-<br />
| 29-05-2017 || 16:45 - 17:35 || <br />
|}<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 22 Tuesday'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 30-05-2017 || 8:45 - 9:35 || <br />
|-<br />
| 30-05-2017 || 9:45 - 10:35 || <br />
|-<br />
| 30-05-2017 || 10:45 - 11:35 || Group 9<br />
|-<br />
| 30-05-2017 || 11:45 - 12:35 || Group 5<br />
|-<br />
| 30-05-2017 || 13:45 - 14:35 || Group 2<br />
|-<br />
| 30-05-2017 || 14:45 - 15:35 || Group 2<br />
|-<br />
| 30-05-2017 || 15:45 - 16:35 || Group 6<br />
|-<br />
| 30-05-2017 || 16:45 - 17:35 || Group 3<br />
|}<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week 22 Wednesday'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| 31-05-2017 || 8:45 - 9:35 || Group 5<br />
|-<br />
| 31-05-2017 || 9:45 - 10:35 || Group 4<br />
|-<br />
| 31-05-2017 || 10:45 - 11:35 || Group 1 <br />
|-<br />
| 31-05-2017 || 11:45 - 12:35 || Group 6<br />
|}<br />
<br />
<br />
<br />
<div style="clear:both"></div><br />
<br />
=Contact Details=<br />
{{:Embedded_Motion_Control_2017/Contact_Details}}</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Embedded_Motion_Control_2017&diff=39558Embedded Motion Control 20172017-05-04T08:31:05Z<p>S127922: /* Group Wiki Pages */</p>
<hr />
<div><div align="center"><br />
<font size="5">Guide towards the assignment</font><br /><br />
<font size="4">'A-MAZE-ING PICO'</font><br />
</div><br />
[[File:Gostai-Jazz-500x500.jpg|center|thumb|350px]]<br />
<br />
----<br />
<br />
= Introduction =<br />
This course is about software design and how to apply this in the context of autonomous robots. The accompanying assignment is about applying this knowledge to a real-life robotics task.<br />
<br />
= Course Schedule and Lecture Slides =<br />
Lectures will be given on Wednesdays from 15.45 - 17.30 in Auditorium 14. The preliminary course schedule is as follows:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" align="center" style="margin-left: 3em;"<br />
|-<br />
| width="150" | April 26<br />
| colspan="2" | '''No Lecture: Ubuntu Installation & Tutorials''' (see Canvas!)<br />
|-<br />
| May 3<br />
| width="325" | Introduction by ''René van de Molengraft''<br />
| width="325" | [[Media:Emc-2017-05-03-tools-and-infrastructure.pdf | Tooling and Infrastructure by ''Wouter Kuijpers'' ]]<br />
|-<br />
| May 10<br />
| colspan="2" | Best Practices in System Design for Robot Control by ''Herman Bruyninckx'' or ''Nico Huebel''<br />
|-<br />
| May 17<br />
| First presentation of the design by ''the groups''. <br />
| <br />
|-<br />
| May 24<br />
| '''Corridor competition'''<br />
| Communication patterns by ''Herman Bruyninckx'' or ''Nico Huebel''<br />
|-<br />
| May 31<br />
| colspan="2" | Invited talk by ''invited speaker''.<br />
|-<br />
| June 7<br />
| colspan="2" | Presentation of final design by the ''groups''.<br />
|-<br />
| June 14<br />
| colspan="2" | '''Final Competition'''<br />
|-<br />
| June 21<br />
| colspan="2" | '''Deadline Wiki Pages'''<br />
|-<br />
|}<br />
<br />
= Assignment =<br />
Design and implement a robotic software system that will let robots Pico/Taco solve a maze in the robotics lab. The maze can contain doors that automatically open and close.<br />
<br />
= Corridor Competition =<br />
{{:Embedded_Motion_Control/Corridor_competition_2017}}<br />
<br />
= Maze Competition =<br />
{{:Embedded_Motion_Control/Maze_competition_2017}}<br />
<br />
= Getting Started =<br />
<br />
To get started, please do the tutorials on the [[Embedded Motion Control/Tutorials | Tutorial Page]]. Please note:<br />
<br />
* '''Do all tutorials, and all steps. Missing one step may cause a different behavior or incorrect working system later'''. If something is not working as expected, make sure you correctly did all previous steps.<br />
* Of course, things may still go wrong. If so, do not hesitate to contact us.<br />
<br />
* See [[Embedded_Motion_Control/Using_Pico | Using Pico]] for a quick overview of how to use Pico.<br />
<br />
= FAQ =<br />
[[Embedded_Motion_Control_2017/FAQ | Here]] you can find a collection of Frequently Asked Questions. Please check this page before contacting the student assistants or the tutors! If you find any issues or questions you had to deal with, please add them as well so your colleagues don't run into the same problems.<br />
<br />
=Group Wiki Pages=<br />
<br />
Group 1 - [[Embedded Motion Control 2017 Group 1 | visit wiki ]] - '''Tutor''': tbd<br />
<br />
Karel van de Plassche <br><br />
Joey Hendriks <br><br />
Ioannis-Dionysios Bratis <br><br />
Jad Haj Mustafa <br><br />
Jip Reinders <br><br />
juliana langen <br><br />
<br />
Group 2 - [[Embedded Motion Control 2017 Group 2 | visit wiki ]] - '''Tutor''': tbd<br />
<br />
Daniël Pijnenborg <br><br />
Joep Linssen <br><br />
Matthijs van der Burgh <br><br />
Sil Schouten <br><br />
Rens Slenders <br><br />
Joeri Roelofs <br><br />
<br />
Group 3 - [[Embedded Motion Control 2017 Group 3 | visit wiki ]] - '''Tutor''': tbd<br />
<br />
Ayisha wafa <br><br />
Aparnasri Sekar <br><br />
Nick Peters <br><br />
Jelte Borsboom <br><br />
<br />
Group 4 - [[Embedded Motion Control 2017 Group 4 | visit wiki ]] - '''Tutor''': tbd<br />
<br />
Mathijs Schouten <br><br />
Niels Janssen <br><br />
Rik Winters <br><br />
Mickey Beurskens <br><br />
Melvin de Wildt <br><br />
Joey Verest<br />
<br />
Group 5 - [[Embedded Motion Control 2017 Group 5 | visit wiki ]] - '''Tutor''': tbd<br />
<br />
Angel Molina <br><br />
Sjoerd Knippenberg <br><br />
Torben Beernaert <br><br />
Bart Vercoulen <br><br />
Rodrigo Estrella <br><br />
Kagan Incetan<br />
<br />
Group 6 - [[Embedded Motion Control 2017 Group 6 | visit wiki ]] - '''Tutor''': tbd<br />
<br />
Lars Moormann <br><br />
Ties Hoenselaar <br><br />
Jeroen van der Velden <br><br />
Laura de Jong <br><br />
Bas Straatman <br><br />
Hasan Ilisu <br><br />
<br />
Group 9 - [[Embedded Motion Control 2017 Group 9 | visit wiki ]] - '''Tutor''': tbd<br />
<br />
Mian Wei <br><br />
Zhihao Wu <br><br />
Petrus T Handoko <br><br />
Bo Deng <br><br />
Bo Cong <br><br />
Jian Wen Kok <br><br />
<br />
Group 10 - [[Embedded Motion Control 2017 Group 10 | visit wiki ]] - '''Tutor''': tbd<br />
<br />
Tim Coerver <br><br />
Bas Vermij <br><br />
Pieter de Groot <br><br />
Jos Terlouw <br><br />
Corné van Haren <br><br />
Roel Vromans <br><br />
<br />
= Pico test schedule =<br />
Be sure you have your software on git before coming to the test session so that you only have to git clone/git pull to get your code on the robot!<br />
<br />
Please charge the robot whenever possible so there is no down time due to empty batteries.<br />
<br />
Submissions are last checked the day before at 22:00.<br />
<br />
It is possible to test on the robot outside of the scheduled time, but know that this is unsupported. Make sure that when you want to test on the robot outside the schedule you add your time to the schedule and put an asterix after the time. Know that other people need to use the field as well (Tech United etc.) and outside the scheduled time these parties have precedence over you. Also know that you can only test once a week, so scheduling twice in a week is not allowed.<br />
<br />
<br />
{| class="TablePager" style="width: 300px; min-width: 240px; margin-left: 2em; float:left; color: black;"<br />
|+ '''Week #'''<br />
|-<br />
! scope="col" | '''Date'''<br />
! scope="col" | '''Time'''<br />
! scope="col" | '''Group'''<br />
|-<br />
| date || time || group<br />
|-<br />
|}<br />
<br />
<div style="clear:both"></div><br />
<br />
=Contact Details=<br />
{{:Embedded_Motion_Control_2017/Contact_Details}}</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17530PRE2Groep2 Experiment2015-01-16T02:47:16Z<p>S127922: /* Tijdsduur */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het experiment. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
==Arduino==<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC op de PN532 deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op een analoge input pin van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar MATLAB op een van onze computers. in MATLAB worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
===Pin allocatie===<br />
De pins van de Arduino zijn als volgt in gebruik:<br />
* SCA : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* SCL : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* Aref : PN532 RFID Shield<br />
* Digital I/O 0-13 : PN532 RFID Shield<br />
* IOREF: PN532 RFID Shield<br />
* RESET: PN532 RFID Shield<br />
* 3V: PN532 RFID Shield<br />
* Vin: PN532 RFID Shield<br />
* Analog in 0-5: PN532 RFID Shield<br />
* Analog in 7: PN532 RFID Shield Antenne<br />
<br />
Verder zijn zowel de thermopile als het RFID shield gekoppeld aan 5V en gnd op verschillende plaatsen. Deze pins zijn voor de PN532 tussen de Digital I/O en SCA, en tussen Vin en 3V.<br />
Voor de thermopile zijn deze onderaan het board, ground links en 5V rechts.<br />
[[File:ArduinoPinouts.png|right|thumb|350px|Overzicht Arduino pinouts]]<br />
<br />
===Broncode===<br />
De broncode om de signalen naar MATLAB te lezen bestaat uit 4 onderdelen:<br />
* De TMP006 library om temperatuur in te lezen[2]<br />
* De NFC Library om het RFID shield te gebruiken[4], met enkele aanpassingen<br />
* Het Arduino programma dat de samples verzamelt en naar de computer stuurt<br />
* Het MATlab script dat deze samples opvangt en in matrices stopt<br />
<br />
Voor de code van de gebruikte libraries, zie de GitHub links in de bronnenlijst.<br />
<br />
====Arduino Programma====<br />
<nowiki><br />
#include <Wire.h><br />
#include <Adafruit_NFCShield_I2C.h><br />
#include <math.h><br />
#include <stdint.h> <br />
#include "I2C_16.h"<br />
#include "TMP006.h"<br />
<br />
#define IRQ (2)<br />
#define RESET (3) // Not connected by default on the NFC Shield<br />
#define SAMPLES_PER_READING (10) // 1 - 255<br />
uint8_t tempID = 0x40; // I2C address of TMP006, can be 0x40-0x47 (would have to wire the address pins)<br />
uint16_t samples = TMP006_CFG_1SAMPLE; // # of samples per reading, can be 1/2/4/8/16<br />
<br />
Adafruit_NFCShield_I2C nfc(IRQ, RESET);<br />
<br />
void setup(void) {<br />
Serial.begin(115200);<br />
<br />
//init PN53x<br />
nfc.begin();<br />
<br />
//init tmp006<br />
config_TMP006(tempID, samples);<br />
<br />
uint32_t versiondata = nfc.getFirmwareVersion();<br />
if (! versiondata) {<br />
Serial.print("Didn't find PN53x board");<br />
while (1); // halt<br />
}<br />
<br />
// Got ok data, print it out!<br />
Serial.print("Found chip PN5"); <br />
Serial.println((versiondata>>24) & 0xFF, HEX); <br />
Serial.print("Firmware ver. "); <br />
Serial.print((versiondata>>16) & 0xFF, DEC); <br />
Serial.print('.'); <br />
Serial.println((versiondata>>8) & 0xFF, DEC);<br />
<br />
// 0xFF = forever<br />
nfc.setPassiveActivationRetries(0xFF);<br />
<br />
// configure board to read RFID tags<br />
nfc.SAMConfig();<br />
<br />
Serial.println("Listening for an ISO14443A card");<br />
nfc.listenPassiveTarget(PN532_MIFARE_ISO14443A);<br />
}<br />
<br />
void loop() { <br />
uint8_t i = 0;<br />
float samplestotal = 0.0;<br />
<br />
for(i = 0; i < SAMPLES_PER_READING; i++) {<br />
samplestotal += analogRead(7);<br />
}<br />
<br />
float sigstrength = samplestotal / SAMPLES_PER_READING; <br />
<br />
float object_temp = readObjTempC(tempID);<br />
Serial.print(object_temp); <br />
Serial.print(";");<br />
Serial.println(sigstrength);<br />
}<br />
</nowiki><br />
<br />
====Extra functie NFC library====<br />
Deze functie zorgt ervoor dat de RFID antenne permanent aan het meten is, waardoor wij vervolgens de mogelijkheid hebben (gebruikmakende van de kabel die we vanaf het RFID shield naar Analog in 7 hebben geleid) om de signaalsterkte direct af te lezen.<br />
<nowiki><br />
/* In header file */<br />
boolean listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout = 0);<br />
<br />
/* In CPP file */<br />
boolean Adafruit_NFCShield_I2C::listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout) {<br />
pn532_packetbuffer[0] = PN532_COMMAND_INLISTPASSIVETARGET;<br />
pn532_packetbuffer[1] = 1; // max 2 cards at once (untested)<br />
pn532_packetbuffer[2] = cardbaudrate;<br />
<br />
if (! sendCommandCheckAck(pn532_packetbuffer, 3, timeout))<br />
{<br />
#ifdef PN532DEBUG<br />
Serial.println(F("No card(s) read"));<br />
#endif<br />
return 0; // no cards read<br />
}<br />
<br />
return 1;<br />
}<br />
</nowiki><br />
<br />
====MATlab code====<br />
<br />
Deze functie werd gebruikt voor het meten van <samples> samples in één cel in het raster (Werd dus voor iedere cel aangeroepen)<br />
<nowiki><br />
function [ RFIDvals, tempvals ] = readRFIDTemp( samples )<br />
%READRFIDTEMP Summary of this function goes here<br />
% Detailed explanation goes here<br />
s = serial('COM3', 'BaudRate', 115200);<br />
RFIDvals = zeros(1, samples);<br />
tempvals = zeros(1, samples);<br />
<br />
try<br />
fopen(s);<br />
index = 1;<br />
while index <= samples<br />
[out, count] = fscanf(s, '%c');<br />
if count == 14<br />
%disp(out);<br />
st = strsplit(out, ';');<br />
%disp(st);<br />
if numel(st) == 2<br />
tempvals(index) = str2num(st{1});<br />
RFIDvals(index) = str2num(st{2});<br />
index = index + 1;<br />
end<br />
end<br />
end<br />
catch err<br />
disp('Error while running script');<br />
disp(err);<br />
end<br />
fclose(s);<br />
delete(s);<br />
clear s;<br />
end<br />
</nowiki><br />
<br />
Deze functie werd gebruikt voor tests van de sensoren, het weergeeft een live plot van de gemeten waarden.<br />
<nowiki><br />
function [] = readAndPlotValues( samples )<br />
%UNTITLED Summary of this function goes here<br />
% Detailed explanation goes here<br />
<br />
i = 1;<br />
figure(1); <br />
lHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
figure(2);<br />
llHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
while 1 == 1<br />
[rfid, tmp] = readRFIDTemp(samples);<br />
rfidMean = mean(rfid);<br />
tmpMean = mean(tmp);<br />
<br />
Y = get(lHandle, 'YData');<br />
Y = [Y rfidMean];<br />
X = get(lHandle, 'XData');<br />
X = [X i];<br />
<br />
set(lHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
<br />
Y = get(llHandle, 'YData');<br />
Y = [Y tmpMean];<br />
X = get(llHandle, 'XData');<br />
X = [X i];<br />
<br />
set(llHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
i = i + 1;<br />
end<br />
<br />
end<br />
</nowiki><br />
<br />
===Bronnen===<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van het gemiddelde daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster.<br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR'''' Voor de corrigeerden IR data in procentpunten<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
end <br />
<br />
'''RIFBAR''' Voor de RFID data in procentpunten<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
end<br />
<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
[[File:both.png|thumb|right|Figuur 3: Vergelijking van 30 samples en 500 samples (meting 1)]]<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na 30 samples al heel erg vergelijkbaar als bij 500 samples, zoals zichtbaar in figuur 3. De pieken verschillen op sommige plekken, maar in groten lijnen blijven de RFID-plekken duidelijk zichtbaar. <br />
In het geval van de temperatuursensor, was 1 sample zelfs al genoeg.<br />
<br />
Vanuit de Arduino kwamen er elke 10ms een sample. In dit geval zou er dus in 300ms genoeg data verzameld kunnen worden voor een hokje van 9 bij 8.5 mm. In dit geval zou de robot per m^2 3921.56862744 seconde nodig hebben, oftewel een iets meer dan een uur en 5 min. Om ervoor te zorgen dat binnen 5 min toch zeker een gebied ter grootte van een paar duizend vierkante meter onderzocht kan worden, zullen de hokjes van 0.0000765 m^2 vergroot moeten worden tot minimaal 5m^2 per hokje.<br />
<br />
Een andere mogelijkheid is meer samples binnen te krijgen. Dit is zeker mogelijk, al is hier een krachtigere processor voor nodig, meer samples per seconde kan de Arduino niet verwerken.<br />
<br />
=Conclusies=<br />
==Discussie betrouwbaarheid==<br />
Door de data te verwerken en daarna te vergelijken met de bekende werelden kunnen er conclusies over de betrouwbaarheid getrokken worden.<br />
===RFID signaal=== <br />
1. Het RFID signaal had een zwakke reactie, de verschillen tussen het hoogste signaal (hokje met een RFID-tag) en het laagste was maximaal 1,6169 mV.<br />
<br />
2. Het RFID signaal gaf in het hokje met een RFID signaal een heel duidelijk signaal, het signaal in de hokjes eromheen (ong. 8cm afstand) gaf in de meeste gevallen een lager (maar zichtbaar) verschil. <br />
<br />
3. Sommige hokjes kregen een heel onverwacht hoge of lage waarde, dit kan te wijden zijn aan:<br />
:a. Meetfouten.<br />
:b. Meerdere RFID-signalen van verschillende tags die met elkaar interfereren.<br />
::Radiogolven met dezelfde frequentie elkaar in tegen-fase kunnen uitdoven, kunnen golven in fase elkaar juist versterken.<br />
<br />
===Hitte signaal===<br />
- Het hitte signaal was betrouwbaar, maar ook op een afstand tot maximaal 16cm.<br />
<br />
==Conclusie Experiment en discussie uitbreiding==<br />
Ondanks de problemen en onverwacht zwakke RFID sensor hebben we toch nuttige conclusies kunnen trekken dankzij het experiment. <br />
Zoals de grafieken die gegenereerd zijn op basis van de meetresultaten van ons experiment laten zien is het aardig mogelijk om te bepalen op welke locaties er mensen zijn, gegeven dat deze een lichaamstemperatuur hebben die boven de omgevingstemperatuur zit, en ze een RFID tag bij zich hebben.<br />
<br />
Kijkende naar de meetresultaten van ons experiment doet zich al snel de vraag voor hoe men op grotere afstanden RFID tags kan lezen. Dit hangt o.a. af van de frequentie, de grootte van de antenne, de grootte van de tag, en de sterkte van de stroom die door de antenne loopt. Bij ons experiment hebben we gebruik gemaakt van een RFID antenne en tags die werken op 13.56Mhz. Dit geeft een theoretische maximale leesafstand van 1.5 meter[1]. Onze antenne bleek hier helaas niet sterk genoeg voor. Dit is echter goed te verhelpen door gebruiken te maken van de (inmiddels zeer populaire)EPC Gen2 RFID tags[2]. Deze opereren op hogere frequenties, en maken bovendien niet meer gebruik van Near Field Communication (dit is datatransmissie op basis van het elektromagnetisch veld van de antenne, wij gebruikten dit in ons experiment) maar gebruiken radar technieken. hierdoor wordt de leesafstand dramatisch vergroot. Chris Paget stelt zelfs dat in theorie een leesafstand van meer dan 1.5km bereikt kan worden (alhoewel dit waarschijnlijk niet een mobiele installatie zou zijn).<br />
<br />
Het lezen van de temperatuur ging prima op kleine schaal. Onze verwachting is dat het geen probleem is om gelijkwaardige al-dan-niet betere warmte sensoren te vinden voor afstanden tot 10 meter, bijvoorbeeld gebruikmakende van dezelfde technieken als een warmte camera of een warmte meetapparaat zoals de Extech VIR50 [3].<br />
<br />
<br />
===Bronnen===<br />
* [1] RFID Tag Maximum Read Distance - http://skyrfid.com/RFID_Tag_Read_Ranges.php<br />
* [2] Extreme-range RFID tracking, Chris Paget, presented at Blackhat USA 2010 - http://www.tombom.co.uk/extreme_rfid.pdf<br />
* [3] Extech VIR50 - http://www.extech.com/instruments/product.asp?catid=62&prodid=653<br />
<br />
==Verdere discussie==<br />
De grootte van het raster hebben wij in het experiment zo gekozen dat de Arduino goed in een hokje past. Dit uit comfort overwegingen tijdens het meten.<br />
Deze grootte hoeft echter niet vast te staan; We zouden de grootte kunnen proberen te bepalen naar de hand van enkele variabelen die per situatie anders kunnen zijn, bijvoorbeeld breedte/lengte van de ruimte waarin de robot gebruikt gaat worden. Ook kan de grootte samenhangen met het pathfinding algorithme; Stel dat de robot begint met zoeken in hele grote hokjes, en als in een van de grote hokjes een afwijkend signaal gedetecteerd wordt verandert de robot de grootte van de hokjes waarin hij gaat scannen en scant vervolgens nog een keer het grote hokje door om een preciezere locatie te kunnen bepalen.<br />
Op de vraag of er een optimale grote is voor de hokjes van het raster is dus niet een kort en eenvoudig antwoord te geven. Hiervoor zal apart onderzoek gedaan moeten worden.<br />
<br />
[[PRE2_Groep2|Terug naar hoofdpagina]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17529PRE2Groep2 Experiment2015-01-16T02:46:01Z<p>S127922: /* Tijdsduur */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het experiment. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
==Arduino==<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC op de PN532 deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op een analoge input pin van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar MATLAB op een van onze computers. in MATLAB worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
===Pin allocatie===<br />
De pins van de Arduino zijn als volgt in gebruik:<br />
* SCA : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* SCL : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* Aref : PN532 RFID Shield<br />
* Digital I/O 0-13 : PN532 RFID Shield<br />
* IOREF: PN532 RFID Shield<br />
* RESET: PN532 RFID Shield<br />
* 3V: PN532 RFID Shield<br />
* Vin: PN532 RFID Shield<br />
* Analog in 0-5: PN532 RFID Shield<br />
* Analog in 7: PN532 RFID Shield Antenne<br />
<br />
Verder zijn zowel de thermopile als het RFID shield gekoppeld aan 5V en gnd op verschillende plaatsen. Deze pins zijn voor de PN532 tussen de Digital I/O en SCA, en tussen Vin en 3V.<br />
Voor de thermopile zijn deze onderaan het board, ground links en 5V rechts.<br />
[[File:ArduinoPinouts.png|right|thumb|350px|Overzicht Arduino pinouts]]<br />
<br />
===Broncode===<br />
De broncode om de signalen naar MATLAB te lezen bestaat uit 4 onderdelen:<br />
* De TMP006 library om temperatuur in te lezen[2]<br />
* De NFC Library om het RFID shield te gebruiken[4], met enkele aanpassingen<br />
* Het Arduino programma dat de samples verzamelt en naar de computer stuurt<br />
* Het MATlab script dat deze samples opvangt en in matrices stopt<br />
<br />
Voor de code van de gebruikte libraries, zie de GitHub links in de bronnenlijst.<br />
<br />
====Arduino Programma====<br />
<nowiki><br />
#include <Wire.h><br />
#include <Adafruit_NFCShield_I2C.h><br />
#include <math.h><br />
#include <stdint.h> <br />
#include "I2C_16.h"<br />
#include "TMP006.h"<br />
<br />
#define IRQ (2)<br />
#define RESET (3) // Not connected by default on the NFC Shield<br />
#define SAMPLES_PER_READING (10) // 1 - 255<br />
uint8_t tempID = 0x40; // I2C address of TMP006, can be 0x40-0x47 (would have to wire the address pins)<br />
uint16_t samples = TMP006_CFG_1SAMPLE; // # of samples per reading, can be 1/2/4/8/16<br />
<br />
Adafruit_NFCShield_I2C nfc(IRQ, RESET);<br />
<br />
void setup(void) {<br />
Serial.begin(115200);<br />
<br />
//init PN53x<br />
nfc.begin();<br />
<br />
//init tmp006<br />
config_TMP006(tempID, samples);<br />
<br />
uint32_t versiondata = nfc.getFirmwareVersion();<br />
if (! versiondata) {<br />
Serial.print("Didn't find PN53x board");<br />
while (1); // halt<br />
}<br />
<br />
// Got ok data, print it out!<br />
Serial.print("Found chip PN5"); <br />
Serial.println((versiondata>>24) & 0xFF, HEX); <br />
Serial.print("Firmware ver. "); <br />
Serial.print((versiondata>>16) & 0xFF, DEC); <br />
Serial.print('.'); <br />
Serial.println((versiondata>>8) & 0xFF, DEC);<br />
<br />
// 0xFF = forever<br />
nfc.setPassiveActivationRetries(0xFF);<br />
<br />
// configure board to read RFID tags<br />
nfc.SAMConfig();<br />
<br />
Serial.println("Listening for an ISO14443A card");<br />
nfc.listenPassiveTarget(PN532_MIFARE_ISO14443A);<br />
}<br />
<br />
void loop() { <br />
uint8_t i = 0;<br />
float samplestotal = 0.0;<br />
<br />
for(i = 0; i < SAMPLES_PER_READING; i++) {<br />
samplestotal += analogRead(7);<br />
}<br />
<br />
float sigstrength = samplestotal / SAMPLES_PER_READING; <br />
<br />
float object_temp = readObjTempC(tempID);<br />
Serial.print(object_temp); <br />
Serial.print(";");<br />
Serial.println(sigstrength);<br />
}<br />
</nowiki><br />
<br />
====Extra functie NFC library====<br />
Deze functie zorgt ervoor dat de RFID antenne permanent aan het meten is, waardoor wij vervolgens de mogelijkheid hebben (gebruikmakende van de kabel die we vanaf het RFID shield naar Analog in 7 hebben geleid) om de signaalsterkte direct af te lezen.<br />
<nowiki><br />
/* In header file */<br />
boolean listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout = 0);<br />
<br />
/* In CPP file */<br />
boolean Adafruit_NFCShield_I2C::listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout) {<br />
pn532_packetbuffer[0] = PN532_COMMAND_INLISTPASSIVETARGET;<br />
pn532_packetbuffer[1] = 1; // max 2 cards at once (untested)<br />
pn532_packetbuffer[2] = cardbaudrate;<br />
<br />
if (! sendCommandCheckAck(pn532_packetbuffer, 3, timeout))<br />
{<br />
#ifdef PN532DEBUG<br />
Serial.println(F("No card(s) read"));<br />
#endif<br />
return 0; // no cards read<br />
}<br />
<br />
return 1;<br />
}<br />
</nowiki><br />
<br />
====MATlab code====<br />
<br />
Deze functie werd gebruikt voor het meten van <samples> samples in één cel in het raster (Werd dus voor iedere cel aangeroepen)<br />
<nowiki><br />
function [ RFIDvals, tempvals ] = readRFIDTemp( samples )<br />
%READRFIDTEMP Summary of this function goes here<br />
% Detailed explanation goes here<br />
s = serial('COM3', 'BaudRate', 115200);<br />
RFIDvals = zeros(1, samples);<br />
tempvals = zeros(1, samples);<br />
<br />
try<br />
fopen(s);<br />
index = 1;<br />
while index <= samples<br />
[out, count] = fscanf(s, '%c');<br />
if count == 14<br />
%disp(out);<br />
st = strsplit(out, ';');<br />
%disp(st);<br />
if numel(st) == 2<br />
tempvals(index) = str2num(st{1});<br />
RFIDvals(index) = str2num(st{2});<br />
index = index + 1;<br />
end<br />
end<br />
end<br />
catch err<br />
disp('Error while running script');<br />
disp(err);<br />
end<br />
fclose(s);<br />
delete(s);<br />
clear s;<br />
end<br />
</nowiki><br />
<br />
Deze functie werd gebruikt voor tests van de sensoren, het weergeeft een live plot van de gemeten waarden.<br />
<nowiki><br />
function [] = readAndPlotValues( samples )<br />
%UNTITLED Summary of this function goes here<br />
% Detailed explanation goes here<br />
<br />
i = 1;<br />
figure(1); <br />
lHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
figure(2);<br />
llHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
while 1 == 1<br />
[rfid, tmp] = readRFIDTemp(samples);<br />
rfidMean = mean(rfid);<br />
tmpMean = mean(tmp);<br />
<br />
Y = get(lHandle, 'YData');<br />
Y = [Y rfidMean];<br />
X = get(lHandle, 'XData');<br />
X = [X i];<br />
<br />
set(lHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
<br />
Y = get(llHandle, 'YData');<br />
Y = [Y tmpMean];<br />
X = get(llHandle, 'XData');<br />
X = [X i];<br />
<br />
set(llHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
i = i + 1;<br />
end<br />
<br />
end<br />
</nowiki><br />
<br />
===Bronnen===<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van het gemiddelde daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster.<br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR'''' Voor de corrigeerden IR data in procentpunten<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
end <br />
<br />
'''RIFBAR''' Voor de RFID data in procentpunten<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
end<br />
<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
[[File:both.png|thumb|right|Figuur 3: Vergelijking van 30 samples en 500 samples (meting 1)]]<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na 30 samples al heel erg vergelijkbaar als bij 500 samples, zoals zichtbaar in figuur 3. De pieken verschillen op sommige plekken, maar in groten lijnen blijven de RFID-plekken duidelijk zichtbaar. <br />
In het geval van de temperatuursensor, was 1 sample zelfs al genoeg.<br />
<br />
Vanuit de Arduino kwamen er elke 10ms een sample. In dit geval zou er dus in 300ms genoeg data verzameld kunnen worden voor een hokje van 9 bij 8.5 mm. In dit geval zou de robot per m^2 3921.56862744 seconde nodig hebben, oftewel een iets meer dan een uur en 5 min. Om ervoor te zorgen dat binnen 5 min toch zeker een gebied ter grootte van een paar duizend vierkante meter, zullen de hokjes van 0.0000765 m^2 naar 5m^2 moeten gaan.<br />
<br />
Een andere mogelijkheid is meer samples binnen te krijgen. Dit is zeker mogelijk, al is hier een krachtigere processor voor nodig, meer samples per seconde kan de Arduino niet verwerken.<br />
<br />
=Conclusies=<br />
==Discussie betrouwbaarheid==<br />
Door de data te verwerken en daarna te vergelijken met de bekende werelden kunnen er conclusies over de betrouwbaarheid getrokken worden.<br />
===RFID signaal=== <br />
1. Het RFID signaal had een zwakke reactie, de verschillen tussen het hoogste signaal (hokje met een RFID-tag) en het laagste was maximaal 1,6169 mV.<br />
<br />
2. Het RFID signaal gaf in het hokje met een RFID signaal een heel duidelijk signaal, het signaal in de hokjes eromheen (ong. 8cm afstand) gaf in de meeste gevallen een lager (maar zichtbaar) verschil. <br />
<br />
3. Sommige hokjes kregen een heel onverwacht hoge of lage waarde, dit kan te wijden zijn aan:<br />
:a. Meetfouten.<br />
:b. Meerdere RFID-signalen van verschillende tags die met elkaar interfereren.<br />
::Radiogolven met dezelfde frequentie elkaar in tegen-fase kunnen uitdoven, kunnen golven in fase elkaar juist versterken.<br />
<br />
===Hitte signaal===<br />
- Het hitte signaal was betrouwbaar, maar ook op een afstand tot maximaal 16cm.<br />
<br />
==Conclusie Experiment en discussie uitbreiding==<br />
Ondanks de problemen en onverwacht zwakke RFID sensor hebben we toch nuttige conclusies kunnen trekken dankzij het experiment. <br />
Zoals de grafieken die gegenereerd zijn op basis van de meetresultaten van ons experiment laten zien is het aardig mogelijk om te bepalen op welke locaties er mensen zijn, gegeven dat deze een lichaamstemperatuur hebben die boven de omgevingstemperatuur zit, en ze een RFID tag bij zich hebben.<br />
<br />
Kijkende naar de meetresultaten van ons experiment doet zich al snel de vraag voor hoe men op grotere afstanden RFID tags kan lezen. Dit hangt o.a. af van de frequentie, de grootte van de antenne, de grootte van de tag, en de sterkte van de stroom die door de antenne loopt. Bij ons experiment hebben we gebruik gemaakt van een RFID antenne en tags die werken op 13.56Mhz. Dit geeft een theoretische maximale leesafstand van 1.5 meter[1]. Onze antenne bleek hier helaas niet sterk genoeg voor. Dit is echter goed te verhelpen door gebruiken te maken van de (inmiddels zeer populaire)EPC Gen2 RFID tags[2]. Deze opereren op hogere frequenties, en maken bovendien niet meer gebruik van Near Field Communication (dit is datatransmissie op basis van het elektromagnetisch veld van de antenne, wij gebruikten dit in ons experiment) maar gebruiken radar technieken. hierdoor wordt de leesafstand dramatisch vergroot. Chris Paget stelt zelfs dat in theorie een leesafstand van meer dan 1.5km bereikt kan worden (alhoewel dit waarschijnlijk niet een mobiele installatie zou zijn).<br />
<br />
Het lezen van de temperatuur ging prima op kleine schaal. Onze verwachting is dat het geen probleem is om gelijkwaardige al-dan-niet betere warmte sensoren te vinden voor afstanden tot 10 meter, bijvoorbeeld gebruikmakende van dezelfde technieken als een warmte camera of een warmte meetapparaat zoals de Extech VIR50 [3].<br />
<br />
<br />
===Bronnen===<br />
* [1] RFID Tag Maximum Read Distance - http://skyrfid.com/RFID_Tag_Read_Ranges.php<br />
* [2] Extreme-range RFID tracking, Chris Paget, presented at Blackhat USA 2010 - http://www.tombom.co.uk/extreme_rfid.pdf<br />
* [3] Extech VIR50 - http://www.extech.com/instruments/product.asp?catid=62&prodid=653<br />
<br />
==Verdere discussie==<br />
De grootte van het raster hebben wij in het experiment zo gekozen dat de Arduino goed in een hokje past. Dit uit comfort overwegingen tijdens het meten.<br />
Deze grootte hoeft echter niet vast te staan; We zouden de grootte kunnen proberen te bepalen naar de hand van enkele variabelen die per situatie anders kunnen zijn, bijvoorbeeld breedte/lengte van de ruimte waarin de robot gebruikt gaat worden. Ook kan de grootte samenhangen met het pathfinding algorithme; Stel dat de robot begint met zoeken in hele grote hokjes, en als in een van de grote hokjes een afwijkend signaal gedetecteerd wordt verandert de robot de grootte van de hokjes waarin hij gaat scannen en scant vervolgens nog een keer het grote hokje door om een preciezere locatie te kunnen bepalen.<br />
Op de vraag of er een optimale grote is voor de hokjes van het raster is dus niet een kort en eenvoudig antwoord te geven. Hiervoor zal apart onderzoek gedaan moeten worden.<br />
<br />
[[PRE2_Groep2|Terug naar hoofdpagina]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17528PRE2Groep2 Experiment2015-01-16T02:45:07Z<p>S127922: /* Discussie betrouwbaarheid */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het experiment. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
==Arduino==<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC op de PN532 deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op een analoge input pin van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar MATLAB op een van onze computers. in MATLAB worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
===Pin allocatie===<br />
De pins van de Arduino zijn als volgt in gebruik:<br />
* SCA : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* SCL : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* Aref : PN532 RFID Shield<br />
* Digital I/O 0-13 : PN532 RFID Shield<br />
* IOREF: PN532 RFID Shield<br />
* RESET: PN532 RFID Shield<br />
* 3V: PN532 RFID Shield<br />
* Vin: PN532 RFID Shield<br />
* Analog in 0-5: PN532 RFID Shield<br />
* Analog in 7: PN532 RFID Shield Antenne<br />
<br />
Verder zijn zowel de thermopile als het RFID shield gekoppeld aan 5V en gnd op verschillende plaatsen. Deze pins zijn voor de PN532 tussen de Digital I/O en SCA, en tussen Vin en 3V.<br />
Voor de thermopile zijn deze onderaan het board, ground links en 5V rechts.<br />
[[File:ArduinoPinouts.png|right|thumb|350px|Overzicht Arduino pinouts]]<br />
<br />
===Broncode===<br />
De broncode om de signalen naar MATLAB te lezen bestaat uit 4 onderdelen:<br />
* De TMP006 library om temperatuur in te lezen[2]<br />
* De NFC Library om het RFID shield te gebruiken[4], met enkele aanpassingen<br />
* Het Arduino programma dat de samples verzamelt en naar de computer stuurt<br />
* Het MATlab script dat deze samples opvangt en in matrices stopt<br />
<br />
Voor de code van de gebruikte libraries, zie de GitHub links in de bronnenlijst.<br />
<br />
====Arduino Programma====<br />
<nowiki><br />
#include <Wire.h><br />
#include <Adafruit_NFCShield_I2C.h><br />
#include <math.h><br />
#include <stdint.h> <br />
#include "I2C_16.h"<br />
#include "TMP006.h"<br />
<br />
#define IRQ (2)<br />
#define RESET (3) // Not connected by default on the NFC Shield<br />
#define SAMPLES_PER_READING (10) // 1 - 255<br />
uint8_t tempID = 0x40; // I2C address of TMP006, can be 0x40-0x47 (would have to wire the address pins)<br />
uint16_t samples = TMP006_CFG_1SAMPLE; // # of samples per reading, can be 1/2/4/8/16<br />
<br />
Adafruit_NFCShield_I2C nfc(IRQ, RESET);<br />
<br />
void setup(void) {<br />
Serial.begin(115200);<br />
<br />
//init PN53x<br />
nfc.begin();<br />
<br />
//init tmp006<br />
config_TMP006(tempID, samples);<br />
<br />
uint32_t versiondata = nfc.getFirmwareVersion();<br />
if (! versiondata) {<br />
Serial.print("Didn't find PN53x board");<br />
while (1); // halt<br />
}<br />
<br />
// Got ok data, print it out!<br />
Serial.print("Found chip PN5"); <br />
Serial.println((versiondata>>24) & 0xFF, HEX); <br />
Serial.print("Firmware ver. "); <br />
Serial.print((versiondata>>16) & 0xFF, DEC); <br />
Serial.print('.'); <br />
Serial.println((versiondata>>8) & 0xFF, DEC);<br />
<br />
// 0xFF = forever<br />
nfc.setPassiveActivationRetries(0xFF);<br />
<br />
// configure board to read RFID tags<br />
nfc.SAMConfig();<br />
<br />
Serial.println("Listening for an ISO14443A card");<br />
nfc.listenPassiveTarget(PN532_MIFARE_ISO14443A);<br />
}<br />
<br />
void loop() { <br />
uint8_t i = 0;<br />
float samplestotal = 0.0;<br />
<br />
for(i = 0; i < SAMPLES_PER_READING; i++) {<br />
samplestotal += analogRead(7);<br />
}<br />
<br />
float sigstrength = samplestotal / SAMPLES_PER_READING; <br />
<br />
float object_temp = readObjTempC(tempID);<br />
Serial.print(object_temp); <br />
Serial.print(";");<br />
Serial.println(sigstrength);<br />
}<br />
</nowiki><br />
<br />
====Extra functie NFC library====<br />
Deze functie zorgt ervoor dat de RFID antenne permanent aan het meten is, waardoor wij vervolgens de mogelijkheid hebben (gebruikmakende van de kabel die we vanaf het RFID shield naar Analog in 7 hebben geleid) om de signaalsterkte direct af te lezen.<br />
<nowiki><br />
/* In header file */<br />
boolean listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout = 0);<br />
<br />
/* In CPP file */<br />
boolean Adafruit_NFCShield_I2C::listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout) {<br />
pn532_packetbuffer[0] = PN532_COMMAND_INLISTPASSIVETARGET;<br />
pn532_packetbuffer[1] = 1; // max 2 cards at once (untested)<br />
pn532_packetbuffer[2] = cardbaudrate;<br />
<br />
if (! sendCommandCheckAck(pn532_packetbuffer, 3, timeout))<br />
{<br />
#ifdef PN532DEBUG<br />
Serial.println(F("No card(s) read"));<br />
#endif<br />
return 0; // no cards read<br />
}<br />
<br />
return 1;<br />
}<br />
</nowiki><br />
<br />
====MATlab code====<br />
<br />
Deze functie werd gebruikt voor het meten van <samples> samples in één cel in het raster (Werd dus voor iedere cel aangeroepen)<br />
<nowiki><br />
function [ RFIDvals, tempvals ] = readRFIDTemp( samples )<br />
%READRFIDTEMP Summary of this function goes here<br />
% Detailed explanation goes here<br />
s = serial('COM3', 'BaudRate', 115200);<br />
RFIDvals = zeros(1, samples);<br />
tempvals = zeros(1, samples);<br />
<br />
try<br />
fopen(s);<br />
index = 1;<br />
while index <= samples<br />
[out, count] = fscanf(s, '%c');<br />
if count == 14<br />
%disp(out);<br />
st = strsplit(out, ';');<br />
%disp(st);<br />
if numel(st) == 2<br />
tempvals(index) = str2num(st{1});<br />
RFIDvals(index) = str2num(st{2});<br />
index = index + 1;<br />
end<br />
end<br />
end<br />
catch err<br />
disp('Error while running script');<br />
disp(err);<br />
end<br />
fclose(s);<br />
delete(s);<br />
clear s;<br />
end<br />
</nowiki><br />
<br />
Deze functie werd gebruikt voor tests van de sensoren, het weergeeft een live plot van de gemeten waarden.<br />
<nowiki><br />
function [] = readAndPlotValues( samples )<br />
%UNTITLED Summary of this function goes here<br />
% Detailed explanation goes here<br />
<br />
i = 1;<br />
figure(1); <br />
lHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
figure(2);<br />
llHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
while 1 == 1<br />
[rfid, tmp] = readRFIDTemp(samples);<br />
rfidMean = mean(rfid);<br />
tmpMean = mean(tmp);<br />
<br />
Y = get(lHandle, 'YData');<br />
Y = [Y rfidMean];<br />
X = get(lHandle, 'XData');<br />
X = [X i];<br />
<br />
set(lHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
<br />
Y = get(llHandle, 'YData');<br />
Y = [Y tmpMean];<br />
X = get(llHandle, 'XData');<br />
X = [X i];<br />
<br />
set(llHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
i = i + 1;<br />
end<br />
<br />
end<br />
</nowiki><br />
<br />
===Bronnen===<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van het gemiddelde daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster.<br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR'''' Voor de corrigeerden IR data in procentpunten<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
end <br />
<br />
'''RIFBAR''' Voor de RFID data in procentpunten<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
end<br />
<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
[[File:both.png|thumb|right|Figuur 3: Vergelijking van 30 samples en 500 samples (meting 1)]]<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na 30 samples al heel erg vergelijkbaar als bij 500 samples, zoals zichtbaar in figuur 3. De pieken verschillen op sommige plekken, maar in groten lijnen blijven de RFID-plekken duidelijk zichtbaar. <br />
In het geval van de temperatuursensor, was 1 sample zelfs al genoeg.<br />
<br />
Vanuit de Arduino kwamen er elke 10ms een sample. In dit geval zou er dus in 300ms genoeg data verzameld kunnen worden voor een hokje van 9 bij 8.5 mm. In dit geval zou de robot per m^2 3921.56862744 seconde nodig hebben, oftewel een iets meer dan een uur en 5 min. Om ervoor te zorgen dat binnen 5 min toch zeker een gebied ter grootte van een paar duizend vierkante meter, zullen de hokjes van 0.0000765 m^2 naar 5m^2 moeten gaan.<br />
<br />
Een andere mogelijkheid is meer samples binnen te krijgen. Deze is zeker mogelijk, al is hier een krachtigere processor voor nodig, meer samples per seconde kan de Arduino niet verwerken.<br />
<br />
=Conclusies=<br />
==Discussie betrouwbaarheid==<br />
Door de data te verwerken en daarna te vergelijken met de bekende werelden kunnen er conclusies over de betrouwbaarheid getrokken worden.<br />
===RFID signaal=== <br />
1. Het RFID signaal had een zwakke reactie, de verschillen tussen het hoogste signaal (hokje met een RFID-tag) en het laagste was maximaal 1,6169 mV.<br />
<br />
2. Het RFID signaal gaf in het hokje met een RFID signaal een heel duidelijk signaal, het signaal in de hokjes eromheen (ong. 8cm afstand) gaf in de meeste gevallen een lager (maar zichtbaar) verschil. <br />
<br />
3. Sommige hokjes kregen een heel onverwacht hoge of lage waarde, dit kan te wijden zijn aan:<br />
:a. Meetfouten.<br />
:b. Meerdere RFID-signalen van verschillende tags die met elkaar interfereren.<br />
::Radiogolven met dezelfde frequentie elkaar in tegen-fase kunnen uitdoven, kunnen golven in fase elkaar juist versterken.<br />
<br />
===Hitte signaal===<br />
- Het hitte signaal was betrouwbaar, maar ook op een afstand tot maximaal 16cm.<br />
<br />
==Conclusie Experiment en discussie uitbreiding==<br />
Ondanks de problemen en onverwacht zwakke RFID sensor hebben we toch nuttige conclusies kunnen trekken dankzij het experiment. <br />
Zoals de grafieken die gegenereerd zijn op basis van de meetresultaten van ons experiment laten zien is het aardig mogelijk om te bepalen op welke locaties er mensen zijn, gegeven dat deze een lichaamstemperatuur hebben die boven de omgevingstemperatuur zit, en ze een RFID tag bij zich hebben.<br />
<br />
Kijkende naar de meetresultaten van ons experiment doet zich al snel de vraag voor hoe men op grotere afstanden RFID tags kan lezen. Dit hangt o.a. af van de frequentie, de grootte van de antenne, de grootte van de tag, en de sterkte van de stroom die door de antenne loopt. Bij ons experiment hebben we gebruik gemaakt van een RFID antenne en tags die werken op 13.56Mhz. Dit geeft een theoretische maximale leesafstand van 1.5 meter[1]. Onze antenne bleek hier helaas niet sterk genoeg voor. Dit is echter goed te verhelpen door gebruiken te maken van de (inmiddels zeer populaire)EPC Gen2 RFID tags[2]. Deze opereren op hogere frequenties, en maken bovendien niet meer gebruik van Near Field Communication (dit is datatransmissie op basis van het elektromagnetisch veld van de antenne, wij gebruikten dit in ons experiment) maar gebruiken radar technieken. hierdoor wordt de leesafstand dramatisch vergroot. Chris Paget stelt zelfs dat in theorie een leesafstand van meer dan 1.5km bereikt kan worden (alhoewel dit waarschijnlijk niet een mobiele installatie zou zijn).<br />
<br />
Het lezen van de temperatuur ging prima op kleine schaal. Onze verwachting is dat het geen probleem is om gelijkwaardige al-dan-niet betere warmte sensoren te vinden voor afstanden tot 10 meter, bijvoorbeeld gebruikmakende van dezelfde technieken als een warmte camera of een warmte meetapparaat zoals de Extech VIR50 [3].<br />
<br />
<br />
===Bronnen===<br />
* [1] RFID Tag Maximum Read Distance - http://skyrfid.com/RFID_Tag_Read_Ranges.php<br />
* [2] Extreme-range RFID tracking, Chris Paget, presented at Blackhat USA 2010 - http://www.tombom.co.uk/extreme_rfid.pdf<br />
* [3] Extech VIR50 - http://www.extech.com/instruments/product.asp?catid=62&prodid=653<br />
<br />
==Verdere discussie==<br />
De grootte van het raster hebben wij in het experiment zo gekozen dat de Arduino goed in een hokje past. Dit uit comfort overwegingen tijdens het meten.<br />
Deze grootte hoeft echter niet vast te staan; We zouden de grootte kunnen proberen te bepalen naar de hand van enkele variabelen die per situatie anders kunnen zijn, bijvoorbeeld breedte/lengte van de ruimte waarin de robot gebruikt gaat worden. Ook kan de grootte samenhangen met het pathfinding algorithme; Stel dat de robot begint met zoeken in hele grote hokjes, en als in een van de grote hokjes een afwijkend signaal gedetecteerd wordt verandert de robot de grootte van de hokjes waarin hij gaat scannen en scant vervolgens nog een keer het grote hokje door om een preciezere locatie te kunnen bepalen.<br />
Op de vraag of er een optimale grote is voor de hokjes van het raster is dus niet een kort en eenvoudig antwoord te geven. Hiervoor zal apart onderzoek gedaan moeten worden.<br />
<br />
[[PRE2_Groep2|Terug naar hoofdpagina]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17527PRE2Groep2 Experiment2015-01-16T02:43:49Z<p>S127922: /* Tijdsduur */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het experiment. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
==Arduino==<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC op de PN532 deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op een analoge input pin van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar MATLAB op een van onze computers. in MATLAB worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
===Pin allocatie===<br />
De pins van de Arduino zijn als volgt in gebruik:<br />
* SCA : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* SCL : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* Aref : PN532 RFID Shield<br />
* Digital I/O 0-13 : PN532 RFID Shield<br />
* IOREF: PN532 RFID Shield<br />
* RESET: PN532 RFID Shield<br />
* 3V: PN532 RFID Shield<br />
* Vin: PN532 RFID Shield<br />
* Analog in 0-5: PN532 RFID Shield<br />
* Analog in 7: PN532 RFID Shield Antenne<br />
<br />
Verder zijn zowel de thermopile als het RFID shield gekoppeld aan 5V en gnd op verschillende plaatsen. Deze pins zijn voor de PN532 tussen de Digital I/O en SCA, en tussen Vin en 3V.<br />
Voor de thermopile zijn deze onderaan het board, ground links en 5V rechts.<br />
[[File:ArduinoPinouts.png|right|thumb|350px|Overzicht Arduino pinouts]]<br />
<br />
===Broncode===<br />
De broncode om de signalen naar MATLAB te lezen bestaat uit 4 onderdelen:<br />
* De TMP006 library om temperatuur in te lezen[2]<br />
* De NFC Library om het RFID shield te gebruiken[4], met enkele aanpassingen<br />
* Het Arduino programma dat de samples verzamelt en naar de computer stuurt<br />
* Het MATlab script dat deze samples opvangt en in matrices stopt<br />
<br />
Voor de code van de gebruikte libraries, zie de GitHub links in de bronnenlijst.<br />
<br />
====Arduino Programma====<br />
<nowiki><br />
#include <Wire.h><br />
#include <Adafruit_NFCShield_I2C.h><br />
#include <math.h><br />
#include <stdint.h> <br />
#include "I2C_16.h"<br />
#include "TMP006.h"<br />
<br />
#define IRQ (2)<br />
#define RESET (3) // Not connected by default on the NFC Shield<br />
#define SAMPLES_PER_READING (10) // 1 - 255<br />
uint8_t tempID = 0x40; // I2C address of TMP006, can be 0x40-0x47 (would have to wire the address pins)<br />
uint16_t samples = TMP006_CFG_1SAMPLE; // # of samples per reading, can be 1/2/4/8/16<br />
<br />
Adafruit_NFCShield_I2C nfc(IRQ, RESET);<br />
<br />
void setup(void) {<br />
Serial.begin(115200);<br />
<br />
//init PN53x<br />
nfc.begin();<br />
<br />
//init tmp006<br />
config_TMP006(tempID, samples);<br />
<br />
uint32_t versiondata = nfc.getFirmwareVersion();<br />
if (! versiondata) {<br />
Serial.print("Didn't find PN53x board");<br />
while (1); // halt<br />
}<br />
<br />
// Got ok data, print it out!<br />
Serial.print("Found chip PN5"); <br />
Serial.println((versiondata>>24) & 0xFF, HEX); <br />
Serial.print("Firmware ver. "); <br />
Serial.print((versiondata>>16) & 0xFF, DEC); <br />
Serial.print('.'); <br />
Serial.println((versiondata>>8) & 0xFF, DEC);<br />
<br />
// 0xFF = forever<br />
nfc.setPassiveActivationRetries(0xFF);<br />
<br />
// configure board to read RFID tags<br />
nfc.SAMConfig();<br />
<br />
Serial.println("Listening for an ISO14443A card");<br />
nfc.listenPassiveTarget(PN532_MIFARE_ISO14443A);<br />
}<br />
<br />
void loop() { <br />
uint8_t i = 0;<br />
float samplestotal = 0.0;<br />
<br />
for(i = 0; i < SAMPLES_PER_READING; i++) {<br />
samplestotal += analogRead(7);<br />
}<br />
<br />
float sigstrength = samplestotal / SAMPLES_PER_READING; <br />
<br />
float object_temp = readObjTempC(tempID);<br />
Serial.print(object_temp); <br />
Serial.print(";");<br />
Serial.println(sigstrength);<br />
}<br />
</nowiki><br />
<br />
====Extra functie NFC library====<br />
Deze functie zorgt ervoor dat de RFID antenne permanent aan het meten is, waardoor wij vervolgens de mogelijkheid hebben (gebruikmakende van de kabel die we vanaf het RFID shield naar Analog in 7 hebben geleid) om de signaalsterkte direct af te lezen.<br />
<nowiki><br />
/* In header file */<br />
boolean listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout = 0);<br />
<br />
/* In CPP file */<br />
boolean Adafruit_NFCShield_I2C::listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout) {<br />
pn532_packetbuffer[0] = PN532_COMMAND_INLISTPASSIVETARGET;<br />
pn532_packetbuffer[1] = 1; // max 2 cards at once (untested)<br />
pn532_packetbuffer[2] = cardbaudrate;<br />
<br />
if (! sendCommandCheckAck(pn532_packetbuffer, 3, timeout))<br />
{<br />
#ifdef PN532DEBUG<br />
Serial.println(F("No card(s) read"));<br />
#endif<br />
return 0; // no cards read<br />
}<br />
<br />
return 1;<br />
}<br />
</nowiki><br />
<br />
====MATlab code====<br />
<br />
Deze functie werd gebruikt voor het meten van <samples> samples in één cel in het raster (Werd dus voor iedere cel aangeroepen)<br />
<nowiki><br />
function [ RFIDvals, tempvals ] = readRFIDTemp( samples )<br />
%READRFIDTEMP Summary of this function goes here<br />
% Detailed explanation goes here<br />
s = serial('COM3', 'BaudRate', 115200);<br />
RFIDvals = zeros(1, samples);<br />
tempvals = zeros(1, samples);<br />
<br />
try<br />
fopen(s);<br />
index = 1;<br />
while index <= samples<br />
[out, count] = fscanf(s, '%c');<br />
if count == 14<br />
%disp(out);<br />
st = strsplit(out, ';');<br />
%disp(st);<br />
if numel(st) == 2<br />
tempvals(index) = str2num(st{1});<br />
RFIDvals(index) = str2num(st{2});<br />
index = index + 1;<br />
end<br />
end<br />
end<br />
catch err<br />
disp('Error while running script');<br />
disp(err);<br />
end<br />
fclose(s);<br />
delete(s);<br />
clear s;<br />
end<br />
</nowiki><br />
<br />
Deze functie werd gebruikt voor tests van de sensoren, het weergeeft een live plot van de gemeten waarden.<br />
<nowiki><br />
function [] = readAndPlotValues( samples )<br />
%UNTITLED Summary of this function goes here<br />
% Detailed explanation goes here<br />
<br />
i = 1;<br />
figure(1); <br />
lHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
figure(2);<br />
llHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
while 1 == 1<br />
[rfid, tmp] = readRFIDTemp(samples);<br />
rfidMean = mean(rfid);<br />
tmpMean = mean(tmp);<br />
<br />
Y = get(lHandle, 'YData');<br />
Y = [Y rfidMean];<br />
X = get(lHandle, 'XData');<br />
X = [X i];<br />
<br />
set(lHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
<br />
Y = get(llHandle, 'YData');<br />
Y = [Y tmpMean];<br />
X = get(llHandle, 'XData');<br />
X = [X i];<br />
<br />
set(llHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
i = i + 1;<br />
end<br />
<br />
end<br />
</nowiki><br />
<br />
===Bronnen===<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van het gemiddelde daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster.<br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR'''' Voor de corrigeerden IR data in procentpunten<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
end <br />
<br />
'''RIFBAR''' Voor de RFID data in procentpunten<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
end<br />
<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
[[File:both.png|thumb|right|Figuur 3: Vergelijking van 30 samples en 500 samples (meting 1)]]<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na 30 samples al heel erg vergelijkbaar als bij 500 samples, zoals zichtbaar in figuur 3. De pieken verschillen op sommige plekken, maar in groten lijnen blijven de RFID-plekken duidelijk zichtbaar. <br />
In het geval van de temperatuursensor, was 1 sample zelfs al genoeg.<br />
<br />
Vanuit de Arduino kwamen er elke 10ms een sample. In dit geval zou er dus in 300ms genoeg data verzameld kunnen worden voor een hokje van 9 bij 8.5 mm. In dit geval zou de robot per m^2 3921.56862744 seconde nodig hebben, oftewel een iets meer dan een uur en 5 min. Om ervoor te zorgen dat binnen 5 min toch zeker een gebied ter grootte van een paar duizend vierkante meter, zullen de hokjes van 0.0000765 m^2 naar 5m^2 moeten gaan.<br />
<br />
Een andere mogelijkheid is meer samples binnen te krijgen. Deze is zeker mogelijk, al is hier een krachtigere processor voor nodig, meer samples per seconde kan de Arduino niet verwerken.<br />
<br />
=Conclusies=<br />
==Discussie betrouwbaarheid==<br />
Door de data te verwerken en daarna te vergelijken met de bekende werelden kunnen er conclusies over de betrouwbaarheid getrokken worden.<br />
[[File:RIFD-500m1.png|right|thumb|300px|Figuur 1: RFID-signaalverschil in mV boven zwakste signaal]]<br />
===RFID signaal=== <br />
1. Het RFID signaal had een zwakke reactie, de verschillen tussen het hoogste signaal (hokje met een RFID-tag) en het laagste was maximaal 1,6169 mV.<br />
<br />
2. Het RFID signaal gaf in het hokje met een RFID signaal een heel duidelijk signaal, het signaal in de hokjes eromheen (ong. 8cm afstand) gaf in de meeste gevallen een lager (maar zichtbaar) verschil. <br />
<br />
3. Sommige hokjes kregen een heel onverwacht hoge of lage waarde, dit kan te wijden zijn aan:<br />
:a. Meetfouten.<br />
:b. Meerdere RFID-signalen van verschillende tags die met elkaar interfereren.<br />
::Radiogolven met dezelfde frequentie elkaar in tegen-fase kunnen uitdoven, kunnen golven in fase elkaar juist versterken.<br />
<br />
===Hitte signaal===<br />
- Het hitte signaal was betrouwbaar, maar ook op een afstand tot maximaal 16cm.<br />
<br />
<br />
==Conclusie Experiment en discussie uitbreiding==<br />
Ondanks de problemen en onverwacht zwakke RFID sensor hebben we toch nuttige conclusies kunnen trekken dankzij het experiment. <br />
Zoals de grafieken die gegenereerd zijn op basis van de meetresultaten van ons experiment laten zien is het aardig mogelijk om te bepalen op welke locaties er mensen zijn, gegeven dat deze een lichaamstemperatuur hebben die boven de omgevingstemperatuur zit, en ze een RFID tag bij zich hebben.<br />
<br />
Kijkende naar de meetresultaten van ons experiment doet zich al snel de vraag voor hoe men op grotere afstanden RFID tags kan lezen. Dit hangt o.a. af van de frequentie, de grootte van de antenne, de grootte van de tag, en de sterkte van de stroom die door de antenne loopt. Bij ons experiment hebben we gebruik gemaakt van een RFID antenne en tags die werken op 13.56Mhz. Dit geeft een theoretische maximale leesafstand van 1.5 meter[1]. Onze antenne bleek hier helaas niet sterk genoeg voor. Dit is echter goed te verhelpen door gebruiken te maken van de (inmiddels zeer populaire)EPC Gen2 RFID tags[2]. Deze opereren op hogere frequenties, en maken bovendien niet meer gebruik van Near Field Communication (dit is datatransmissie op basis van het elektromagnetisch veld van de antenne, wij gebruikten dit in ons experiment) maar gebruiken radar technieken. hierdoor wordt de leesafstand dramatisch vergroot. Chris Paget stelt zelfs dat in theorie een leesafstand van meer dan 1.5km bereikt kan worden (alhoewel dit waarschijnlijk niet een mobiele installatie zou zijn).<br />
<br />
Het lezen van de temperatuur ging prima op kleine schaal. Onze verwachting is dat het geen probleem is om gelijkwaardige al-dan-niet betere warmte sensoren te vinden voor afstanden tot 10 meter, bijvoorbeeld gebruikmakende van dezelfde technieken als een warmte camera of een warmte meetapparaat zoals de Extech VIR50 [3].<br />
<br />
<br />
===Bronnen===<br />
* [1] RFID Tag Maximum Read Distance - http://skyrfid.com/RFID_Tag_Read_Ranges.php<br />
* [2] Extreme-range RFID tracking, Chris Paget, presented at Blackhat USA 2010 - http://www.tombom.co.uk/extreme_rfid.pdf<br />
* [3] Extech VIR50 - http://www.extech.com/instruments/product.asp?catid=62&prodid=653<br />
<br />
==Verdere discussie==<br />
De grootte van het raster hebben wij in het experiment zo gekozen dat de Arduino goed in een hokje past. Dit uit comfort overwegingen tijdens het meten.<br />
Deze grootte hoeft echter niet vast te staan; We zouden de grootte kunnen proberen te bepalen naar de hand van enkele variabelen die per situatie anders kunnen zijn, bijvoorbeeld breedte/lengte van de ruimte waarin de robot gebruikt gaat worden. Ook kan de grootte samenhangen met het pathfinding algorithme; Stel dat de robot begint met zoeken in hele grote hokjes, en als in een van de grote hokjes een afwijkend signaal gedetecteerd wordt verandert de robot de grootte van de hokjes waarin hij gaat scannen en scant vervolgens nog een keer het grote hokje door om een preciezere locatie te kunnen bepalen.<br />
Op de vraag of er een optimale grote is voor de hokjes van het raster is dus niet een kort en eenvoudig antwoord te geven. Hiervoor zal apart onderzoek gedaan moeten worden.<br />
<br />
[[PRE2_Groep2|Terug naar hoofdpagina]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=File:Both.png&diff=17526File:Both.png2015-01-16T02:43:06Z<p>S127922: </p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17525PRE2Groep2 Experiment2015-01-16T02:42:35Z<p>S127922: /* Tijdsduur */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het experiment. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
==Arduino==<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC op de PN532 deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op een analoge input pin van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar MATLAB op een van onze computers. in MATLAB worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
===Pin allocatie===<br />
De pins van de Arduino zijn als volgt in gebruik:<br />
* SCA : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* SCL : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* Aref : PN532 RFID Shield<br />
* Digital I/O 0-13 : PN532 RFID Shield<br />
* IOREF: PN532 RFID Shield<br />
* RESET: PN532 RFID Shield<br />
* 3V: PN532 RFID Shield<br />
* Vin: PN532 RFID Shield<br />
* Analog in 0-5: PN532 RFID Shield<br />
* Analog in 7: PN532 RFID Shield Antenne<br />
<br />
Verder zijn zowel de thermopile als het RFID shield gekoppeld aan 5V en gnd op verschillende plaatsen. Deze pins zijn voor de PN532 tussen de Digital I/O en SCA, en tussen Vin en 3V.<br />
Voor de thermopile zijn deze onderaan het board, ground links en 5V rechts.<br />
[[File:ArduinoPinouts.png|right|thumb|350px|Overzicht Arduino pinouts]]<br />
<br />
===Broncode===<br />
De broncode om de signalen naar MATLAB te lezen bestaat uit 4 onderdelen:<br />
* De TMP006 library om temperatuur in te lezen[2]<br />
* De NFC Library om het RFID shield te gebruiken[4], met enkele aanpassingen<br />
* Het Arduino programma dat de samples verzamelt en naar de computer stuurt<br />
* Het MATlab script dat deze samples opvangt en in matrices stopt<br />
<br />
Voor de code van de gebruikte libraries, zie de GitHub links in de bronnenlijst.<br />
<br />
====Arduino Programma====<br />
<nowiki><br />
#include <Wire.h><br />
#include <Adafruit_NFCShield_I2C.h><br />
#include <math.h><br />
#include <stdint.h> <br />
#include "I2C_16.h"<br />
#include "TMP006.h"<br />
<br />
#define IRQ (2)<br />
#define RESET (3) // Not connected by default on the NFC Shield<br />
#define SAMPLES_PER_READING (10) // 1 - 255<br />
uint8_t tempID = 0x40; // I2C address of TMP006, can be 0x40-0x47 (would have to wire the address pins)<br />
uint16_t samples = TMP006_CFG_1SAMPLE; // # of samples per reading, can be 1/2/4/8/16<br />
<br />
Adafruit_NFCShield_I2C nfc(IRQ, RESET);<br />
<br />
void setup(void) {<br />
Serial.begin(115200);<br />
<br />
//init PN53x<br />
nfc.begin();<br />
<br />
//init tmp006<br />
config_TMP006(tempID, samples);<br />
<br />
uint32_t versiondata = nfc.getFirmwareVersion();<br />
if (! versiondata) {<br />
Serial.print("Didn't find PN53x board");<br />
while (1); // halt<br />
}<br />
<br />
// Got ok data, print it out!<br />
Serial.print("Found chip PN5"); <br />
Serial.println((versiondata>>24) & 0xFF, HEX); <br />
Serial.print("Firmware ver. "); <br />
Serial.print((versiondata>>16) & 0xFF, DEC); <br />
Serial.print('.'); <br />
Serial.println((versiondata>>8) & 0xFF, DEC);<br />
<br />
// 0xFF = forever<br />
nfc.setPassiveActivationRetries(0xFF);<br />
<br />
// configure board to read RFID tags<br />
nfc.SAMConfig();<br />
<br />
Serial.println("Listening for an ISO14443A card");<br />
nfc.listenPassiveTarget(PN532_MIFARE_ISO14443A);<br />
}<br />
<br />
void loop() { <br />
uint8_t i = 0;<br />
float samplestotal = 0.0;<br />
<br />
for(i = 0; i < SAMPLES_PER_READING; i++) {<br />
samplestotal += analogRead(7);<br />
}<br />
<br />
float sigstrength = samplestotal / SAMPLES_PER_READING; <br />
<br />
float object_temp = readObjTempC(tempID);<br />
Serial.print(object_temp); <br />
Serial.print(";");<br />
Serial.println(sigstrength);<br />
}<br />
</nowiki><br />
<br />
====Extra functie NFC library====<br />
Deze functie zorgt ervoor dat de RFID antenne permanent aan het meten is, waardoor wij vervolgens de mogelijkheid hebben (gebruikmakende van de kabel die we vanaf het RFID shield naar Analog in 7 hebben geleid) om de signaalsterkte direct af te lezen.<br />
<nowiki><br />
/* In header file */<br />
boolean listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout = 0);<br />
<br />
/* In CPP file */<br />
boolean Adafruit_NFCShield_I2C::listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout) {<br />
pn532_packetbuffer[0] = PN532_COMMAND_INLISTPASSIVETARGET;<br />
pn532_packetbuffer[1] = 1; // max 2 cards at once (untested)<br />
pn532_packetbuffer[2] = cardbaudrate;<br />
<br />
if (! sendCommandCheckAck(pn532_packetbuffer, 3, timeout))<br />
{<br />
#ifdef PN532DEBUG<br />
Serial.println(F("No card(s) read"));<br />
#endif<br />
return 0; // no cards read<br />
}<br />
<br />
return 1;<br />
}<br />
</nowiki><br />
<br />
====MATlab code====<br />
<br />
Deze functie werd gebruikt voor het meten van <samples> samples in één cel in het raster (Werd dus voor iedere cel aangeroepen)<br />
<nowiki><br />
function [ RFIDvals, tempvals ] = readRFIDTemp( samples )<br />
%READRFIDTEMP Summary of this function goes here<br />
% Detailed explanation goes here<br />
s = serial('COM3', 'BaudRate', 115200);<br />
RFIDvals = zeros(1, samples);<br />
tempvals = zeros(1, samples);<br />
<br />
try<br />
fopen(s);<br />
index = 1;<br />
while index <= samples<br />
[out, count] = fscanf(s, '%c');<br />
if count == 14<br />
%disp(out);<br />
st = strsplit(out, ';');<br />
%disp(st);<br />
if numel(st) == 2<br />
tempvals(index) = str2num(st{1});<br />
RFIDvals(index) = str2num(st{2});<br />
index = index + 1;<br />
end<br />
end<br />
end<br />
catch err<br />
disp('Error while running script');<br />
disp(err);<br />
end<br />
fclose(s);<br />
delete(s);<br />
clear s;<br />
end<br />
</nowiki><br />
<br />
Deze functie werd gebruikt voor tests van de sensoren, het weergeeft een live plot van de gemeten waarden.<br />
<nowiki><br />
function [] = readAndPlotValues( samples )<br />
%UNTITLED Summary of this function goes here<br />
% Detailed explanation goes here<br />
<br />
i = 1;<br />
figure(1); <br />
lHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
figure(2);<br />
llHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
while 1 == 1<br />
[rfid, tmp] = readRFIDTemp(samples);<br />
rfidMean = mean(rfid);<br />
tmpMean = mean(tmp);<br />
<br />
Y = get(lHandle, 'YData');<br />
Y = [Y rfidMean];<br />
X = get(lHandle, 'XData');<br />
X = [X i];<br />
<br />
set(lHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
<br />
Y = get(llHandle, 'YData');<br />
Y = [Y tmpMean];<br />
X = get(llHandle, 'XData');<br />
X = [X i];<br />
<br />
set(llHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
i = i + 1;<br />
end<br />
<br />
end<br />
</nowiki><br />
<br />
===Bronnen===<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van het gemiddelde daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster.<br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR'''' Voor de corrigeerden IR data in procentpunten<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
end <br />
<br />
'''RIFBAR''' Voor de RFID data in procentpunten<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
end<br />
<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
[[File:both.png|thumb|right|Figuur x: Vergelijking van 30 samples en 500 samples (meting 1)]]<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na 30 samples al heel erg vergelijkbaar als bij 500 samples, zoals zichtbaar in figuur x. De pieken verschillen op sommige plekken, maar in groten lijnen blijven de RFID-plekken duidelijk zichtbaar. <br />
In het geval van de temperatuursensor, was 1 sample zelfs al genoeg.<br />
<br />
Vanuit de Arduino kwamen er elke 10ms een sample. In dit geval zou er dus in 300ms genoeg data verzameld kunnen worden voor een hokje van 9 bij 8.5 mm. In dit geval zou de robot per m^2 3921.56862744 seconde nodig hebben, oftewel een iets meer dan een uur en 5 min. Om ervoor te zorgen dat binnen 5 min toch zeker een gebied ter grootte van een paar duizend vierkante meter, zullen de hokjes van 0.0000765 m^2 naar 5m^2 moeten gaan.<br />
<br />
Een andere mogelijkheid is meer samples binnen te krijgen. Deze is zeker mogelijk, al is hier een krachtigere processor voor nodig, meer samples per seconde kan de Arduino niet verwerken.<br />
<br />
=Conclusies=<br />
==Discussie betrouwbaarheid==<br />
Door de data te verwerken en daarna te vergelijken met de bekende werelden kunnen er conclusies over de betrouwbaarheid getrokken worden.<br />
[[File:RIFD-500m1.png|right|thumb|300px|Figuur 1: RFID-signaalverschil in mV boven zwakste signaal]]<br />
===RFID signaal=== <br />
1. Het RFID signaal had een zwakke reactie, de verschillen tussen het hoogste signaal (hokje met een RFID-tag) en het laagste was maximaal 1,6169 mV.<br />
<br />
2. Het RFID signaal gaf in het hokje met een RFID signaal een heel duidelijk signaal, het signaal in de hokjes eromheen (ong. 8cm afstand) gaf in de meeste gevallen een lager (maar zichtbaar) verschil. <br />
<br />
3. Sommige hokjes kregen een heel onverwacht hoge of lage waarde, dit kan te wijden zijn aan:<br />
:a. Meetfouten.<br />
:b. Meerdere RFID-signalen van verschillende tags die met elkaar interfereren.<br />
::Radiogolven met dezelfde frequentie elkaar in tegen-fase kunnen uitdoven, kunnen golven in fase elkaar juist versterken.<br />
<br />
===Hitte signaal===<br />
- Het hitte signaal was betrouwbaar, maar ook op een afstand tot maximaal 16cm.<br />
<br />
<br />
==Conclusie Experiment en discussie uitbreiding==<br />
Ondanks de problemen en onverwacht zwakke RFID sensor hebben we toch nuttige conclusies kunnen trekken dankzij het experiment. <br />
Zoals de grafieken die gegenereerd zijn op basis van de meetresultaten van ons experiment laten zien is het aardig mogelijk om te bepalen op welke locaties er mensen zijn, gegeven dat deze een lichaamstemperatuur hebben die boven de omgevingstemperatuur zit, en ze een RFID tag bij zich hebben.<br />
<br />
Kijkende naar de meetresultaten van ons experiment doet zich al snel de vraag voor hoe men op grotere afstanden RFID tags kan lezen. Dit hangt o.a. af van de frequentie, de grootte van de antenne, de grootte van de tag, en de sterkte van de stroom die door de antenne loopt. Bij ons experiment hebben we gebruik gemaakt van een RFID antenne en tags die werken op 13.56Mhz. Dit geeft een theoretische maximale leesafstand van 1.5 meter[1]. Onze antenne bleek hier helaas niet sterk genoeg voor. Dit is echter goed te verhelpen door gebruiken te maken van de (inmiddels zeer populaire)EPC Gen2 RFID tags[2]. Deze opereren op hogere frequenties, en maken bovendien niet meer gebruik van Near Field Communication (dit is datatransmissie op basis van het elektromagnetisch veld van de antenne, wij gebruikten dit in ons experiment) maar gebruiken radar technieken. hierdoor wordt de leesafstand dramatisch vergroot. Chris Paget stelt zelfs dat in theorie een leesafstand van meer dan 1.5km bereikt kan worden (alhoewel dit waarschijnlijk niet een mobiele installatie zou zijn).<br />
<br />
Het lezen van de temperatuur ging prima op kleine schaal. Onze verwachting is dat het geen probleem is om gelijkwaardige al-dan-niet betere warmte sensoren te vinden voor afstanden tot 10 meter, bijvoorbeeld gebruikmakende van dezelfde technieken als een warmte camera of een warmte meetapparaat zoals de Extech VIR50 [3].<br />
<br />
<br />
===Bronnen===<br />
* [1] RFID Tag Maximum Read Distance - http://skyrfid.com/RFID_Tag_Read_Ranges.php<br />
* [2] Extreme-range RFID tracking, Chris Paget, presented at Blackhat USA 2010 - http://www.tombom.co.uk/extreme_rfid.pdf<br />
* [3] Extech VIR50 - http://www.extech.com/instruments/product.asp?catid=62&prodid=653<br />
<br />
==Verdere discussie==<br />
De grootte van het raster hebben wij in het experiment zo gekozen dat de Arduino goed in een hokje past. Dit uit comfort overwegingen tijdens het meten.<br />
Deze grootte hoeft echter niet vast te staan; We zouden de grootte kunnen proberen te bepalen naar de hand van enkele variabelen die per situatie anders kunnen zijn, bijvoorbeeld breedte/lengte van de ruimte waarin de robot gebruikt gaat worden. Ook kan de grootte samenhangen met het pathfinding algorithme; Stel dat de robot begint met zoeken in hele grote hokjes, en als in een van de grote hokjes een afwijkend signaal gedetecteerd wordt verandert de robot de grootte van de hokjes waarin hij gaat scannen en scant vervolgens nog een keer het grote hokje door om een preciezere locatie te kunnen bepalen.<br />
Op de vraag of er een optimale grote is voor de hokjes van het raster is dus niet een kort en eenvoudig antwoord te geven. Hiervoor zal apart onderzoek gedaan moeten worden.<br />
<br />
[[PRE2_Groep2|Terug naar hoofdpagina]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17524PRE2Groep2 Experiment2015-01-16T02:42:11Z<p>S127922: /* Tijdsduur */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het experiment. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
==Arduino==<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC op de PN532 deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op een analoge input pin van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar MATLAB op een van onze computers. in MATLAB worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
===Pin allocatie===<br />
De pins van de Arduino zijn als volgt in gebruik:<br />
* SCA : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* SCL : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* Aref : PN532 RFID Shield<br />
* Digital I/O 0-13 : PN532 RFID Shield<br />
* IOREF: PN532 RFID Shield<br />
* RESET: PN532 RFID Shield<br />
* 3V: PN532 RFID Shield<br />
* Vin: PN532 RFID Shield<br />
* Analog in 0-5: PN532 RFID Shield<br />
* Analog in 7: PN532 RFID Shield Antenne<br />
<br />
Verder zijn zowel de thermopile als het RFID shield gekoppeld aan 5V en gnd op verschillende plaatsen. Deze pins zijn voor de PN532 tussen de Digital I/O en SCA, en tussen Vin en 3V.<br />
Voor de thermopile zijn deze onderaan het board, ground links en 5V rechts.<br />
[[File:ArduinoPinouts.png|right|thumb|350px|Overzicht Arduino pinouts]]<br />
<br />
===Broncode===<br />
De broncode om de signalen naar MATLAB te lezen bestaat uit 4 onderdelen:<br />
* De TMP006 library om temperatuur in te lezen[2]<br />
* De NFC Library om het RFID shield te gebruiken[4], met enkele aanpassingen<br />
* Het Arduino programma dat de samples verzamelt en naar de computer stuurt<br />
* Het MATlab script dat deze samples opvangt en in matrices stopt<br />
<br />
Voor de code van de gebruikte libraries, zie de GitHub links in de bronnenlijst.<br />
<br />
====Arduino Programma====<br />
<nowiki><br />
#include <Wire.h><br />
#include <Adafruit_NFCShield_I2C.h><br />
#include <math.h><br />
#include <stdint.h> <br />
#include "I2C_16.h"<br />
#include "TMP006.h"<br />
<br />
#define IRQ (2)<br />
#define RESET (3) // Not connected by default on the NFC Shield<br />
#define SAMPLES_PER_READING (10) // 1 - 255<br />
uint8_t tempID = 0x40; // I2C address of TMP006, can be 0x40-0x47 (would have to wire the address pins)<br />
uint16_t samples = TMP006_CFG_1SAMPLE; // # of samples per reading, can be 1/2/4/8/16<br />
<br />
Adafruit_NFCShield_I2C nfc(IRQ, RESET);<br />
<br />
void setup(void) {<br />
Serial.begin(115200);<br />
<br />
//init PN53x<br />
nfc.begin();<br />
<br />
//init tmp006<br />
config_TMP006(tempID, samples);<br />
<br />
uint32_t versiondata = nfc.getFirmwareVersion();<br />
if (! versiondata) {<br />
Serial.print("Didn't find PN53x board");<br />
while (1); // halt<br />
}<br />
<br />
// Got ok data, print it out!<br />
Serial.print("Found chip PN5"); <br />
Serial.println((versiondata>>24) & 0xFF, HEX); <br />
Serial.print("Firmware ver. "); <br />
Serial.print((versiondata>>16) & 0xFF, DEC); <br />
Serial.print('.'); <br />
Serial.println((versiondata>>8) & 0xFF, DEC);<br />
<br />
// 0xFF = forever<br />
nfc.setPassiveActivationRetries(0xFF);<br />
<br />
// configure board to read RFID tags<br />
nfc.SAMConfig();<br />
<br />
Serial.println("Listening for an ISO14443A card");<br />
nfc.listenPassiveTarget(PN532_MIFARE_ISO14443A);<br />
}<br />
<br />
void loop() { <br />
uint8_t i = 0;<br />
float samplestotal = 0.0;<br />
<br />
for(i = 0; i < SAMPLES_PER_READING; i++) {<br />
samplestotal += analogRead(7);<br />
}<br />
<br />
float sigstrength = samplestotal / SAMPLES_PER_READING; <br />
<br />
float object_temp = readObjTempC(tempID);<br />
Serial.print(object_temp); <br />
Serial.print(";");<br />
Serial.println(sigstrength);<br />
}<br />
</nowiki><br />
<br />
====Extra functie NFC library====<br />
Deze functie zorgt ervoor dat de RFID antenne permanent aan het meten is, waardoor wij vervolgens de mogelijkheid hebben (gebruikmakende van de kabel die we vanaf het RFID shield naar Analog in 7 hebben geleid) om de signaalsterkte direct af te lezen.<br />
<nowiki><br />
/* In header file */<br />
boolean listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout = 0);<br />
<br />
/* In CPP file */<br />
boolean Adafruit_NFCShield_I2C::listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout) {<br />
pn532_packetbuffer[0] = PN532_COMMAND_INLISTPASSIVETARGET;<br />
pn532_packetbuffer[1] = 1; // max 2 cards at once (untested)<br />
pn532_packetbuffer[2] = cardbaudrate;<br />
<br />
if (! sendCommandCheckAck(pn532_packetbuffer, 3, timeout))<br />
{<br />
#ifdef PN532DEBUG<br />
Serial.println(F("No card(s) read"));<br />
#endif<br />
return 0; // no cards read<br />
}<br />
<br />
return 1;<br />
}<br />
</nowiki><br />
<br />
====MATlab code====<br />
<br />
Deze functie werd gebruikt voor het meten van <samples> samples in één cel in het raster (Werd dus voor iedere cel aangeroepen)<br />
<nowiki><br />
function [ RFIDvals, tempvals ] = readRFIDTemp( samples )<br />
%READRFIDTEMP Summary of this function goes here<br />
% Detailed explanation goes here<br />
s = serial('COM3', 'BaudRate', 115200);<br />
RFIDvals = zeros(1, samples);<br />
tempvals = zeros(1, samples);<br />
<br />
try<br />
fopen(s);<br />
index = 1;<br />
while index <= samples<br />
[out, count] = fscanf(s, '%c');<br />
if count == 14<br />
%disp(out);<br />
st = strsplit(out, ';');<br />
%disp(st);<br />
if numel(st) == 2<br />
tempvals(index) = str2num(st{1});<br />
RFIDvals(index) = str2num(st{2});<br />
index = index + 1;<br />
end<br />
end<br />
end<br />
catch err<br />
disp('Error while running script');<br />
disp(err);<br />
end<br />
fclose(s);<br />
delete(s);<br />
clear s;<br />
end<br />
</nowiki><br />
<br />
Deze functie werd gebruikt voor tests van de sensoren, het weergeeft een live plot van de gemeten waarden.<br />
<nowiki><br />
function [] = readAndPlotValues( samples )<br />
%UNTITLED Summary of this function goes here<br />
% Detailed explanation goes here<br />
<br />
i = 1;<br />
figure(1); <br />
lHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
figure(2);<br />
llHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
while 1 == 1<br />
[rfid, tmp] = readRFIDTemp(samples);<br />
rfidMean = mean(rfid);<br />
tmpMean = mean(tmp);<br />
<br />
Y = get(lHandle, 'YData');<br />
Y = [Y rfidMean];<br />
X = get(lHandle, 'XData');<br />
X = [X i];<br />
<br />
set(lHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
<br />
Y = get(llHandle, 'YData');<br />
Y = [Y tmpMean];<br />
X = get(llHandle, 'XData');<br />
X = [X i];<br />
<br />
set(llHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
i = i + 1;<br />
end<br />
<br />
end<br />
</nowiki><br />
<br />
===Bronnen===<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van het gemiddelde daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster.<br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR'''' Voor de corrigeerden IR data in procentpunten<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
end <br />
<br />
'''RIFBAR''' Voor de RFID data in procentpunten<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
end<br />
<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
[File:both.png|thumb|right|Figuur x: Vergelijking van 30 samples en 500 samples (meting 1)]]<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na 30 samples al heel erg vergelijkbaar als bij 500 samples, zoals zichtbaar in figuur x. De pieken verschillen op sommige plekken, maar in groten lijnen blijven de RFID-plekken duidelijk zichtbaar. <br />
In het geval van de temperatuursensor, was 1 sample zelfs al genoeg.<br />
<br />
Vanuit de Arduino kwamen er elke 10ms een sample. In dit geval zou er dus in 300ms genoeg data verzameld kunnen worden voor een hokje van 9 bij 8.5 mm. In dit geval zou de robot per m^2 3921.56862744 seconde nodig hebben, oftewel een iets meer dan een uur en 5 min. Om ervoor te zorgen dat binnen 5 min toch zeker een gebied ter grootte van een paar duizend vierkante meter, zullen de hokjes van 0.0000765 m^2 naar 5m^2 moeten gaan.<br />
<br />
Een andere mogelijkheid is meer samples binnen te krijgen. Deze is zeker mogelijk, al is hier een krachtigere processor voor nodig, meer samples per seconde kan de Arduino niet verwerken.<br />
<br />
=Conclusies=<br />
==Discussie betrouwbaarheid==<br />
Door de data te verwerken en daarna te vergelijken met de bekende werelden kunnen er conclusies over de betrouwbaarheid getrokken worden.<br />
[[File:RIFD-500m1.png|right|thumb|300px|Figuur 1: RFID-signaalverschil in mV boven zwakste signaal]]<br />
===RFID signaal=== <br />
1. Het RFID signaal had een zwakke reactie, de verschillen tussen het hoogste signaal (hokje met een RFID-tag) en het laagste was maximaal 1,6169 mV.<br />
<br />
2. Het RFID signaal gaf in het hokje met een RFID signaal een heel duidelijk signaal, het signaal in de hokjes eromheen (ong. 8cm afstand) gaf in de meeste gevallen een lager (maar zichtbaar) verschil. <br />
<br />
3. Sommige hokjes kregen een heel onverwacht hoge of lage waarde, dit kan te wijden zijn aan:<br />
:a. Meetfouten.<br />
:b. Meerdere RFID-signalen van verschillende tags die met elkaar interfereren.<br />
::Radiogolven met dezelfde frequentie elkaar in tegen-fase kunnen uitdoven, kunnen golven in fase elkaar juist versterken.<br />
<br />
===Hitte signaal===<br />
- Het hitte signaal was betrouwbaar, maar ook op een afstand tot maximaal 16cm.<br />
<br />
<br />
==Conclusie Experiment en discussie uitbreiding==<br />
Ondanks de problemen en onverwacht zwakke RFID sensor hebben we toch nuttige conclusies kunnen trekken dankzij het experiment. <br />
Zoals de grafieken die gegenereerd zijn op basis van de meetresultaten van ons experiment laten zien is het aardig mogelijk om te bepalen op welke locaties er mensen zijn, gegeven dat deze een lichaamstemperatuur hebben die boven de omgevingstemperatuur zit, en ze een RFID tag bij zich hebben.<br />
<br />
Kijkende naar de meetresultaten van ons experiment doet zich al snel de vraag voor hoe men op grotere afstanden RFID tags kan lezen. Dit hangt o.a. af van de frequentie, de grootte van de antenne, de grootte van de tag, en de sterkte van de stroom die door de antenne loopt. Bij ons experiment hebben we gebruik gemaakt van een RFID antenne en tags die werken op 13.56Mhz. Dit geeft een theoretische maximale leesafstand van 1.5 meter[1]. Onze antenne bleek hier helaas niet sterk genoeg voor. Dit is echter goed te verhelpen door gebruiken te maken van de (inmiddels zeer populaire)EPC Gen2 RFID tags[2]. Deze opereren op hogere frequenties, en maken bovendien niet meer gebruik van Near Field Communication (dit is datatransmissie op basis van het elektromagnetisch veld van de antenne, wij gebruikten dit in ons experiment) maar gebruiken radar technieken. hierdoor wordt de leesafstand dramatisch vergroot. Chris Paget stelt zelfs dat in theorie een leesafstand van meer dan 1.5km bereikt kan worden (alhoewel dit waarschijnlijk niet een mobiele installatie zou zijn).<br />
<br />
Het lezen van de temperatuur ging prima op kleine schaal. Onze verwachting is dat het geen probleem is om gelijkwaardige al-dan-niet betere warmte sensoren te vinden voor afstanden tot 10 meter, bijvoorbeeld gebruikmakende van dezelfde technieken als een warmte camera of een warmte meetapparaat zoals de Extech VIR50 [3].<br />
<br />
<br />
===Bronnen===<br />
* [1] RFID Tag Maximum Read Distance - http://skyrfid.com/RFID_Tag_Read_Ranges.php<br />
* [2] Extreme-range RFID tracking, Chris Paget, presented at Blackhat USA 2010 - http://www.tombom.co.uk/extreme_rfid.pdf<br />
* [3] Extech VIR50 - http://www.extech.com/instruments/product.asp?catid=62&prodid=653<br />
<br />
==Verdere discussie==<br />
De grootte van het raster hebben wij in het experiment zo gekozen dat de Arduino goed in een hokje past. Dit uit comfort overwegingen tijdens het meten.<br />
Deze grootte hoeft echter niet vast te staan; We zouden de grootte kunnen proberen te bepalen naar de hand van enkele variabelen die per situatie anders kunnen zijn, bijvoorbeeld breedte/lengte van de ruimte waarin de robot gebruikt gaat worden. Ook kan de grootte samenhangen met het pathfinding algorithme; Stel dat de robot begint met zoeken in hele grote hokjes, en als in een van de grote hokjes een afwijkend signaal gedetecteerd wordt verandert de robot de grootte van de hokjes waarin hij gaat scannen en scant vervolgens nog een keer het grote hokje door om een preciezere locatie te kunnen bepalen.<br />
Op de vraag of er een optimale grote is voor de hokjes van het raster is dus niet een kort en eenvoudig antwoord te geven. Hiervoor zal apart onderzoek gedaan moeten worden.<br />
<br />
[[PRE2_Groep2|Terug naar hoofdpagina]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17523PRE2Groep2 Experiment2015-01-16T02:40:11Z<p>S127922: /* Tijdsduur */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het experiment. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
==Arduino==<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC op de PN532 deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op een analoge input pin van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar MATLAB op een van onze computers. in MATLAB worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
===Pin allocatie===<br />
De pins van de Arduino zijn als volgt in gebruik:<br />
* SCA : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* SCL : Zowel het PN532 RFID Shield als de TMP006 Thermopile<br />
* Aref : PN532 RFID Shield<br />
* Digital I/O 0-13 : PN532 RFID Shield<br />
* IOREF: PN532 RFID Shield<br />
* RESET: PN532 RFID Shield<br />
* 3V: PN532 RFID Shield<br />
* Vin: PN532 RFID Shield<br />
* Analog in 0-5: PN532 RFID Shield<br />
* Analog in 7: PN532 RFID Shield Antenne<br />
<br />
Verder zijn zowel de thermopile als het RFID shield gekoppeld aan 5V en gnd op verschillende plaatsen. Deze pins zijn voor de PN532 tussen de Digital I/O en SCA, en tussen Vin en 3V.<br />
Voor de thermopile zijn deze onderaan het board, ground links en 5V rechts.<br />
[[File:ArduinoPinouts.png|right|thumb|350px|Overzicht Arduino pinouts]]<br />
<br />
===Broncode===<br />
De broncode om de signalen naar MATLAB te lezen bestaat uit 4 onderdelen:<br />
* De TMP006 library om temperatuur in te lezen[2]<br />
* De NFC Library om het RFID shield te gebruiken[4], met enkele aanpassingen<br />
* Het Arduino programma dat de samples verzamelt en naar de computer stuurt<br />
* Het MATlab script dat deze samples opvangt en in matrices stopt<br />
<br />
Voor de code van de gebruikte libraries, zie de GitHub links in de bronnenlijst.<br />
<br />
====Arduino Programma====<br />
<nowiki><br />
#include <Wire.h><br />
#include <Adafruit_NFCShield_I2C.h><br />
#include <math.h><br />
#include <stdint.h> <br />
#include "I2C_16.h"<br />
#include "TMP006.h"<br />
<br />
#define IRQ (2)<br />
#define RESET (3) // Not connected by default on the NFC Shield<br />
#define SAMPLES_PER_READING (10) // 1 - 255<br />
uint8_t tempID = 0x40; // I2C address of TMP006, can be 0x40-0x47 (would have to wire the address pins)<br />
uint16_t samples = TMP006_CFG_1SAMPLE; // # of samples per reading, can be 1/2/4/8/16<br />
<br />
Adafruit_NFCShield_I2C nfc(IRQ, RESET);<br />
<br />
void setup(void) {<br />
Serial.begin(115200);<br />
<br />
//init PN53x<br />
nfc.begin();<br />
<br />
//init tmp006<br />
config_TMP006(tempID, samples);<br />
<br />
uint32_t versiondata = nfc.getFirmwareVersion();<br />
if (! versiondata) {<br />
Serial.print("Didn't find PN53x board");<br />
while (1); // halt<br />
}<br />
<br />
// Got ok data, print it out!<br />
Serial.print("Found chip PN5"); <br />
Serial.println((versiondata>>24) & 0xFF, HEX); <br />
Serial.print("Firmware ver. "); <br />
Serial.print((versiondata>>16) & 0xFF, DEC); <br />
Serial.print('.'); <br />
Serial.println((versiondata>>8) & 0xFF, DEC);<br />
<br />
// 0xFF = forever<br />
nfc.setPassiveActivationRetries(0xFF);<br />
<br />
// configure board to read RFID tags<br />
nfc.SAMConfig();<br />
<br />
Serial.println("Listening for an ISO14443A card");<br />
nfc.listenPassiveTarget(PN532_MIFARE_ISO14443A);<br />
}<br />
<br />
void loop() { <br />
uint8_t i = 0;<br />
float samplestotal = 0.0;<br />
<br />
for(i = 0; i < SAMPLES_PER_READING; i++) {<br />
samplestotal += analogRead(7);<br />
}<br />
<br />
float sigstrength = samplestotal / SAMPLES_PER_READING; <br />
<br />
float object_temp = readObjTempC(tempID);<br />
Serial.print(object_temp); <br />
Serial.print(";");<br />
Serial.println(sigstrength);<br />
}<br />
</nowiki><br />
<br />
====Extra functie NFC library====<br />
Deze functie zorgt ervoor dat de RFID antenne permanent aan het meten is, waardoor wij vervolgens de mogelijkheid hebben (gebruikmakende van de kabel die we vanaf het RFID shield naar Analog in 7 hebben geleid) om de signaalsterkte direct af te lezen.<br />
<nowiki><br />
/* In header file */<br />
boolean listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout = 0);<br />
<br />
/* In CPP file */<br />
boolean Adafruit_NFCShield_I2C::listenPassiveTarget(uint8_t cardbaudrate, uint16_t timeout) {<br />
pn532_packetbuffer[0] = PN532_COMMAND_INLISTPASSIVETARGET;<br />
pn532_packetbuffer[1] = 1; // max 2 cards at once (untested)<br />
pn532_packetbuffer[2] = cardbaudrate;<br />
<br />
if (! sendCommandCheckAck(pn532_packetbuffer, 3, timeout))<br />
{<br />
#ifdef PN532DEBUG<br />
Serial.println(F("No card(s) read"));<br />
#endif<br />
return 0; // no cards read<br />
}<br />
<br />
return 1;<br />
}<br />
</nowiki><br />
<br />
====MATlab code====<br />
<br />
Deze functie werd gebruikt voor het meten van <samples> samples in één cel in het raster (Werd dus voor iedere cel aangeroepen)<br />
<nowiki><br />
function [ RFIDvals, tempvals ] = readRFIDTemp( samples )<br />
%READRFIDTEMP Summary of this function goes here<br />
% Detailed explanation goes here<br />
s = serial('COM3', 'BaudRate', 115200);<br />
RFIDvals = zeros(1, samples);<br />
tempvals = zeros(1, samples);<br />
<br />
try<br />
fopen(s);<br />
index = 1;<br />
while index <= samples<br />
[out, count] = fscanf(s, '%c');<br />
if count == 14<br />
%disp(out);<br />
st = strsplit(out, ';');<br />
%disp(st);<br />
if numel(st) == 2<br />
tempvals(index) = str2num(st{1});<br />
RFIDvals(index) = str2num(st{2});<br />
index = index + 1;<br />
end<br />
end<br />
end<br />
catch err<br />
disp('Error while running script');<br />
disp(err);<br />
end<br />
fclose(s);<br />
delete(s);<br />
clear s;<br />
end<br />
</nowiki><br />
<br />
Deze functie werd gebruikt voor tests van de sensoren, het weergeeft een live plot van de gemeten waarden.<br />
<nowiki><br />
function [] = readAndPlotValues( samples )<br />
%UNTITLED Summary of this function goes here<br />
% Detailed explanation goes here<br />
<br />
i = 1;<br />
figure(1); <br />
lHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
figure(2);<br />
llHandle = line(nan, nan); %# Generate a blank line and return the line handle<br />
while 1 == 1<br />
[rfid, tmp] = readRFIDTemp(samples);<br />
rfidMean = mean(rfid);<br />
tmpMean = mean(tmp);<br />
<br />
Y = get(lHandle, 'YData');<br />
Y = [Y rfidMean];<br />
X = get(lHandle, 'XData');<br />
X = [X i];<br />
<br />
set(lHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
<br />
Y = get(llHandle, 'YData');<br />
Y = [Y tmpMean];<br />
X = get(llHandle, 'XData');<br />
X = [X i];<br />
<br />
set(llHandle, 'XData', X, 'YData', Y);<br />
drawnow();<br />
i = i + 1;<br />
end<br />
<br />
end<br />
</nowiki><br />
<br />
===Bronnen===<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van het gemiddelde daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster.<br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR'''' Voor de corrigeerden IR data in procentpunten<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
end <br />
<br />
'''RIFBAR''' Voor de RFID data in procentpunten<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
end<br />
<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
[File:both.png|thumb|right|Figuur x: Vergelijking van 30 samples en 500 samples (meting 1)]<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na 30 samples al heel erg vergelijkbaar als bij 500 samples, zoals zichtbaar in figuur x. De pieken verschillen op sommige plekken, maar in groten lijnen blijven de RFID-plekken duidelijk zichtbaar. <br />
In het geval van de temperatuursensor, was 1 sample zelfs al genoeg.<br />
<br />
Vanuit de Arduino kwamen er elke 10ms een sample. In dit geval zou er dus in 300ms genoeg data verzameld kunnen worden voor een hokje van 9 bij 8.5 mm. In dit geval zou de robot per m^2 3921.56862744 seconde nodig hebben, oftewel een iets meer dan een uur en 5 min. Om ervoor te zorgen dat binnen 5 min toch zeker een gebied ter grootte van een paar duizend vierkante meter, zullen de hokjes van 0.0000765 m^2 naar 5m^2 moeten gaan.<br />
<br />
Een andere mogelijkheid is meer samples binnen te krijgen. Deze is zeker mogelijk, al is hier een krachtigere processor voor nodig, meer samples per seconde kan de Arduino niet verwerken.<br />
<br />
=Conclusies=<br />
==Discussie betrouwbaarheid==<br />
Door de data te verwerken en daarna te vergelijken met de bekende werelden kunnen er conclusies over de betrouwbaarheid getrokken worden.<br />
[[File:RIFD-500m1.png|right|thumb|300px|Figuur 1: RFID-signaalverschil in mV boven zwakste signaal]]<br />
===RFID signaal=== <br />
1. Het RFID signaal had een zwakke reactie, de verschillen tussen het hoogste signaal (hokje met een RFID-tag) en het laagste was maximaal 1,6169 mV.<br />
<br />
2. Het RFID signaal gaf in het hokje met een RFID signaal een heel duidelijk signaal, het signaal in de hokjes eromheen (ong. 8cm afstand) gaf in de meeste gevallen een lager (maar zichtbaar) verschil. <br />
<br />
3. Sommige hokjes kregen een heel onverwacht hoge of lage waarde, dit kan te wijden zijn aan:<br />
:a. Meetfouten.<br />
:b. Meerdere RFID-signalen van verschillende tags die met elkaar interfereren.<br />
::Radiogolven met dezelfde frequentie elkaar in tegen-fase kunnen uitdoven, kunnen golven in fase elkaar juist versterken.<br />
<br />
===Hitte signaal===<br />
- Het hitte signaal was betrouwbaar, maar ook op een afstand tot maximaal 16cm.<br />
<br />
<br />
==Conclusie Experiment en discussie uitbreiding==<br />
Ondanks de problemen en onverwacht zwakke RFID sensor hebben we toch nuttige conclusies kunnen trekken dankzij het experiment. <br />
Zoals de grafieken die gegenereerd zijn op basis van de meetresultaten van ons experiment laten zien is het aardig mogelijk om te bepalen op welke locaties er mensen zijn, gegeven dat deze een lichaamstemperatuur hebben die boven de omgevingstemperatuur zit, en ze een RFID tag bij zich hebben.<br />
<br />
Kijkende naar de meetresultaten van ons experiment doet zich al snel de vraag voor hoe men op grotere afstanden RFID tags kan lezen. Dit hangt o.a. af van de frequentie, de grootte van de antenne, de grootte van de tag, en de sterkte van de stroom die door de antenne loopt. Bij ons experiment hebben we gebruik gemaakt van een RFID antenne en tags die werken op 13.56Mhz. Dit geeft een theoretische maximale leesafstand van 1.5 meter[1]. Onze antenne bleek hier helaas niet sterk genoeg voor. Dit is echter goed te verhelpen door gebruiken te maken van de (inmiddels zeer populaire)EPC Gen2 RFID tags[2]. Deze opereren op hogere frequenties, en maken bovendien niet meer gebruik van Near Field Communication (dit is datatransmissie op basis van het elektromagnetisch veld van de antenne, wij gebruikten dit in ons experiment) maar gebruiken radar technieken. hierdoor wordt de leesafstand dramatisch vergroot. Chris Paget stelt zelfs dat in theorie een leesafstand van meer dan 1.5km bereikt kan worden (alhoewel dit waarschijnlijk niet een mobiele installatie zou zijn).<br />
<br />
Het lezen van de temperatuur ging prima op kleine schaal. Onze verwachting is dat het geen probleem is om gelijkwaardige al-dan-niet betere warmte sensoren te vinden voor afstanden tot 10 meter, bijvoorbeeld gebruikmakende van dezelfde technieken als een warmte camera of een warmte meetapparaat zoals de Extech VIR50 [3].<br />
<br />
<br />
===Bronnen===<br />
* [1] RFID Tag Maximum Read Distance - http://skyrfid.com/RFID_Tag_Read_Ranges.php<br />
* [2] Extreme-range RFID tracking, Chris Paget, presented at Blackhat USA 2010 - http://www.tombom.co.uk/extreme_rfid.pdf<br />
* [3] Extech VIR50 - http://www.extech.com/instruments/product.asp?catid=62&prodid=653<br />
<br />
==Verdere discussie==<br />
De grootte van het raster hebben wij in het experiment zo gekozen dat de Arduino goed in een hokje past. Dit uit comfort overwegingen tijdens het meten.<br />
Deze grootte hoeft echter niet vast te staan; We zouden de grootte kunnen proberen te bepalen naar de hand van enkele variabelen die per situatie anders kunnen zijn, bijvoorbeeld breedte/lengte van de ruimte waarin de robot gebruikt gaat worden. Ook kan de grootte samenhangen met het pathfinding algorithme; Stel dat de robot begint met zoeken in hele grote hokjes, en als in een van de grote hokjes een afwijkend signaal gedetecteerd wordt verandert de robot de grootte van de hokjes waarin hij gaat scannen en scant vervolgens nog een keer het grote hokje door om een preciezere locatie te kunnen bepalen.<br />
Op de vraag of er een optimale grote is voor de hokjes van het raster is dus niet een kort en eenvoudig antwoord te geven. Hiervoor zal apart onderzoek gedaan moeten worden.<br />
<br />
[[PRE2_Groep2|Terug naar hoofdpagina]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17286PRE2Groep2 Protocol2015-01-12T10:36:21Z<p>S127922: /* Protocol“Gevaarlijke ‘Search and Rescue’ operaties met robots” */</p>
<hr />
<div>='''Protocol “Gevaarlijke ‘Search and Rescue’ operaties met robots”'''=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. [1] Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
* Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
* Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
* De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
* Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
* Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
* Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk "Gebruik van de terminals"). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===<br />
Hulpverleners gaan met gebruik van de zo geheten terminals op zoek naar mensen in het rampgebied, doordat de robot de nodige data heeft verzameld kan er een duidelijke verdeling van prioriteit gesteld worden. Hierdoor worden gebieden met hogere kansen eerder onderzocht dan gebieden zonder waardes. De hulpverleners zullen volgens het hoofdstuk "Gebruik van de Terminals" handelen, om levenden slachtoffers zo snel mogelijk te redden. Gevonden slachtoffers zullen z.s.m. het gebied verlaten en zal waar mogelijk direct naar een zorginstelling vervoerd worden.<br />
<br />
===6. Zorginstellingen ===<br />
Binnengebrachte slachtoffers zullen worden onderzocht en nazorg zal worden gegeven volgens de standaard medische protocollen. Binnen het dossier zal de ramp gemeld worden zodat dit later herleidbaar zal zijn.<br />
<br />
<br />
==Gebruik van de Terminals==<br />
[[File:Terminal.png|right|thumb|Figuur 1: Terminal-dislay]]<br />
De terminals zullen de omgeving aangeven in een hoeveelheid hokjes. De werkelijke grootte ligt aan het vooraf ingestelde gebied. In figuur 1, is een voorbeeld te zien van een dergelijke terminal. Hierbij is op te merken dat hoe roder het hokje hoe groter de kans dat hier een mens ligt. In dit geval gaat het om een tunnel aangeven bij 20 bij 150 hokjes. We kunnen hieruit concluderen dat er een aantal delen van hoge prioriteit zijn. Naar hoge verwachting ligt er een mens op punt (4,15), bij (7,130) en bij (19,125). Er zal dus zo snel mogelijk geprobeerd worden daar een slachtoffer vandaan te halen. Het is aan de hulpverlener om de uiteindelijke route te lopen.<br />
<br />
Ter oriëntatie zal door middel van GPS de plaats op de kaart aangegeven worden.<br />
<br />
==Bronnen==<br />
[1]‘Isues in Inteligent Robots for Search and Rescue’ by Jenifer Casper, Mark Micire, Robin R. Murphy in “Proc. SPIE 4024, Unmanned Ground Vehicle Technology II” University of South Florida (July 10, 2000), page 293</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17285PRE2Groep2 Protocol2015-01-12T10:20:23Z<p>S127922: </p>
<hr />
<div>='''Protocol“Gevaarlijke ‘Search and Rescue’ operaties met robots”'''=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. [1] Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
* Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
* Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
* De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
* Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
* Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
* Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk "Gebruik van de terminals"). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===<br />
Hulpverleners gaan met gebruik van de zo geheten terminals op zoek naar mensen in het rampgebied, doordat de robot de nodige data heeft verzameld kan er een duidelijke verdeling van prioriteit gesteld worden. Hierdoor worden gebieden met hogere kansen eerder onderzocht dan gebieden zonder waardes. De hulpverleners zullen volgens het hoofdstuk "Gebruik van de Terminals" handelen, om levenden slachtoffers zo snel mogelijk te redden. Gevonden slachtoffers zullen z.s.m. het gebied verlaten en zal waar mogelijk direct naar een zorginstelling vervoerd worden.<br />
<br />
===6. Zorginstellingen ===<br />
Binnengebrachte slachtoffers zullen worden onderzocht en nazorg zal worden gegeven volgens de standaard medische protocollen. Binnen het dossier zal de ramp gemeld worden zodat dit later herleidbaar zal zijn.<br />
<br />
<br />
==Gebruik van de Terminals==<br />
[[File:Terminal.png|right|thumb|Figuur 1: Terminal-dislay]]<br />
De terminals zullen de omgeving aangeven in een hoeveelheid hokjes. De werkelijke grootte ligt aan het vooraf ingestelde gebied. In figuur 1, is een voorbeeld te zien van een dergelijke terminal. Hierbij is op te merken dat hoe roder het hokje hoe groter de kans dat hier een mens ligt. In dit geval gaat het om een tunnel aangeven bij 20 bij 150 hokjes. We kunnen hieruit concluderen dat er een aantal delen van hoge prioriteit zijn. Naar hoge verwachting ligt er een mens op punt (4,15), bij (7,130) en bij (19,125). Er zal dus zo snel mogelijk geprobeerd worden daar een slachtoffer vandaan te halen. Het is aan de hulpverlener om de uiteindelijke route te lopen.<br />
<br />
Ter oriëntatie zal door middel van GPS de plaats op de kaart aangegeven worden.<br />
<br />
==Bronnen==<br />
[1]‘Isues in Inteligent Robots for Search and Rescue’ by Jenifer Casper, Mark Micire, Robin R. Murphy in “Proc. SPIE 4024, Unmanned Ground Vehicle Technology II” University of South Florida (July 10, 2000), page 293</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=File:Terminal.png&diff=17284File:Terminal.png2015-01-12T10:19:40Z<p>S127922: uploaded a new version of "File:Terminal.png"</p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=File:Terminal.png&diff=17283File:Terminal.png2015-01-12T10:19:21Z<p>S127922: </p>
<hr />
<div></div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17282PRE2Groep2 Protocol2015-01-12T10:18:43Z<p>S127922: /* Gebruik van de Terminals */</p>
<hr />
<div>='''Protocol“Gevaarlijke ‘Search and Rescue’ operaties met robots”'''=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. [1] Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
* Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
* Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
* De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
* Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
* Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
* Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk "Gebruik van de terminals"). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===<br />
Hulpverleners gaan met gebruik van de zo geheten terminals op zoek naar mensen in het rampgebied, doordat de robot de nodige data heeft verzameld kan er een duidelijke verdeling van prioriteit gesteld worden. Hierdoor worden gebieden met hogere kansen eerder onderzocht dan gebieden zonder waardes. De hulpverleners zullen volgens het hoofdstuk "Gebruik van de Terminals" handelen, om levenden slachtoffers zo snel mogelijk te redden. Gevonden slachtoffers zullen z.s.m. het gebied verlaten en zal waar mogelijk direct naar een zorginstelling vervoerd worden.<br />
<br />
===6. Zorginstellingen ===<br />
Binnengebrachte slachtoffers zullen worden onderzocht en nazorg zal worden gegeven volgens de standaard medische protocollen. Binnen het dossier zal de ramp gemeld worden zodat dit later herleidbaar zal zijn.<br />
<br />
[[File:Terminal|right|thumb|Figuur 1: Terminal-dislay]]<br />
==Gebruik van de Terminals==<br />
De terminals zullen de omgeving aangeven in een hoeveelheid hokjes. De werkelijke grootte ligt aan het vooraf ingestelde gebied. In figuur 1, is een voorbeeld te zien van een dergelijke terminal. Hierbij is op te merken dat hoe roder het hokje hoe groter de kans dat hier een mens ligt. In dit geval gaat het om een tunnel aangeven bij 20 bij 150 hokjes. We kunnen hieruit concluderen dat er een aantal delen van hoge prioriteit zijn. Naar hoge verwachting ligt er een mens op punt (4,15), bij (7,130) en bij (19,125). Er zal dus zo snel mogelijk geprobeerd worden daar een slachtoffer vandaan te halen. Het is aan de hulpverlener om de uiteindelijke route te lopen.<br />
<br />
Ter oriëntatie zal door middel van GPS de plaats op de kaart aangegeven worden.<br />
<br />
==Bronnen==<br />
[1]‘Isues in Inteligent Robots for Search and Rescue’ by Jenifer Casper, Mark Micire, Robin R. Murphy in “Proc. SPIE 4024, Unmanned Ground Vehicle Technology II” University of South Florida (July 10, 2000), page 293</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17281PRE2Groep2 Protocol2015-01-12T09:30:38Z<p>S127922: /* 2. Reddingswerkers ter plaatse */</p>
<hr />
<div>='''Protocol“Gevaarlijke ‘Search and Rescue’ operaties met robots”'''=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. [1] Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
* Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
* Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
* De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
* Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
* Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
* Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk "Gebruik van de terminals"). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===<br />
Hulpverleners gaan met gebruik van de zo geheten terminals op zoek naar mensen in het rampgebied, doordat de robot de nodige data heeft verzameld kan er een duidelijke verdeling van prioriteit gesteld worden. Hierdoor worden gebieden met hogere kansen eerder onderzocht dan gebieden zonder waardes. De hulpverleners zullen volgens het hoofdstuk "Gebruik van de Terminals" handelen, om levenden slachtoffers zo snel mogelijk te redden. Gevonden slachtoffers zullen z.s.m. het gebied verlaten en zal waar mogelijk direct naar een zorginstelling vervoerd worden.<br />
<br />
===6. Zorginstellingen ===<br />
Binnengebrachte slachtoffers zullen worden onderzocht en nazorg zal worden gegeven volgens de standaard medische protocollen. Binnen het dossier zal de ramp gemeld worden zodat dit later herleidbaar zal zijn.<br />
<br />
==Gebruik van de Terminals==<br />
<br />
<br />
<br />
==Bronnen==<br />
[1]‘Isues in Inteligent Robots for Search and Rescue’ by Jenifer Casper, Mark Micire, Robin R. Murphy in “Proc. SPIE 4024, Unmanned Ground Vehicle Technology II” University of South Florida (July 10, 2000), page 293</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17280PRE2Groep2 Protocol2015-01-12T09:30:02Z<p>S127922: /* Bronnen */</p>
<hr />
<div>='''Protocol“Gevaarlijke ‘Search and Rescue’ operaties met robots”'''=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. [1] Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
* Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
* Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
* De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
* Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
* Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
* Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk werking). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===<br />
Hulpverleners gaan met gebruik van de zo geheten terminals op zoek naar mensen in het rampgebied, doordat de robot de nodige data heeft verzameld kan er een duidelijke verdeling van prioriteit gesteld worden. Hierdoor worden gebieden met hogere kansen eerder onderzocht dan gebieden zonder waardes. De hulpverleners zullen volgens het hoofdstuk "Gebruik van de Terminals" handelen, om levenden slachtoffers zo snel mogelijk te redden. Gevonden slachtoffers zullen z.s.m. het gebied verlaten en zal waar mogelijk direct naar een zorginstelling vervoerd worden.<br />
<br />
===6. Zorginstellingen ===<br />
Binnengebrachte slachtoffers zullen worden onderzocht en nazorg zal worden gegeven volgens de standaard medische protocollen. Binnen het dossier zal de ramp gemeld worden zodat dit later herleidbaar zal zijn.<br />
<br />
==Gebruik van de Terminals==<br />
<br />
<br />
<br />
==Bronnen==<br />
[1]‘Isues in Inteligent Robots for Search and Rescue’ by Jenifer Casper, Mark Micire, Robin R. Murphy in “Proc. SPIE 4024, Unmanned Ground Vehicle Technology II” University of South Florida (July 10, 2000), page 293</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17279PRE2Groep2 Protocol2015-01-12T09:28:58Z<p>S127922: /* 5. Hulpverleners */</p>
<hr />
<div>='''Protocol“Gevaarlijke ‘Search and Rescue’ operaties met robots”'''=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. [1] Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
* Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
* Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
* De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
* Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
* Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
* Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk werking). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===<br />
Hulpverleners gaan met gebruik van de zo geheten terminals op zoek naar mensen in het rampgebied, doordat de robot de nodige data heeft verzameld kan er een duidelijke verdeling van prioriteit gesteld worden. Hierdoor worden gebieden met hogere kansen eerder onderzocht dan gebieden zonder waardes. De hulpverleners zullen volgens het hoofdstuk "Gebruik van de Terminals" handelen, om levenden slachtoffers zo snel mogelijk te redden. Gevonden slachtoffers zullen z.s.m. het gebied verlaten en zal waar mogelijk direct naar een zorginstelling vervoerd worden.<br />
<br />
===6. Zorginstellingen ===<br />
Binnengebrachte slachtoffers zullen worden onderzocht en nazorg zal worden gegeven volgens de standaard medische protocollen. Binnen het dossier zal de ramp gemeld worden zodat dit later herleidbaar zal zijn.<br />
<br />
==Bronnen==<br />
[1]‘Isues in Inteligent Robots for Search and Rescue’ by Jenifer Casper, Mark Micire, Robin R. Murphy in “Proc. SPIE 4024, Unmanned Ground Vehicle Technology II” University of South Florida (July 10, 2000), page 293</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17274PRE2Groep2 Protocol2015-01-12T09:17:00Z<p>S127922: </p>
<hr />
<div>='''Protocol“Gevaarlijke ‘Search and Rescue’ operaties met robots”'''=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. [1] Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
* Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
* Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
* De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
* Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
* Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
* Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk werking). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===<br />
<br />
==Bronnen==<br />
[1]‘Isues in Inteligent Robots for Search and Rescue’ by Jenifer Casper, Mark Micire, Robin R. Murphy in “Proc. SPIE 4024, Unmanned Ground Vehicle Technology II” University of South Florida (July 10, 2000), page 293</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17273PRE2Groep2 Protocol2015-01-12T01:47:43Z<p>S127922: </p>
<hr />
<div>='''Protocol“Gevaarlijke ‘Search and Rescue’ operaties met robots”'''=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
* Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
* Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
* De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
* Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
* Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
* Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk werking). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Protocol&diff=17272PRE2Groep2 Protocol2015-01-12T01:46:05Z<p>S127922: Created page with '=Protocol “Gevaarlijke ‘Search and Rescue’ operaties met robots”= ==Inleiding:== In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporgan…'</p>
<hr />
<div>=Protocol<br />
“Gevaarlijke ‘Search and Rescue’ operaties met robots”=<br />
<br />
==Inleiding:==<br />
In het geval van een reddingoperatie is het van groots belang dat de betrokken hulporganisaties goed samen werken en een cruciaal onderdeel om dit te bewerkstelligen is weten wat iedereen zijn taak is en hoe deze uitgevoerd wordt een onmisbaar aspect. In protocollen zijn een duidelijke structuur voor de desbetreffende instanties in een elke mogelijke situatie, om niet alleen de operatie zo goed mogelijk te laten verlopen, maar ook de veiligheid aan beide kanten zo goed mogelijk te waarborgen en te zorgen voor een goede nasleep.<br />
<br />
==Reddingsoperatie==<br />
Dit protocol is geschreven voor de nieuwe standaard in reddingsoperaties, in een wereld van klimaatveranderingen, opstanden en oorlogen zullen er genoeg situaties opduiken waarbij de hulpverlening snel en goed op gang zal moeten komen. Uit eerdere reddingsoperaties is te vinden dat in de eerste 30 minuten al bijna 10% van de overlevenden was overleden en na 2 dagen al bijna 2/3 overleden is. Deze getallen zullen als er gevaarlijke stoffen aanwezig zijn natuurlijk nog lager zijn. Het is daarom dus zeer belangrijk dat een redding snel begint en snel uitgevoerd wordt. Huidige operaties worden uitgevoerd door het zoeken van hulpverleners in het rampgebied, al dan niet met hulp van zoekhonden, hopend op een teken van leven of een aanwijzing. Dit heeft als nadeel dat de hulpverleners, gedeeltelijk blind, en voor gevaar voor eigen leven lang in het gebied moeten zijn. Hierbij worden ze zelf mogelijk ook blootgesteld aan de gevaren, een omgeving van giftige gassen, rook en/of straling valt zeker in de mogelijkheden. Om de veiligheid van de reddingswerkers te vergroten en de reddingsoperatie gerichter uit te voeren is de robot aangeschaft om in (gevaarlijke) operaties levende slachtoffers te kunnen lokaliseren terwijl de voorbereidingen van de reddingsoperatie worden opgestart. De robot zal gebruik maken van middelen die verder gaan dan visuele, zodat ook verborgen slachtoffers gevonden worden.<br />
<br />
==Protocol== <br />
In korte lijnen zal het protocol voor toekomstige reddingsoperaties met gebruik van de robot er zo uit zien:<br />
1. Melding komt binnen en wordt doorgegeven aan betreffende hulpverleners.<br />
2. Reddingswerkers gaan ter plaatse en stelt de robot in staat om het rampgebied te verkennen.<br />
3. De reddingswerkers zullen de situatie van de ramp plek inschatten en maatregelen ter bescherming nemen en schakelen specialistische hulpverleners in<br />
4. Specialistische hulpverleners komen ter plaatse, terwijl de data van de robot wordt geanalyseerd.<br />
5. Met de locaties van (mogelijke) slachtoffers zullen de hulpverleners korte en gerichte routes door het rampgebied. <br />
6. Slachtoffers worden met spoed naar een zorginstelling gebracht worden.<br />
<br />
===1. Melding===<br />
Ten tijde van een rampsituatie zullen omstanders, betrokkenen of eventueel hulpverleners overgaan tot melding. Deze zal in meeste gevallen doorgestuurd worden naar de (plaatselijke) brandweer, maar kan in verschillende situaties anders opgelost worden. Dergelijke hulpverleners zijn bij dergelijke meldingen in het bezit van een of meerdere redding robots.<br />
<br />
===2. Reddingswerkers ter plaatse===<br />
Als de hulpverleners aangekomen zijn bij het ramp gebied zullen ze eerst een aantal, afhankelijk van het gebied, redding robots opstarten, voordat andere maatregelen getroffen worden. Deze zullen autonoom werken, verder instructies na initiële instellingen zijn niet nodig (zoals beschreven wordt in het hoofdstuk werking). De robots kunnen dan werken nog voor conventionele hulpverlening kan beginnen, om geen tijd te verliezen.<br />
<br />
===3. Reddingswerkers schatten situatie in===<br />
De ingeschakelde hulpverleners schatten de situatie in en geven dit door naar de meldkamer. Afhankelijk van de omvang zullen specialistische reddingswerkers gestuurd evenals veiligheidskleding etc. behorend tot de rampsituatie. Ondertussen zullen de eerste hulpverleners de plek veilig stellen en voorbereidingen treffen zodat een actie kan beginnen. <br />
<br />
===4a. Specialistische hulpverleners komen ter plaatste===<br />
Afhankelijk van het scenario zullen experts op het gebied van giftige, radioactieve of (bio-)chemische omgevingen op de ramp aankomen met beschermende kleding en gereedschap en beginnen met het instrueren van de hulpverleners ter plaatse over de aanpak van redding.<br />
<br />
===4b. Data van de robot wordt geanalyseerd===<br />
Terwijl reddingsoperatie op gang komt zal in de data van de robot worden geanalyseerd door hiervoor getrainde hulpverleners. Dit zal het systeem gedeeltelijk zelf analyseren en de hulpverlener zal dit aanvullen totdat een duidelijke ‘routebeschrijving’ van het gebied gemaakt kan worden. Deze informatie zal worden geüpload naar terminals, die in directe verbinding staan met het apparaat en gebruikt gaan worden door de hulpverleners. De terminals worden dan uitgedeeld aan de hulpverleners tijdens hun laatste voorbereidingen.<br />
<br />
===5. Hulpverleners ===</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2_Groep2&diff=17271PRE2 Groep22015-01-12T01:42:53Z<p>S127922: </p>
<hr />
<div>__FORCETOC__<br />
<br />
==Project overzicht==<br />
Wij hebben ervoor gekozen om in ons project te kijken of met behulp van speciaal hiervoor uitgeruste drones het mogelijk is om bij een situatie waarbij er brand en veel rook in een tunnel/gang staat slachtoffers sneller te vinden (en dus te redden). In een dergelijk scenario komt het al snel voor dat het moeilijk tot onmogelijk is voor reddingswerkers om zelf te verkennen. Wij willen hier een oplossing voor vinden.<br />
<br />
===Leden===<br />
* Jelte Borsboom<br />
* Merlijne Geurts<br />
* Linde Koning<br />
* Koen Tange<br />
<br />
==Scenario beschrijving==<br />
Door een ramp is er rookvorming in een tunnel, hierdoor is het zicht belemmerd. Er liggen slachtoffers in de tunnel, maar het is zeer risicovol voor reddingswerkers om de tunnel in te gaan. In plaats van het zoeken naar slachtoffers over te laten aan reddingswerkers wordt er een drone ingezet die uitgerust is met een RFID antenne en warmte sensoren. Door te zoeken naar RFID chips en dit te combineren met de readings van de warmte sensoren bepaalt de robot de kans dat er zich een mens bevindt. Dit wordt doorgegeven aan de reddingswerkers, waarna er een route bepaald kan worden die zoveel mogelijk (potentiele) slachtoffers afgaat, en de reddingswerkers de tunnel in kunnen gaan om deze te redden terwijl ze zichzelf zo min mogelijk in risicovolle situaties bevinden.<br />
<br />
== Onderzoeksvraag ==<br />
<br />
Hoe is het mogelijk om een mens te detecteren, door middel van een combinatie van RFID en een infrarood sensor, in een omgeving waarbij het zicht belemmerd is?<br />
<br />
== Deelvragen ==<br />
<br />
* Welke technieken zijn nog niet ontwikkeld voor de sensoren van een rescue robot in een tunnel brand?<br />
* Welke technieken bestaan al voor de sensoren van een rescue robot in een tunnel brand?<br />
* Wie zijn de belanghebbende en welke rol hebben zij?<br />
* Met welke sensoren kan een mens gedetecteerd worden? En welke sensoren zijn geschikt in een omgeving zoals in het scenario omschreven?<br />
<br />
<br />
* Hoe kan je met RFID objecten lokaliseren?<br />
* Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?<br />
* Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?<br />
<br />
<br />
* Hoe betrouwbaar is het systeem van RFID en infrarood sensoren?<br />
* Hoe gaat het reddingsprotocol eruit zien, met behulp van de RFID en infrarood sensor?<br />
* Welke argumenten zijn er voor/tegen het RFID/infrarood sensor systeem?<br />
<br />
==[[Voorlopige planning]]==<br />
<br />
==[[Literatuur onderzoek]]==<br />
<br />
==[[PRE2Groep2_Experiment|Experiment]]==<br />
<br />
==[[PRE2Groep2_Protocol|Nieuw Protocol rampsituaties]]==<br />
<br />
== [[Ethiek PRE2Groep2|Ethiek onderzoek]] ==<br />
<br />
==Weekoverzicht==<br />
===[[Week 1 PRE2Groep2|Week 1]]===<br />
Onderwerp uitkiezen; Algemene informatie reddinsrobot, sensoren en bewegings detectie<br />
===[[Week 2 PRE2Groep2|Week 2]]===<br />
Concept project presentatie; Informatie detecteren mensen<br />
===[[Week 3 PRE2Groep2|Week 3]]===<br />
Uiteindelijk project presentatie; informatie bestaande technieken, te ontwikkelen technieken en belanghebbende<br />
===[[Week 4 PRE2Groep2|Week 4]]===<br />
Onderdelenlijst; Onderzoeksplan; Sensor fusie; Ethiek onderzoek<br />
===[[Week 5 PRE2Groep2|Week 5]]===<br />
Ethiek onderzoek<br />
===[[Week 6 PRE2Groep2|Week 6]]===<br />
Experiment; Ethiek onderzoek<br />
<br />
===[[Week 7 PRE2Groep2|Week 7]]===<br />
Conclusies experiment<br />
<br />
==Logboek==<br />
[https://docs.google.com/spreadsheets/d/10rVYZCUgKiC57V0ommYVOv5PVhXFOKefqlhpftt_2fg/edit?usp=sharing Google Spreadsheets logboek]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17270PRE2Groep2 Experiment2015-01-12T01:40:31Z<p>S127922: /* Samenvoegen Sensoren */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het project. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
===Arduino===<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op de analoge input van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar Matlab op een van onze computers. in Matlab worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
'''Bronnen'''<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van een gemiddelde over daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster. <br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR'''' Voor de corrigeerden IR data in procentpunten<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
end <br />
<br />
'''RIFBAR''' Voor de RFID data in procentpunten<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
end<br />
<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na een sample of 20 tot 40 al even betrouwbaar als bij 1000 samples. De IR-sensor had zo'n kleine afwijking dat de eerste sample in alle gevallen al dicht genoeg bij het gemiddelde zat om het niet in de output te kunnen merken.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=Week_6_PRE2Groep2&diff=17269Week 6 PRE2Groep22015-01-12T01:37:42Z<p>S127922: /* Hitte signaal */</p>
<hr />
<div>'''Feedback maandag 15-12-2014'''<br />
* De eindpresentatie zal plaats vinden in week 8.<br />
* Hoe wordt de temperatuur in één grid vakje bepaald? In een vakje zullen er namelijk meerdere temperaturen gemeten worden.<br />
* Hoe wordt de onzekerheid van de gereedschappen meegenomen in de beslissing of ergens een mens ligt?<br />
* Het onderzoeksplan is nog niet concreet genoeg. Bedenk voordat er met het onderzoek wordt gestart goed na wat je gaat doen.<br />
* Wat is het nut van het systeem? Worden alleen de plaatsen gegeven waar de mensen zijn? Of worden alle temperaturen door gegeven, zodat de reddingswerker ook mensen kan vinden zonder RFID chip?<br />
<br />
'''Meeting vrijdag 19-12-2014'''<br />
<br />
Op vrijdag is er meeting gehouden. Tijdens deze meeting hebben we de laatste afspraken gemaakt over het experiment dat maandag uitgevoerd zal worden.<br />
<br />
= Uitvoering experiment =<br />
::''Zie [[PRE2Groep2_Experiment|Experiment]] voor het hoofdartikel over dit onderwerp.''<br />
Op maandag 22 december is er op de Technische Universiteit Eindhoven een experiment uitgevoerd om het bedachte systeem in een geïsoleerde omgeving te testen. <br />
<br />
==Beschrijving==<br />
In een rasterwereld waren zowel warmtebronnen als RFID-tags geplaatst om een tunnel op kleine schaal na te bootsen. De robot kon een vastgestelde tijd data te vergaren per hokje. Dit werd gedaan met verschillende tijden en in verschillende werelden.<br />
<br />
==Conclusies==<br />
Door de data te verwerken en daarna te vergelijken met de bekende werelden kunnen er conclusies over de betrouwbaarheid getrokken worden.<br />
[[File:RIFD-500m1.png|right|thumb|300px|Figuur 1: RFID-signaalverschil in mV boven zwakste signaal]]<br />
====RFID signaal==== <br />
1. Het RFID signaal had een zwakke reactie, de verschillen tussen het hoogste signaal (hokje met een RFID-tag) en het laagste was maximaal 1,6169 mV.<br />
<br />
2. Het RFID signaal gaf in het hokje met een RFID signaal een heel duidelijk signaal, het signaal in de hokjes eromheen (ong. 8cm afstand) gaf in de meeste gevallen een lager (maar zichtbaar) verschil. <br />
<br />
3. Sommige hokjes kregen een heel onverwacht hoge of lage waarde, dit kan te wijden zijn aan:<br />
:a. Meetfouten.<br />
:b. Meerdere RFID-signalen van verschillende tags die met elkaar interfereren.<br />
::Radiogolven met dezelfde frequentie elkaar in tegen-fase kunnen uitdoven, kunnen golven in fase elkaar juist versterken.<br />
<br />
===Hitte signaal===<br />
- Het hitte signaal was betrouwbaar, maar ook op een afstand tot maximaal 16cm.<br />
<br />
= Ethiek onderzoek =<br />
[[Ethiek PRE2Groep2|Uitwerking onderzoek]]<br />
<br />
'''Recht'''<br />
* Is het toegestaan dat een extern bedrijf de RFID tags uitleest?<br />
Voor ieder bedrijf geldt er dat de chips uitgelezen kunnen worden, wanneer zij een documentlezer hebben. Het is niet mogelijk voor het bedrijf om de vingerafdrukken op de chip in het paspoort uit te lezen [1]. Het is dus toegestaan om de RFID tags uit te lezen.<br />
Bron: [1] Mag een bedrijf of organisatie de chip in mijn identiteitsbewijs uitlezen? (n.d). College bescherming persoonsgegevens. Geraadpleegd op 3-1-2015 om 12.21. https://www.mijnprivacy.nl/VeelgesteldeVragen/Pages/chip-identiteitsbewijs-uitlezen.aspx <br />
<br />
* Is het toegestaan dat mensen met de RFID chips worden gelokaliseerd?<br />
Met een RTLS (Real Time Location System) is het mogelijk om de RFID chips te lokaliseren. Dit kan door het plaatsen van antennes op een strategische plaats [2]. Maar de vraag is of met behulp van dit systeem de mensen ook gelokaliseerd mogen worden. <br />
Voor GPS geldt er dat voor werknemers van een bedrijf, eerst naar de ondernemingsraad toestemming moet worden gevraagd [1]. Verder geldt er de Wet op Bescherming van Persoonsgegevens en moet er kunnen worden aangegeven dat het nodig is om het volgen noodzakelijk is [1]. Het is belangrijk dat de privacy van de persoon niet in het geding komt [1]. Door de Wet Registratie Persoonsgegevens stelt dat er geen privacy-inbreuk, mag worden gemaakt. Zo mag er geen informatie worden opgeslagen worden, zodat er naar een bepaald persoon geleid mag worden [3].<br />
Dit kan ook worden toegepast op RFID chips, dit zou betekenen dat het noodzakelijk is om de mensen te lokaliseren en dat de privacy van de slachtoffers niet wordt geschaad. Zo mag de persoonlijke informatie niet worden opgeslagen. Ook mag alleen in de noodsituatie het lokalisatie systeem worden aangezet. <br />
Bron:[1]Baas mag personeel niet bespieden via GPS (2012). OfficeGrip. Geraadpleegd op 3-1-2015 om 12.26. http://officegrip.nl/baas-mag-personeel-niet-bespieden-via-gps/ <br />
[2]Real Time Location (RTLS) (n.d.). WIFI Advies. Geraadpleegd op 3-1-2015 om 12.27. http://www.wifi-advies.nl/technologie/real-time-location<br />
[3] GPS, C-track of Blackbox-systemen (n.d.). FNV. Geraadpleegd op 3-1-2015 om 12.29. http://www.fnvbondgenoten.nl/themas/or_en_pvt/or_en_privacy/artikelen/volgsystemen/ <br />
<br />
* Zijn mensen verplicht om een paspoort bij zich te hebben met een RFID tag?<br />
In Nederland geldt er een identificatieplicht. Dit betekend dat iemand zich moet kunnen identificeren als een controleur (politieagent, conducteur in het openbaar vervoer, BOA’s) hiernaar vraagt. Zonder reden mag er niet naar de identiteit van een persoon worden gevraagd. [1] Verder geldt er ook op het werk dat iemand zich iedere dag moet kunnen identificeren. Zo kan het zijn dat een werkplekcontrole wordt uitgevoerd [1]. Als de identiteit op het werk niet kan worden vastgesteld, bestaat een kans dat de persoon naar het politiebureau moet gaan. [1] <br />
In de zorg geldt er voor iedereen een identificatieplicht, ook voor minderjarige [1]. <br />
De identificatieplicht geldt niet voor een minderjarige die jonger is dan 14 jaar. [1] Mensen zijn dus niet verplicht om een RFID tag bij zich te hebben.<br />
Bron: [1] Identificatieplicht (n.d.). Rijksoverheid. Geraadpleegd op 3-1-2015 om 12.30. http://www.rijksoverheid.nl/onderwerpen/paspoort-en-identificatie/identificatieplicht <br />
<br />
* Hoe moet de wet worden aangepast, zodat er zeker vanuit gegaan kan worden dat iedereen opspoor baar is met behulp van RFID? <br />
Wanneer de identificatieplicht veranderd wordt in een draagplicht, is er meer zekerheid dat iedereen een RFID chip bij zich heeft. Verder moet dit ook gaan gelden voor minderjarige mensen. <br />
Een probleem met de draagplicht is dat dit in strijd is met de rechten van het kind en het recht op eerbiediging van privé-, familie- en gezinsleven [1,2].<br />
Een ander punt waardoor er in Nederland weerstand is, is door de Tweede Wereldoorlog. Door de identificatieplicht zijn er veel Joden gedood [1].<br />
Bron: [1] Ophef over identificatieplicht (2012). Privacy First. Geraadpleegd op 3-1-2015 om 12.31. https://www.privacyfirst.nl/privacy-first/columns/item/515-ophef-over-identificatieplicht.html <br />
[2] Wet- en Regelgeving (n.d.) . Overheid. Geraadpleegd op 3-1-2015 om 12.32. http://wetten.overheid.nl/zoeken_op/regeling_type_alle/titel_of_afkorting_%2522EVRM%2522/artikelnr_%25228%2522/datum_02-01-2015/deeplink <br />
<br />
'''Privacy'''<br />
* Hoeveel mensen hebben een RFID tag bij zich, zoals paspoort, bankpas of ov-chipkaart?<br />
In 2013 waren er ruim 25 miljoen ID-kaarten, paspoorten en rijbewijzen in omloop [1]. Verder zijn er 27.7 miljoen bankpassen en 5.6 miljoen creditcards in omloop. Ook zijn er ook nog 7.5 miljoen bruikbare persoonlijke OV-chipkaarten in omloop [1]. Dit komt gemiddeld neer op 3 private identiteitsdragers per persoon [1]. <br />
Deze kaarten worden natuurlijk niet altijd bijgedragen. De gevolgen hiervan kunnen gevonden worden in Verantwoordelijkheid. <br />
Bron: [1] Ministerie van Binnenlandse Zaken en Konikrijksrelaties(12-12-2013). Identiteit in Cijfers. 1-22. <br />
<br />
'''Acceptatie'''<br />
* Zullen mensen het accepteren als een robot helpt in een ramp situatie?<br />
Om de overlevingskans van een overlevende te bevorderen, kan met een rescue robot het slachtoffer gemonitord worden [1]. Verder kan het slachtoffer op zijn gemak worden gesteld door de rescue robot [1]. Dit hangt af van de benadering van de rescue robot naar het slachtoffer [2]. Mensen zullen meer op hun gemak zijn bij de robot als de robot in een emotionele stand staat [2]. In de emotionele stand wordt het slachtoffer langzamer benaderd en zal de robot meer georiënteerd blijven op het slachtoffer [2].<br />
Wanneer de rescue robot, de persoon dus op een goede manier benadert, zal de overlevingskans van de persoon verhoogd worden. Verder zal de persoon ook meer op zijn gemak zijn en zal eerder een robot accepteren in een ramp situatie. <br />
Bron: [1] R.R. Murphy, M. Minson, S. Egawa (2013). Interacting with trapped victims using robots. IEEE (2013). 32-37. <br />
[2] C. L. Bethel, C. Bringes, R.R. Murphy (2009). Non-facial and non-verbal affective expression in appearance-constrained robots for use in victim management: robots to the rescue! ACM (2009). 191. <br />
<br />
* Wat gebeurd er met de mensen die geen chip bij zich hebben, zoals baby’s en kinderen?<br />
Voor kinderen geldt er dat zij zich moeten kunnen identificeren, wanneer zij gaan reizen [1]. Verder moeten kinderen zich ook kunnen identificeren in de zorg [1]. <br />
Wanneer kinderen in het buitenland zijn of in een zorginstantie, kan er vanuit worden gegaan dat er in de buurt van het kind een RFID chip zich bevindt. Echter in de noodsituatie kan er niet worden uitgegaan dat er in de buurt van het kind een RFID chip is. <br />
Een maatregel om er voor te zorgen dat kinderen wel een RFID chip bij zich hebben, is het inbrengen van een microchip-implantaat, dit zal een RFID tag zijn [2]. Echter bestaat er bij deze maatregel wel een kans op medische problemen, zoals afstotingsreacties, schade tijdens de plaatsing van de chip en gezwellen [2]. Verder bestaat er ook een kans dat de RFID tag wordt gehackt [2]. Wanneer er echter geen informatie op de RFID tag wordt geplaatst, is dit geen probleem. Er zijn ook ethische vraagstukken over deze microchip. Zo kan de privacy van de mens geschaad worden, doordat de microchip niet beveiligd is en doordat er medische problemen optreden [2]. <br />
Om er zeker van te zijn dat alle kinderen een chip hebben, kan dit in de wet worden opgenomen dat ieder kind een chip heeft. Echter zijn er in de Verenigde Staten al staten die een wet hebben aangenomen, dat dit verboden is [2].<br />
Verder zal tijdens de reddingsoperatie de reddingswerkers, nog altijd verantwoordelijk zijn voor het redden van de slachtoffers. Zij moeten er dus voor zorgen, dat ook mensen zonder chip gered zullen worden (zie Verantwoordelijkheid voor verdere uitleg).<br />
Een aanpassing aan de robot met sensoren kan zijn dat deze altijd de warmte van de omgeving opneemt, ook als er geen RFID chip in de buurt is. Hierdoor kan de reddingswerker bepalen waar gezocht gaat worden, ook al geeft de robot aan dat daar geen mens ligt. <br />
Bron: [1] Paspoort of identiteitskaart voor kinderen (n.d.). Rijksoverheid. Geraadpleegd op 3-1-2015 om 12.42. http://www.rijksoverheid.nl/onderwerpen/paspoort-en-identificatie/paspoort-of-identiteitskaart-voor-kinderen <br />
[2] Microchip-implantaat (2014). Wikipedia. Geraadpleegd op 3-1-2015 om 12.43. http://nl.wikipedia.org/wiki/Microchip-implantaat<br />
<br />
* Zullen mensen accepteren dat de tag wordt uitgelezen? <br />
De chips in Nederlandse reisdocumenten zijn beveiligd. De overheid heeft er voor gezorgd dat de communicatie versleuteld plaatsvind. Hierdoor is de chip onleesbaar door ongeautoriseerde instanties [1]. Tijdens het zoeken van de slachtoffers, zullen er geen gegevens worden ontvangen. Alleen de plaats van de RFID-tag wordt gelokaliseerd. <br />
Bron: [1] Wat is een elektronisch reisdocument en welke gegevens bevat de chip hierin? (n.d.). Rijksoverheid. Geraadpleegd op 3-1-2015 om 12.45. http://www.rijksoverheid.nl/onderwerpen/paspoort-en-identificatie/vraag-en-antwoord/wat-is-een-elektronisch-reisdocument-en-welke-gegevens-bevat-de-chip-hierin.html<br />
<br />
'''Veiligheid'''<br />
* Is het veilig om de rescue robot te gebruiken met sensoren?<br />
De sensoren op de robot zullen op een veilige afstand van het slachtoffer bevinden, tijdens het detecteren van de persoon. Hierdoor kan de robot de persoon niet nog meer verwonden. Echter zijn de sensoren op de drone bevestigd, hiermee kunnen problemen ontstaan. Zo is het mogelijk dat de drone neerstort [1]. Dit kan komen door mechanische storingen of door het weer, maar ook door menselijke fouten [1]. Echter zijn er nog geen mensen gedood bij het neerstorten van drones [1].<br />
Bron: [1] Ruim 400 drones VS sinds 2001 neergestort en dat leverde gevaar op (2014). NRC. Geraadpleegd op 3-1-2015 om 12.46. http://www.nrc.nl/nieuws/2014/06/21/ruim-400-drones-vs-sinds-2001-neergestort-en-dat-leverde-gevaar-op/ <br />
<br />
* Is het verstandig om mensen te detecteren met alleen de warmte van een mens?<br />
De lichaamstemperatuur van een persoon kan gedetecteerd worden met een human skin detector [1]. Alleen menselijke lichamen kunnen niet gedetecteerd worden in een omgeving met warmte, want dan is het menselijk lichaam niet het enig warme object in de ruimte [1]. Een lichaam van een slachtoffer, zal ook moeilijk te herkennen zijn als er lage activiteit is [1]. <br />
Bron: [1] K. Uto, H. Seki, Y. Kosugi, R. Murase, S. Takagishi (2012). Human detection based on active infrared illumination. IEEE Global humanitarian technology conference (2012). 47-52.<br />
<br />
* Is het verstandiger om meer false positives of false negatives, te verkrijgen van het sensoren system? <br />
De rescue robot met RFID sensor en IR sensor wordt aangestuurd door een algoritme. Dit algoritme bestaat uit een set instructies, die uiteindelijk zal concluderen of iemand een mens is of niet. Echter in dit algoritme zullen er een aantal keuzes gemaakt worden door de ontwerper, die een andere ontwerper anders zou hebben gedaan [1]. De ontwerper zorgt voor een ethisch standpunt in zijn algoritme [1]. Hierdoor is de software ontwerper moreel verantwoordelijk voor het algoritme dat ze ontwerpen [1]. Het probleem bij het algoritme voor het redden van mensen, is dat er false positivie of false negative situaties kunnen voorkomen. Een false positive situatie, is dat ergens volgens het algoritme een mens ligt, maar dit is niet het geval. Een false negative situatie, is dat ergens volgens het algoritme geen mens ligt, maar er ligt wel een mens. Wanneer iemand accepteert dat er meer false positive situaties zijn, dan zijn er vanzelf ook minder false negative situaties [1]. De ontwerper van het algoritme moet bepalen of er meer false positive situaties zijn of meer false negative situaties zijn [1]. Er is geen duidelijke lijn welke situatie de voorkeur heeft [1]. <br />
In het algoritme zal de beslissing of er op een plaats een mens ligt genomen worden door te kijken naar de temperatuur van de persoon. De temperatuur van een mens kan verschillen, hierdoor zal de temperatuur tussen een vastgestelde range moeten liggen. Echter de randen van de range hebben zijn niet scherp [1]. Verder zal er zich ook noise bevinden in het ontvangen signaal over de warmte van de persoon [1]. Het beste zal zijn dat alle false positive en false negative situaties vermeden worden [1]. Maar de voorkeur bij wetenschappers gaat uit naar minder false positives dan false negatives [1]. Bij artsen licht dit juist andersom [1].<br />
Tijdens het zoekproces moet de reddingswerker echter wel rekening houden dat in het zoekalgoritme keuzes zijn gemaakt. Hierdoor kan de reddingswerker niet alleen vertrouwen op de resultaten van de robot [1]. <br />
In het sensoren systeem wil je zo min mogelijk false negatives, want dit zou betekenen dat er iemand niet is gevonden. Maar de false positives moeten ook zo klein mogelijk zijn, omdat dit af gaat van de tijd om false negatives te zoeken. De meest ideale ratio van false negatives en false positives (false negative/false positive) is gelijk aan 0. Verder moet in deze ratio de false positives ook zo klein mogelijk zijn.<br />
Er moet ook gekeken worden naar de tijd besparing met de robot, wanneer de ratio (tijd met robot/tijd zonder robot) kleiner is dan 1, dan is het verstandig om de robot te gebruiken. In de tijd met de robot moet er ook de extra tijd berekend worden voor het zoeken naar false positives en false negatives. Tijdens het zoekproces zal eerst de robot de tunnel ingaan, hierna kunnen de reddingswerkers gericht gaan zoeken volgens de kaart die de robot heeft geproduceerd. De reddingswerker heeft met de kaart van de robot, dus meer succes om een persoon te vinden, dan zonder de kaart. <br />
Er moet binnen de tijd ratio een afweging gemaakt worden tussen de tijd die de robot nodig heeft voor het zoeken naar de mensen. Wanneer de robot snel te werk moet gaan, zullen er meer fouten gemaakt worden. (Zie de analyse van de sample rate van het experiment of er verschil is tussen de verschillende sample rates.) Echter wanneer de robot langzamer werkt dan een reddingswerker, dan is het verstandiger om geen robot te gebruiken. Er moet een afweging gemaakt worden tussen de juiste tijd, die de robot nodig heeft om voorwerk te doen met zo min mogelijk false negatives en een klein aantal false positives.<br />
De false negatives zijn mensen die niet gevonden zijn. Hierbinnen vallen de mensen die de robot niet heeft gevonden heeft, maar die wel een RFID chip bij zich hebben. Ook de mensen zonder RFID chip vallen hieronder. In Verantwoordelijkheid en “Wat gebeurt er met mensen die geen RFID chip bij zich hebben?” zullen deze gevallen besproken worden.<br />
Het meest verstandige is dus geen false negatives en het aantal false positives te verkleinen. Het aantal false positives en false negatives, zal afhangen van de tijd die de robot mag besteden in de tunnel. Echter deze tijd mag niet te lang zijn, omdat het anders niet rendabel is om de robot te gebruiken.<br />
Bron: [1] F. Kraemer, K. van Overveld, M. Peterson (2010). Is there an ethics of algorithms? Ethics Inf Technol (2011). 251-260.<br />
<br />
'''Aansprakelijkheid'''<br />
* Wie is er verantwoordelijk als iemand niet gevonden wordt met chip? <br />
In elke applicatie waar mensen samen werken met robots, zijn er gevaren en goed en slecht dat met elkaar vergeleken moeten worden[1]. Als het team vertrouwd dat de robot de capaciteiten heeft om een bepaald doel te bereiken, dan kan het team de robot dit werk laten doen [1]. In dit opzicht is het reddingsteam verantwoordelijk voor de keuze dat een rescue robot wordt gebruikt. Echter moet de reddingswerker niet alleen vertrouwen op de resultaten van de robot [2]. De robot zal namelijk volgens een algoritme werken en in dit algoritme zijn ook ontwerpkeuzes gemaakt door de software ontwerper. De software ontwerper is dus moreel verantwoordelijk voor het algoritme dat ontworpen wordt [2].<br />
De verantwoordelijkheid ligt dus gedeeltelijk bij het reddingsteam en voor een gedeelte bij de software ontwerper. <br />
Bron: [1] F. Kruijff, M. Janicek (2011). Using doctrines for human-robot collaboration to guide ethical behavior. Robot-Human Teamwork in Dynamic Adverse Environment (2011). 26-33.<br />
[2] F. Kraemer, K. van Overveld, M. Peterson (2010). Is there an ethics of algorithms? Ethics Inf Technol (2011). 251-260.<br />
<br />
* Wie is er verantwoordelijk als iemand niet gevonden wordt zonder een chip?<br />
Het reddingsteam heeft gekozen dat de robot in staat is om de mensen te vinden in het ramp situatie. Als het reddingsteam vertrouwen heeft dat de robot de slachtoffers kan vinden, dan is het toegestaan om de robot in te zetten [1]. Echter mag het reddingsteam niet alleen vertrouwen op de resultaten van de robot [2]. Wanneer een persoon niet gevonden wordt, omdat de reddingswerkers alleen hebben gekeken op de plaatsen die de robot aangeeft, is het de verantwoordelijkheid van het reddingsteam. <br />
Bron: [1] F. Kruijff, M. Janicek (2011). Using doctrines for human-robot collaboration to guide ethical behavior. Robot-Human Teamwork in Dynamic Adverse Environment (2011). 26-33.<br />
[2] F. Kraemer, K. van Overveld, M. Peterson (2010). Is there an ethics of algorithms? Ethics Inf Technol (2011). 251-260.<br />
<br />
[[PRE2_Groep2|Terug naar hoofdpagina]]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2_Groep2&diff=17268PRE2 Groep22015-01-12T01:37:00Z<p>S127922: /* Literatuur onderzoek */</p>
<hr />
<div>__FORCETOC__<br />
<br />
==Project overzicht==<br />
Wij hebben ervoor gekozen om in ons project te kijken of met behulp van speciaal hiervoor uitgeruste drones het mogelijk is om bij een situatie waarbij er brand en veel rook in een tunnel/gang staat slachtoffers sneller te vinden (en dus te redden). In een dergelijk scenario komt het al snel voor dat het moeilijk tot onmogelijk is voor reddingswerkers om zelf te verkennen. Wij willen hier een oplossing voor vinden.<br />
<br />
===Leden===<br />
* Jelte Borsboom<br />
* Merlijne Geurts<br />
* Linde Koning<br />
* Koen Tange<br />
<br />
==Scenario beschrijving==<br />
Door een ramp is er rookvorming in een tunnel, hierdoor is het zicht belemmerd. Er liggen slachtoffers in de tunnel, maar het is zeer risicovol voor reddingswerkers om de tunnel in te gaan. In plaats van het zoeken naar slachtoffers over te laten aan reddingswerkers wordt er een drone ingezet die uitgerust is met een RFID antenne en warmte sensoren. Door te zoeken naar RFID chips en dit te combineren met de readings van de warmte sensoren bepaalt de robot de kans dat er zich een mens bevindt. Dit wordt doorgegeven aan de reddingswerkers, waarna er een route bepaald kan worden die zoveel mogelijk (potentiele) slachtoffers afgaat, en de reddingswerkers de tunnel in kunnen gaan om deze te redden terwijl ze zichzelf zo min mogelijk in risicovolle situaties bevinden.<br />
<br />
== Onderzoeksvraag ==<br />
<br />
Hoe is het mogelijk om een mens te detecteren, door middel van een combinatie van RFID en een infrarood sensor, in een omgeving waarbij het zicht belemmerd is?<br />
<br />
== Deelvragen ==<br />
<br />
* Welke technieken zijn nog niet ontwikkeld voor de sensoren van een rescue robot in een tunnel brand?<br />
* Welke technieken bestaan al voor de sensoren van een rescue robot in een tunnel brand?<br />
* Wie zijn de belanghebbende en welke rol hebben zij?<br />
* Met welke sensoren kan een mens gedetecteerd worden? En welke sensoren zijn geschikt in een omgeving zoals in het scenario omschreven?<br />
<br />
<br />
* Hoe kan je met RFID objecten lokaliseren?<br />
* Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?<br />
* Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?<br />
<br />
<br />
* Hoe betrouwbaar is het systeem van RFID en infrarood sensoren?<br />
* Hoe gaat het reddingsprotocol eruit zien, met behulp van de RFID en infrarood sensor?<br />
* Welke argumenten zijn er voor/tegen het RFID/infrarood sensor systeem?<br />
<br />
==[[Voorlopige planning]]==<br />
<br />
==[[Literatuur onderzoek]]==<br />
<br />
==[[PRE2Groep2_Experiment|Experiment]]==<br />
<br />
== [[Ethiek PRE2Groep2|Ethiek onderzoek]] ==<br />
<br />
==Weekoverzicht==<br />
===[[Week 1 PRE2Groep2|Week 1]]===<br />
Onderwerp uitkiezen; Algemene informatie reddinsrobot, sensoren en bewegings detectie<br />
===[[Week 2 PRE2Groep2|Week 2]]===<br />
Concept project presentatie; Informatie detecteren mensen<br />
===[[Week 3 PRE2Groep2|Week 3]]===<br />
Uiteindelijk project presentatie; informatie bestaande technieken, te ontwikkelen technieken en belanghebbende<br />
===[[Week 4 PRE2Groep2|Week 4]]===<br />
Onderdelenlijst; Onderzoeksplan; Sensor fusie; Ethiek onderzoek<br />
===[[Week 5 PRE2Groep2|Week 5]]===<br />
Ethiek onderzoek<br />
===[[Week 6 PRE2Groep2|Week 6]]===<br />
Experiment; Ethiek onderzoek<br />
<br />
===[[Week 7 PRE2Groep2|Week 7]]===<br />
Conclusies experiment<br />
<br />
==Logboek==<br />
[https://docs.google.com/spreadsheets/d/10rVYZCUgKiC57V0ommYVOv5PVhXFOKefqlhpftt_2fg/edit?usp=sharing Google Spreadsheets logboek]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2_Groep2&diff=17267PRE2 Groep22015-01-12T01:36:32Z<p>S127922: </p>
<hr />
<div>__FORCETOC__<br />
<br />
==Project overzicht==<br />
Wij hebben ervoor gekozen om in ons project te kijken of met behulp van speciaal hiervoor uitgeruste drones het mogelijk is om bij een situatie waarbij er brand en veel rook in een tunnel/gang staat slachtoffers sneller te vinden (en dus te redden). In een dergelijk scenario komt het al snel voor dat het moeilijk tot onmogelijk is voor reddingswerkers om zelf te verkennen. Wij willen hier een oplossing voor vinden.<br />
<br />
===Leden===<br />
* Jelte Borsboom<br />
* Merlijne Geurts<br />
* Linde Koning<br />
* Koen Tange<br />
<br />
==Scenario beschrijving==<br />
Door een ramp is er rookvorming in een tunnel, hierdoor is het zicht belemmerd. Er liggen slachtoffers in de tunnel, maar het is zeer risicovol voor reddingswerkers om de tunnel in te gaan. In plaats van het zoeken naar slachtoffers over te laten aan reddingswerkers wordt er een drone ingezet die uitgerust is met een RFID antenne en warmte sensoren. Door te zoeken naar RFID chips en dit te combineren met de readings van de warmte sensoren bepaalt de robot de kans dat er zich een mens bevindt. Dit wordt doorgegeven aan de reddingswerkers, waarna er een route bepaald kan worden die zoveel mogelijk (potentiele) slachtoffers afgaat, en de reddingswerkers de tunnel in kunnen gaan om deze te redden terwijl ze zichzelf zo min mogelijk in risicovolle situaties bevinden.<br />
<br />
== Onderzoeksvraag ==<br />
<br />
Hoe is het mogelijk om een mens te detecteren, door middel van een combinatie van RFID en een infrarood sensor, in een omgeving waarbij het zicht belemmerd is?<br />
<br />
== Deelvragen ==<br />
<br />
* Welke technieken zijn nog niet ontwikkeld voor de sensoren van een rescue robot in een tunnel brand?<br />
* Welke technieken bestaan al voor de sensoren van een rescue robot in een tunnel brand?<br />
* Wie zijn de belanghebbende en welke rol hebben zij?<br />
* Met welke sensoren kan een mens gedetecteerd worden? En welke sensoren zijn geschikt in een omgeving zoals in het scenario omschreven?<br />
<br />
<br />
* Hoe kan je met RFID objecten lokaliseren?<br />
* Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?<br />
* Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?<br />
<br />
<br />
* Hoe betrouwbaar is het systeem van RFID en infrarood sensoren?<br />
* Hoe gaat het reddingsprotocol eruit zien, met behulp van de RFID en infrarood sensor?<br />
* Welke argumenten zijn er voor/tegen het RFID/infrarood sensor systeem?<br />
<br />
==[[Voorlopige planning]]==<br />
<br />
==[[Literatuur onderzoek]]==<br />
<br />
==[[PRE2Groep2_Experiment|Experiment]]<br />
<br />
<br />
== [[Ethiek PRE2Groep2|Ethiek onderzoek]] ==<br />
<br />
==Weekoverzicht==<br />
===[[Week 1 PRE2Groep2|Week 1]]===<br />
Onderwerp uitkiezen; Algemene informatie reddinsrobot, sensoren en bewegings detectie<br />
===[[Week 2 PRE2Groep2|Week 2]]===<br />
Concept project presentatie; Informatie detecteren mensen<br />
===[[Week 3 PRE2Groep2|Week 3]]===<br />
Uiteindelijk project presentatie; informatie bestaande technieken, te ontwikkelen technieken en belanghebbende<br />
===[[Week 4 PRE2Groep2|Week 4]]===<br />
Onderdelenlijst; Onderzoeksplan; Sensor fusie; Ethiek onderzoek<br />
===[[Week 5 PRE2Groep2|Week 5]]===<br />
Ethiek onderzoek<br />
===[[Week 6 PRE2Groep2|Week 6]]===<br />
Experiment; Ethiek onderzoek<br />
<br />
===[[Week 7 PRE2Groep2|Week 7]]===<br />
Conclusies experiment<br />
<br />
==Logboek==<br />
[https://docs.google.com/spreadsheets/d/10rVYZCUgKiC57V0ommYVOv5PVhXFOKefqlhpftt_2fg/edit?usp=sharing Google Spreadsheets logboek]</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17266PRE2Groep2 Experiment2015-01-12T01:34:34Z<p>S127922: /* Samenvoegen Sensoren */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het project. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
===Arduino===<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op de analoge input van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar Matlab op een van onze computers. in Matlab worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
'''Bronnen'''<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van een gemiddelde over daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster. <br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR''''<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
figure;<br />
h = bar3(G,1);<br />
colormap jet<br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end <br />
<br />
'''RIFBAR'''<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
figure;<br />
h = bar3(G,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
====Vergelijking met situatie====<br />
Als de bovenstaande plotten worden vergeleken met de van tevoren opgestelde situaties kunnen we concluderen dat de hokjes met zowel IR en RFID het hoogste scoren en de andere hokjes vooral door de IR worden gedomineerd. Dit zien wij als een goede manier om eventuele false negatives doordat het RFID-signaal te laag was alsnog wordt opgevangen door het hittesignaal.<br />
<br />
====Tijdsduur====<br />
Het laatste resultaat dat uit de data kwam was dat het onnodig was om 500 tot 1000 samples te gebruiken, dit was voor de berekeningen natuurlijk fijn, maar de output van de RFID was na een sample of 20 tot 40 al even betrouwbaar als bij 1000 samples. De IR-sensor had zo'n kleine afwijking dat de eerste sample in alle gevallen al dicht genoeg bij het gemiddelde zat om het niet in de output te kunnen merken.</div>S127922https://cstwiki.wtb.tue.nl/index.php?title=PRE2Groep2_Experiment&diff=17265PRE2Groep2 Experiment2015-01-12T01:26:04Z<p>S127922: /* Samenvoegen Sensoren */</p>
<hr />
<div>Een essentieel onderdeel van ons project is de uitvoering van het project. Door in een versimpelde wereld op schaal ons project te testen krijgen we de nodige data om conclusies over de haalbaarheid van deze oplossing te trekken.<br />
<br />
=Onderzoeksplan=<br />
===Inleiding===<br />
In het scenario is beschreven dat we de reddingsoperaties van gevaarlijke en zicht belemmerende situaties willen verbeteren doormiddel van een “Search-and-Rescue” robot. Dit zal gebeuren door middel van een autonome robot met een IR-sensor en een RFID-sensor. In ons onderzoek gaan wij er vanuit dat alle mensen in het bezit zijn van een of ander object met een RFID-chip.<br />
<br />
Er kan dus alleen een mens op een bepaalde locatie aanwezig zijn als er een hitte-patroon(±37°C) en een RFID respons aanwezig is.<br />
In het onderzoek zal de werking van de gebruikte sensoren getest worden. We zullen ervan uitgaan dat de robot al (autonoom) kan beweging en zullen dus niet ingaan op de bewegingen van de robot. Hierbij zullen we omgevingsvariabele zoals luchtdruk, luchtvochtigheid etc. buiten beschouwing laten.<br />
Met een combinatie van een RFID antenne en IR sensor zullen we alle combinaties van hitte bronnen en RFID-tags waarnemen in een bepaald gebied. Het onderzoek zal uitgevoerd worden op kleine schaal. (Zie onderzoeksopstelling)<br />
Door middel van dit onderzoek zullen we proberen de volgende deelvragen te beantwoorden:<br />
<br />
*“Hoe kan je met RFID objecten lokaliseren?”<br />
*“Hoe kan een infrarood sensor mensen detecteren, zodat er zo min mogelijk false positive en false negative situaties zijn?”<br />
*“Hoe kan een RFID sensor en een infrarood sensor een mens detecteren, door middel van sensor fusion?”<br />
<br />
===Voorbereiding===<br />
Het systeem (bestaande uit een Arduino met een RFID Shield en een IR-sensor) is dusdanig geprogrammeerd dat deze RFID tags detecteren en de temperatuur kan op meten. De responses van deze sensoren worden doorgestuurd naar de computer. <br />
De robot zal de route die hij rijdt bepalen met een zoek algoritme. Wij gebruiken bij ons experiment een vrij simpel algoritme die één voor één alle plekken langs gaat.<br />
<br />
===Variabelen===<br />
'''Meetvariabelen'''<br />
*IR: Temperatuur<br />
*RFID: Signaalsterke<br />
<br />
'''Omgevingsvariabelen''' <br />
*Omgevingstemperatuur<br />
<br />
===Materialen===<br />
De materialen gebruikt voor dit onderzoek zullen zijn:<br />
* [[PRE2Groep2 Experiment#Arduino|Arduino]] (incl. RFID Shield en een IR Sensor)<br />
* RFID Tags<br />
* Hittebronnen (bekers met warm water)<br />
* Tape voor het maken van het grid<br />
<br />
===Onderzoeksopstelling===<br />
Voor dit experiment hebben we een Arduino uitgerust met een 13.56Mhz RFID shield,en een thermopile shield. Op een tafel zal een raster gemaakt worden, en in sommige hokjes van dit raster worden objecten neergelegd waarop (minstens een van) de sensoren reageren. Op basis van de afmetingen van de RFID tags maken we de hokjes 9 bij 8.5cm groot. Voor het experiment worden kartonnen bekertjes gevuld met warm water, en op een aantal van deze bekertjes hebben we RFID tags vastgeplakt. Ook zijn er bekers met RFID tag die niet gevuld worden, zodat alle mogelijke detectie waardes van de sensoren gedekt zijn (Alleen warmte, Alleen RFID, en zowel warmte als RFID). De Arduino wordt iedere keer met de hand naar een volgend hokje in het raster gebracht, waarna deze zijn metingen doet en doorgeeft aan een computer.<br />
<br />
===Uitvoering onderzoek===<br />
De versimpelde versie van de robot, bestaande uit de Arduino, zal de ‘tunnel’ betreden van hokje naar hokje verplaatst worden tot dat de robot op elke locatie van de ‘tunnel’ geweest is. Bij elk hokje wordt de signaalsterkte van de RFID tags en de temperatuur op gemeten. Hierbij wordt de robot naar de dichtstbijzijnde warmte bron gericht.<br />
We voeren elke situatie van het experiment 2 keer uit. De eerste keer verzamelen we per locatie 500 samples en de tweede keer verzamelen we per locatie 1000 samples.<br />
De volgende situaties nemen we in beschouwing:<br />
<br />
'''Situatie 1'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|RW3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|}<br />
<br />
'''Situatie 2'''<br />
{| class="wikitable" border="1px solid #000000" style="text-align: center; width:750px; height:500px;"<br />
!<br />
!1<br />
!2<br />
!3<br />
!4<br />
!5<br />
!6<br />
!7<br />
!8<br />
!9<br />
!A<br />
!B<br />
|- <br />
!8<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW3<br />
|-<br />
!7<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!6<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W3<br />
|width="100"|RW4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!5<br />
|width="100"|<br />
|width="100"|W2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|R1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!4<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!3<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|W1<br />
|width="100"|<br />
|width="100"|RW2<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!2<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|-<br />
!1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|RW1<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|width="100"|<br />
|} <br />
<br />
===Onderzoek verslaglegging===<br />
De data die tijdens het onderzoek onderzocht gaan worden zullen per hokje worden opgeschreven. Hierin zullen de volgende gegevens in worden opgeslagen:<br />
<br />
'''Statische:'''<br />
*Afstand tot RFID tags<br />
* Afstand tot warmtebronnen<br />
<br />
'''Variabele:'''<br />
* Signaalsterkte RFID ontvanger<br />
* Temperatuurmeter <br />
<br />
===Analyse===<br />
Als eerst kan er met de gegevens van het onderzoek bepaald worden of het mogelijk is om mensen te detecteren met een RFID shield, een IR sensor en een combinatie van deze sensoren.<br />
Verder zal er met deze gegevens uitgezocht worden wat de “False positives en de “False negatives” gaan zijn. Ook wordt hierbij duidelijk hoe dicht het object bij de robot moet zijn voor een trigger. <br />
<br />
De gegevens zullen na het onderzoek door middel van Statistiek worden geanalyseerd om een uitkomst te kunnen geven van de betrouwbaarheid van dit onderzoek.<br />
<br />
===Aanpassingen in onderzoek===<br />
Aanpassingen in het onderzoek om eventuele onaanvaardbare uitkomsten te kunnen oplossen zijn:<br />
* Aanpassing van de ‘treshhold’ waardes<br />
* Aanpassing zoek-algoritmes<br />
<br />
<br />
<br />
===Arduino===<br />
We gebruiken een Arduino Mega uitgerust met een Adafruit PN532 NFC/RFID shield dat werkt op 13.56Mhz en een SparkFun Infrared Temperature Breakout - TMP006.<br />
De Sparkfun temperatuur sensor hebben we aangesloten zoals vermeld staat op de website van Sparkfun[1] (behalve dat we de kabels niet direct aan de Arduino aangesloten hebben, maar aan het RFID shield gesoldeerd hebben, waardoor we met behulp van SPI zowel het shield als de sensor kunnen aansturen), en we gebruiken de Sparkfun library[2] om hem eenvoudig aan te kunnen sturen. De library is voorzien van een handige functie die de gelezen temperatuur automatisch vertaald naar graden Celsius.<br />
<br />
Het RFID shield hebben we grotendeels ook volgens de documentatie van de leverancier aangesloten[3], met uitzondering van de antenne. Deze wordt standaard niet aangesloten op een Arduino aangezien de SOC deze uitleest en de taak van communicatie met RFID tags in het geheel op zich neemt. Om dit te omzeilen hebben wij op het RFID shield zelf een kabel vastgesoldeert aan de RX pin van de antenne. Deze sluiten we vervolgens aan op de analoge input van onze Arduino en kunnen zo de voltages van de antenne direct aflezen.<br />
Adafruit heeft voor het RFID Shield een handige library[4] geschreven, die wij gebruiken om de RFID antenne te initialiseren voor communicatie met passive RFID tags.<br />
<br />
De Arduino heeft zijn handen vol aan het continue inlezen van de antenne signalen, en niet genoeg geheugen om de signalen te kunnen verwerken. Daarom sturen we via USB alle signalen in realtime naar Matlab op een van onze computers. in Matlab worden alle data in matrices gezet, zodat we hier later analyses op kunnen uitvoeren.<br />
<br />
'''Bronnen'''<br />
* [1] TMP006 Hookup Guide - http://sfe.io/t116<br />
* [2] Sparkfun TMP006 firmware sourcecode - https://github.com/sparkfun/TMP006-Temp_Sensor_Breakout/tree/master/Firmware/TMP006<br />
* [3] Adafruit PN532 RFID/NFC Breakout and Shield - https://learn.adafruit.com/adafruit-pn532-rfid-nfc/overview<br />
* [4] Adafruit-PN532 - https://github.com/adafruit/Adafruit-PN532<br />
<br />
=Problemen tijdens experiment=<br />
Tijdens het uitvoeren van het experiment zijn we enkele onverwachte problemen tegengekomen.<br />
<br />
'''RFID antenne te zwak'''<br />
<br />
De RFID antenne die we gebruikt hebben bleek zeer zwak te zijn, en hierdoor konden we geen RFID signaal ontvangen op de afstand waarop we gehoopt hadden. Na wat experimenteren met de sensor is het gelukt om toch enigzins betrouwbare waardes af te kunnen lezen tot ongeveer 5 cm afstand. Hoewel dit nog steeds niet optimaal is, is het voldoende om het experiment toch uit te kunnen voeren.<br />
<br />
'''Temperatuur bekertjes'''<br />
<br />
De kartonnen bekertjes koelden zeer snel af wanneer we er warm water (ong. 60 graden celsius) in deden. Wanneer we een experiment uitvoerden met water dat net ingeschonken was, daalde de temperatuur tijdens het experiment van 50-60 graden naar 25-29 graden. Uiteindelijk hebben we besloten dat aangezien het verschil met de omgevingstemperatuur in alle gevallen groot genoeg was om het betrouwbaar te kunnen meten, we dit simpelweg over het hoofd zullen zien en alles boven de 26 graden als "mogelijk een mens" zullen beschouwen. In een echte situatie zal een mens natuurlijk nooit 50 graden of hoger als huidstemperatuur hebben, maar het zou triviaal zijn om een bovengrens te leggen aan de "toegestane mens temperatuur". Aangezien binnen de grenzen van ons experiment zich geen niet-menselijke objecten bevinden met een hoge temperatuur ''en'' een RFID signaal, hebben we besloten dat we zonder bovengrens kunnen werken.<br />
<br />
De grote verschillen in temperatuur hebben natuurlijk wel een invloed in de fusion met de data van de RFID sensor. Dit zal dan ook softwarematig moeten worden gecorrigeerd, hierbij is er aangenomen dat het water met een geleidelijke snelheid afkoelt.<br />
<br />
=Resultaten=<br />
[[File:RIFD-signaal.png|right|thumb|350px|Figuur 1: RFID-signaal over 500 samples]]<br />
De data verzameld door de Arduino kon niet direct gebruikt worden. Zoals zichtbaar in bijvoorbeeld figuur 1. Er is dus overduidelijk een soort van databewerking voor nodig, hiervoor zal MATLAB gebruikt worden. <br />
==Dataverwerking==<br />
====RFID====<br />
In het geval van het RFID signaal was het zichtbaar dat het een vrij stabiel signaal bleek, met uitzondering van een aantal duidelijke meetfouten. Deze fouten pieken in alle gevallen naar beneden, en kunnen door het gebruik van lokale maxima eruit gefilterd worden. Daarna is gekozen voor het gebruik van een gemiddelde over daarover. Omdat de verschillen tussen de waardes klein zijn t.o.v. (max. 16 mV) de absolute waarde (rond 2,9V) is de data genormaliseerd naar de laagste waarde in het raster. <br />
<br />
Er is gekozen voor een aangepaste 'BAR3' functie om in een oogopslag de totale informatie te kunnen bekijken van een bepaald raster. <br />
<br />
====IR====<br />
[[File:temp-signaal.png|right|thumb|350px|Figuur 2: temperatuur over 500 samples met gemiddeldelijn]]<br />
In tegenstelling tot het RFID signaal kon het signaal van de temperatuursensor al gedeeltelijk worden verwerkt door de Arduino, hierbij kwam een signaal binnen in graden Celsius. Dit bleef vrij constant over tijd en kon dus d.m.v. van de gemiddelde waarde bepaald worden. Ook hier is gekozen voor de aangepaste BAR3 functie.<br />
<br />
====MATLAB====<br />
Voor de verwerking zijn de volgende MATLAB-scripts geschreven:<br />
<br />
*'''RIFBAR''' Voor het plotten van de RIFD-data<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
title(matf);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
*'''TEMPBAR''' voor het plotten van de IR-data<br />
function [n]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
figure;<br />
h = bar3(B,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end<br />
<br />
*'''SIGNAL''' voor de verwerking van de signalen<br />
function [n,m] = signal(Y,f)<br />
s=zeros(100);<br />
m=zeros(11,8,100);<br />
n=zeros(11,8);<br />
for t=1:8<br />
for p=1:11<br />
for i=1:100<br />
r(i:i*5)=Y(p,t,i:i*5);<br />
if (f==true)<br />
a=findpeaks(r);<br />
<br />
else<br />
a=r;<br />
end<br />
s(i)=mean(a);<br />
m(p,t,i)=s(i);<br />
n(p,t)=mean(s(i));<br />
end <br />
end <br />
end<br />
end<br />
<br />
==Uitwerking==<br />
Door het gebruik van de bovenstaande MATLAB scripts komen voor de verschillende samples en werelden de volgende uitwerkingen.<br />
Hierbij is het xy-vlak het rasterveld en de z-as de waardes. Deze zijn bij de RFID in 10^-2 Volt en de IR in graden Celsius.<br />
<br />
{| class="wikitable" border="1px solid #FFFFFF"<br />
! style="font-weight: bold;" | <br />
! style="font-weight: bold;" | RFID Voor<br />
! style="font-weight: bold;" | RFID Boven<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
500 samples<br />
| [[File:RIFD-500m1.png |300px]]<br />
| [[File:RIFD112.png |300px]]<br />
| [[File:IR-500m1.png |300px]]<br />
| [[File:IR-500m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
1000 samples<br />
| [[File:RIFD-1000m1.png |300px]]<br />
| [[File:RIFD-1000m1b.png |300px]]<br />
| [[File:IR-1000m1.png |300px]]<br />
| [[File:IR-1000m1b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
500 samples<br />
| [[File:RIFD-500m2.png |300px]]<br />
| [[File:RIFD-500m2b.png |300px]]<br />
| [[File:IR-500m2.png |300px]]<br />
| [[File:IR-500m2b.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
1000 samples<br />
| [[File:RIFD--1000m2.png |300px]]<br />
| [[File:RIFD--1000m2b.png |300px]]<br />
| [[File:IR-1000m2.png |300px]]<br />
| [[File:IR-1000m2b.png |300px]]<br />
|}<br />
Notes:<br />
*Door communicatiefouten van de Arduino en de RFID-shield is de data bij zowel de 2de (Situatie 1, 1000samples) als de 3de meting (Situatie 2, 500samples) van de RFID niet bruikbaar voor verdere verwerking. Gelukkig valt uit de ruwe data vanuit de Arduino op te maken dat het aantal samples weinig invloed heeft op de uitkomst. Er zal dus met de 1ste en 4de meting worden doorgewerkt.<br />
*Een zichtbare daling van de warmtepieken is zichtbaar. Dit komt overeen met de conclusie die tijdens het onderzoek getrokken werd.<br />
<br />
==Sensorfusie==<br />
Er zijn duidelijke pieken te zien bij een hittebron, en vrij duidelijke pieken te zijn bij een RFID-tag. Om iets over de gezamenlijke informatie te zeggen is ervoor gekozen om beide data uit te drukken in percentpunten en deze op te tellen, zo zullen de hokjes waar beide sensoren reageren de hoogste waarde aangeven, maar zullen ook de hokjes met één sensor goed zichtbaar blijven. <br />
<br />
====Correctie IR-sensor====<br />
Inclusief de correctie voor de koudere wordende bekertjes, ziet de data er in percentpunten voor IR als volgt uit.<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR Voor<br />
! style="font-weight: bold;" | IR Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:IR-500m1p.png |300px]]<br />
| [[File:IR-500m1bp.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:IR-1000m2p.png |300px]]<br />
| [[File:IR-1000m2bp.png |300px]]<br />
|}<br />
<br />
====Samenvoegen Sensoren====<br />
Door de sinalen te combineren volgens de onderstaande MATLAB scripts kwamen we uit op de onderstaande gefuseerde plots<br />
<br />
{| class="wikitable" border="1px"<br />
! style="font-weight: bold;" | <br />
<br />
! style="font-weight: bold;" | IR&RFID Voor<br />
! style="font-weight: bold;" | IR&RFID Boven<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 1<br />
<br />
| [[File:fusion1.png |300px]]<br />
| [[File:fusion12.png |300px]]<br />
|-<br />
| style="text-align: right; font-weight: bold;" | Situatie 2<br />
<br />
| [[File:fusion2.png |300px]]<br />
| [[File:fusion22.png |300px]]<br />
|}<br />
'''FUSION''' voor de sensor-fusion<br />
r1500=rifbar(numb,matf);<br />
t1500=tempbar(numb,matf);<br />
tr1500=(r1500+t1500)/2;<br />
figure;<br />
h = bar3(tr1500,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
<br />
'''TEMPBAR''''<br />
function [G]= tempbar (numb, matf)<br />
Y=tempfind (numb, matf);<br />
n=signal(Y,false);<br />
B=n-min(n(:));<br />
for i=1:11<br />
for q=1:8 <br />
c=B(i,q);<br />
B(i,q)=(0.1+i/10+q/30)*c;<br />
end<br />
end<br />
n1=max(B(:));<br />
n2=min(B(:));<br />
G=(B-n2)/(n1-n2); <br />
figure;<br />
h = bar3(G,1);<br />
colormap jet<br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end <br />
<br />
'''RIFBAR'''<br />
function [G]= rifbar (numb, matf)<br />
Y=riffind (numb, matf);<br />
n=signal(Y,true);<br />
B=n-min(n(:));<br />
n1=max(n(:));<br />
n2=min(n(:));<br />
G=(n-n2)/(n1-n2);<br />
figure;<br />
h = bar3(G,1);<br />
colormap jet<br />
colorbar <br />
shading interp<br />
for i = 1:length(h)<br />
zdata = get(h(i),'ZData');<br />
set(h(i),'CData',zdata)<br />
set(h,'EdgeColor','k') <br />
end<br />
end</div>S127922