PRE2017 1 Groep3: Difference between revisions
Line 363: | Line 363: | ||
==18 September == | ==18 September == | ||
In the section above you can read about the plans that were made for week 2. In the following section, the results of that week will be described we will pinpoint the following steps. | In the section above you can read about the plans that were made for week 2. In the following section, the results of that week will be described we will pinpoint the following steps. | ||
• In week 2 a list of general RPC’s was made; that is, a list that contains the RPC’s that the hypothetical system in real life should adhere to. We decided however that those RPC’s are not applicable to the prototype that we are aiming to build. This week, Luka will define an additional list of RPC’s specific to the prototype. | • In week 2 a list of general RPC’s was made; that is, a list that contains the RPC’s that the hypothetical system in real life should adhere to. We decided however that those RPC’s are not applicable to the prototype that we are aiming to build. This week, Luka will define an additional list of RPC’s specific to the prototype. | ||
Revision as of 11:18, 22 September 2017
Members of group 3 | |
Karlijn van Rijen | 0956798 |
Gijs Derks | 0940505 |
Tjacco Koskamp | 0905569 |
Luka Smeets | 0934530 |
Jeroen Hagman | 0917201 |
Introduction
The technology of robotics is an unavoidable rapidly evolving technology which could bring lots of improvements for the modern world as we know it nowadays. The challenge is however to invest in the kind of robotics that will make its investments worthwhile instead of investing in a research that will never be able to pay its investments back. In this report we are going to investigate into a robotics technology that we think is worthwhile looking into. In this chapter it will be explained what the societal issue is that we want to tackle, what we want to achieve for this issue and how we plan on achieving this.
Problem Definition
When you travel by train on a regular basis you might have noticed that when people in a wheelchair need to exit or entry the train it goes rather slow. Before they can get on or off the train the train personnel is needed first to get some sort of ramp to make the disabled people able to board or deboard the train. When someone in a wheelchair is on board or wants to go on board of the train the train might even be delayed because of this. As we know trains in the Netherlands tend to be too late every time and therefore every obstacle that is getting in the way of letting them ride on time, should be taken care of. The wheelchair problem is definetely one of them. Imagine you are in a wheelchair and want to board the train. First you have to look for someone of the staff to ask if they can help you board the train. Someone of the staff will then get the ramp and help you board the train when it has arrived. When you have reached your destination and you want to exit the train again someone of the staff at the trainstation has to get the ramp and help you deboard the train. As you can see it is a lot more difficult for people with a handicap to be able to easily travel by train. Every time they want to travel by train they are dependent of other people. The feeling of constantly being dependent on others is for most people the worst part of living with a handicap. Because of this dependency the threshold for these people to travel by train is much higher. When they stop using the train it might have an impact on their social being which might cause loneliness and even depression. We as group 3 want to improve the service at trainstations for disabled people by using the technology of robotics.
Objective
As already mentioned in the problem definition it is our goal to improve the assistance for disabled people at train stations. In order to achieve this goal we need to specify what is actually meant by improve. To see what the best eventual goal would be the wishes of the users need to be considered. The primary users are of course the disabled people, however the indirect user, which is the train staff, also has their own wishes. To be able to know what the users want their opinion is needed, which will be discussed under the USE chapter. Here our view of the ideal solution will be explained. As explained before the dependency on others is one of the main problems and therefore it would be best if everyone could board the train all by their self without the help of any staff. Another problem was the time it takes to board the train and therefore we want a solution that is as fast as possible but of course also entirely safe to use. Another important part are the manufacturing costs, which of course are preferred to be low. Also the product should be easy to use and not wear off too quickly since reparation costs will be high on a robotic system.
Approach
The approach for the project will be discussed in this section. First of all the users wishes should be the main design criteria. To find out what the wishes of the users are there 2 questionnaires will be made, one for the disabled people and one for the train staff. The results of these questionnaires will be used for a thematic analysis. From the conceptual designs the one that fits the wishes of the users best and is the best solution according to the other design criteria will be chosen. After the best conceptual design is chosen a literature research will be executed about the options of the design. When the literature research is completed a prototype will be designed which will represent the final solution of the project. With the prototype it can be seen what things of the design should be adapted to improve the design.
To make sure that the project will be finished in time milestones have been made which show what we want to finish in every week from now on. The list of milestones can be seen in the planning.
USE
To get a better view of the design criteria the design should comply to, the USE aspect of the problem statement and the objective will be considered in this section. The USE aspect consists of the User part, the Society part and the Enterprise part. The USE aspect helps to get a clearer understanding of who is going to use the product and who will benefit or be disadvantaged by the product. Then one can also determine what the wishes are for the product for every different group. To get an even better view of the wishes of the users a questionnaire will be made which is also shown in this section.
For this project two types of questionnaires were created for two different target groups: NS staff and disabled people. The questionnaires were created for several reasons:
• To gain insight into the current situation with regard to traveling by train when being disabled. How does the current system work? How do people experience the current system?
• In order to finetune our RPC’s for the robot, the aim is to gain insight in the wants and needs of the actual users: NS staff and disabled people. What do they believe is necessary in order for the system to work efficiently? What do they miss in the current situation?
• To improve the system for all its users, not necessarily only disabled people. Therefore we are also curious to know how operating NS staff experiences the system? What can be improved for them to improve their work efficiency and pleasure?
To find participants for this study, several steps were taken: a call on Facebook was posted for the target groups, personal networks we contacted and NS staff on the stations was approached. The questionnaires could be filled in online, or on paper.
We aimed to get 5 participants for the disabled target group, and 2 to 3 for the NS staff. These amounts are based on what is reasonable for the scope of this project; due to time constraints it is not an option to find large groups of participants. The questionnaires were written in Dutch.
User aspect
The user aspect of our product is of course going to be the disabled people who actually use the robot. To get a better understanding of their needs a questionnaire will be held which focusses on the way they are helped right now and what the advantages/disadvantages of the current state. Also their feeling of being helped by a robot in the future is an important part and in what way they would prefer to be helped.
Questionnaire
The questionnaire was designed to get insight into several aspects of the project.
The first two questions explore the current situation:
1. How often do you travel by train?
2. How much time does it take you to plan your train journey?
After this, several questions test the subjective experience of the current situation?
3. How do you experience the current NS travel assistance service?
4. What do you think could be improved in the current situation?
5. Are you capable of getting on to the ramp without help?
6. Do you experience difficulties in planning your train journey with regard to the NS travel assistance service?
7. How much time do you generally need when changing trains?
8. How do you experience travelling by train from 1 to 10, with 1 not pleasant and 10 very pleasant
9. Can you clarify your answer for question 8?
After this set of questions, the new concept is introduced and tested:
10. For this project, we aim to develop an automated system that functions as a ramp. By pressing a button on the platform, the robot will drive towards the train entrance and fold out to form a ramp. What would you think, of being aided with entering the train by a robot or automated system?
11. What are important aspect of good service for you?
12. What type of help with boarding the train would you appreciate most? (For example: ramp, lift, etc.)
In the final question we leave space for the participant to write down remarks or tips:
13. Do you have any tips or remarks with regard to the current or new system?
Society aspect
The society part of our project are the other train passengers, they should not be disadvantaged by the new wheelchair assistant. This should be considered to see if the new design has an impact on the other passengers.
Enterprise aspect
The enterprise part is in our case the NS, of course they are the ones that eventually need to pay for the research and manufacturing of the robot. Therefore the enterprise aspect is just as important as the user aspect. To get a better view of what the NS thinks of our idea again a questionnaire is made. In this questionnaire the view of the train personnel is asked regarding the current assistance and what they think that could/should be improved. Also their view on the idea of a robot helping the disabled people is important.
Questionnaire
This questionnaire focuses more on the specific experience of NS staff working with the system and how it could be improved in their view.
The first questions explore the current situation:
1. What is your specific function at the NS?
2. How often do you help disabled people boarding or leaving the train? (1x per week, 1x per month, 1x per year, etc.)
3. In what way do you help disabled people boarding and leaving the train?
The next set of questions explores the subjective experience with the current system.
4. What are the advantages of the current system?
5. What are the disadvantages of the current system?
6. How would you rate the system with regard to NS travel assistance from 1 to 10, with 1 very negative and 10 very positive?
7. What could be improved in the current situation, to make your working experience more pleasant?
The next questions introduce the new concept.
8. For this project, we aim to develop an automated system that functions as a ramp. By pressing a button on the platform, the robot will drive towards the train entrance and fold out to form a ramp. What is your first reaction to a system like this?
9. How do you experience the current time needed to help a disabled person board or leave the train? Too long/too short?
The final question leave room for the participants to write down any thoughts on the topic:
10. Do you have any tips or remarks with regard to the current or new system?
Process description
State of the art
In the following section you will be guided through the current process of boarding a train when you are disabled.
First, you have to contact the NS to apply for NS travel assistance. This can be done in two ways: by telephone or online. In case you want to do it online, you have to one-time register with NS, after which you should plan your trip. Then, you can ask for travel assistance. By telephone you simply have to pass on your trip as planned, after which the NS can provide travel assistance. In both cases the disabled person has to contact the NS at least one hour before travelling. You cannot travel anywhere if you are disabled; travel assistance is only possible at about 100 of the 400 train stations in the Netherlands.
After applying, you have to be at a pre-set meeting point at least 15 minutes before your train departs. The travel assistant will then take you to the right platform and help you enter the train. This happens as follows: the travel assistant, often with another NS employee, takes the ramp (which is on wheels) and rolls it towards the desirable train entrance. Then, they fold out the ramp and align it correctly with the train’s height. This happens after all other passengers have entered the train, ideally at a train entrance where there is plenty of room for the disabled person to stay during the trip. After docking the ramp, the disabled person either drives up the ramp himself or the NS travel assistant helps. As soon as the person is inside the train, the NS staff begins to fold up the ramp again and they bring it back to the original position on the platform.
The NS then contacts other staff at the destination station and pass on in which train compartment the disabled person is. Then, they can take the ramp again and simply have to wait for the person to arrive. As soon as the train arrives, they help the person leave the train in a similar way as they help them with boarding. Often, the NS travel assistant helps the person during the entire process, which means he will only stop helping as soon as the person is off the platform and ready to continue its journey in the city of destination.
Idealized solution
The idealized solution has to fulfill every requirement, preference and constraint. The biggest goal is that disabled people are able to travel all by them self. This means that they can reach the platform and use the automated assistance system to exit and enter the train without any staff being involved. When someone arrives at a train station the first thing they need to do is to get to the right platform with the use of the elevators that are already present at every station. A pole to check in with the OV-card will be located next to the elevator. The people that need assistance when entering or exiting the train have a special OV-card which can be used at the check in pole to activate the automated assistance. When the train arrives the robot will then locate itself at a door of the train. The person can then enter the robot which helps them entering the train. When someone has reached his destination the robot should, in some way, already be stationed at the door where the person wants to exit the train. During the movement of the robot the robot should always pick the shortest but also the safest path to the door. With safest is meant that the robot should never hit any obstacles or any passengers. To realize this the robot needs to be aware of its own position and the position of obstacles and people. The robot should also be able to constantly adapt its driving path to avoid moving obstacles as efficient as possible.
Conceptual Designs
In order to get to a right solution for our problemstatement conceptual designs need to be made. Five different conceptual designs where formed and on the basis of the RPC's and the analysis of the questionnaires, the best conceptual design will be chosen. To come to a preliminary design the best conceptual design is adapted to fullfill the requirements and preferences of the users even more. In this section the list of RPC's will be given together with five conceptual designs and at last the preliminary design.
Literature research
Most railway companies in other European countries are bound by law to accomodate disabled people onto their train. Trains like the Eurostar have dedicated spaces inside trains in the 1st class cars, and allow for an additional passenger to come with the wheelchair bound customer. Most railways companies work like the NS system, you have to plan your trip ahead of time (online or through customer service) so the railway employees can help you along your trip. However, not all trips are allowed because railway companies like Deutsche Bahn have a specific time that they need to make sure you can transfer between trains, thus some passengers have to wait for the next train because a 10 minute transfer between trains is not possible. Either ramps or mobile wheelchair elevators are used. These are stored on the platform and chained to a pole or wall and the railway employee will put this ramp in place for you. Then, when it’s connected to the train door the railway employee will push you on board or place you on the mobile wheelchair lift. When you are on the lift both sides are closed and the employee presses a button to align the height with the train door. Once it’s done lifting the front ramp will go down and you can ride on the train on your own. It’s also possible for trains to have a ramp inside the train floor that goes out when a button is pressed. Companies that use the wheelchair lift are: VIA Canada, TGV (France), SBB (Switzerland), Trenitalia (Italy),
RPC's
Requirements
- Completely safe to use for the disabled person but also completely safe to other passengers on the train.
- Able to use continuously, if not it will cause delay for the train or the person misses the train.
- Easy to use, disabled or elderly people have to be able to operate it.
- Completely autonomous, this means that the disabled person can enter and exit the train all by their self.
- The solution should not cause delay for other people who want to board the train.
- The solution should take care of faster boarding and deboarding than the current approach.
- The solution must be resistible to weather conditions and aging.
Preferences
- Let the person board and deboard as fast as possible.
- A solution that is as cheap as possible for both research costs and manufacturing costs.
- As comfortable as possible to user.
Constraints
- Solution has to fit for every different train, think about the width of the doors and the height of the entrance.
- Solution has to fit on the train station, possibly requires power and therefore needs some powersource.
Design 1
Design 1 involves an autonomous driving vehicle which can automatically drive to a certain location at the platform. The car only drives in a straight line parallel to the railway and therefore one robotic vehicle is needed per platform. The robot has wheels and an extendable shelf that can be attached to the train when the doors are opened. When someone wants to use the robot to board a train one simply walks up to the robot and pushes a button. The robot will be positioned at the end or front part of the platform depending on where the nearest elevator is located. When the train has arrived the robot will move to the door that is nearest to its location. This is either at the rear of the train or at the front (depending on which direction the train travels). The robot will be positioned using sensors in the doors to let it know where the doors are located exactly. When the doors are opened the robot will unfold its ramp and the person can board the training. By the use of a pressure sensor in the shelf the robot knows whether the person has entered the train. After the person has entered the train the robot will lift the shelf up again and then drives back to its original position. When the person inside the train wants to exit the train at a certain station the (not yet existing) extension of the NS app can be used. The app shares the information with the robot and the robot can know in advance that someone wants to exit the train. The robot can move in place when the train arrives (it can start moving when the door sensor is within its reach). When the doors open the shelf will be put in place again and the person can exit the train. When the person has left the shelf and is on the platform the robot will again lift the shelf and go back in its original position. To make sure the robot has enough power there will be a power station at the beginning position of the robot. The robot can attach to the power station and charge his batteries (same way as the lawnmower robot).
Design 2
Design 2 uses a crane to lift wheelchairs and moves them on or off the train. With this design there is no need for a car on the platform. There will be designated doors for people in wheelchairs where the crane positioned on the train. The crane has a lifting cable with four universal clamps which can be locked on the wheels of the wheelchair. The advantage of this concept is that it does not need anything on the platform which can cause obstructions for other persons. Getting off the train is just as easy as getting on. You will not have to worry if whether the crane is on the right platform at the right door and on the right time when you arrive, because the crane moves with you in the train. The disadvantage of this design is that you need to attach the clamps to the wheelchair yourself. It does not work autonomously. If you are incapable of operating it yourself, you still need someone to help you. The second disadvantage is that all the trains need to be adjusted, which takes a lot of time and will probably cost a lot of money.
Design 3
Design 3 is in many ways similar to the current ramp that is being used at NS stations. It involves two ramps that are folded upwards, and when one wants to use the ramp both sides flip down and level with the desirable height. At one side of the ramp this equals the height of the entrance of the train, and on the other side this equals the height of the platform. In this way, a person in a wheelchair can simply drive upward or downward if one wants to enter or respectively leave the train. When the ramp is folded upward, a simple user interface could be installed. The screen would allow interaction between user and platform; the user could enter an ‘order’ after which the robot can perform its duty. The robot is driven by two large wheels, one on each side, which allow for easy rotation within the platform environment. The robot autonomously navigates in this environment. The robot is stationed at one single spot per platform, where it can recharge itself after serving. The ramp has raised edges, to avoid someone falling off of the ramp.
Design 4
This design will focus on the docking problem for an autonomous robot. The wheelchair boarding system, as mentioned, has three main stages. The alert, dock and board stage. In this design the vehicle will use wireless network and latency to triangulate the position. There will be beacons in the platform, this could also be in the docking station, but that is probably less accurate. The robot has two sender/receiver combinations. One on the front and one on the back. They will send signals to the beacons, the beacons resend them. With the latency information the robot will be able to triangulate its position and orientation. At the same time there is a send/receive combination module under the stair of the train. This will also ping the beacons. The beacons then again triangulate the position and send this information to the robot. So at this moment the robot knows where it is and there is also a goal. In order to move to the goal, there are at least three things required:
Solutions
- The motion is to be planned within the kinematic constraints of the robot. A Quintic polynomial could be used to control start values of position, velocity and acceleration. The problem is that the robot is constrained in it's movement. So the orientation matters. We could describe the path as a series of robotic links, making constraints between the links. In a way the robot can always go from one to another.
- The motion should be tracked by suppressing disturbances. This could be done using the kinematic equations of motion represented in a state space.
- It has to move around obstacles, human and inhuman. This could be done by planning a path around it. Proximity sensors make a map of the nearest obstacles. Just a thought on this problems allows to fantasize a solution where the controller tracks the path, but starts deviating from the path as the sensors pick up obstacles. So instead of thriving for zero error, the error could increase with sensor input. The human obstacles are mobile, which means that they could move aside if urged to.
The solutions posed for the problems are made up using current knowledge. In order to find smart solutions, we might look into "Truck Docking". This is investigated by truck companies and shows a similar problem.
Design 5
Design 5 is an autonomous mobile lifting robot on four wheels that will help the disabled person board the train without any assistance from railway employees. The robot is stationed at a charging hub on each platform and has to be activated through the NS app and physical interaction with the OV-chipcard. Once the trip is planned and you "log in" on the robot with your chipcard, the robot will move itself to where the train will stop, ideally already aligned with a train door. Then, the train arrives and the robot will autonomously align itself with the door and open the back gate so the disabled can ride into the lifting platform. Then, the backdoor closes for safety and the person is lifted. When at the right height, the front door is brought down so the wheelchair can move over it into the train. When the person has left the robot, it should detect this and return to its original position and then move back to the charging hub as soon as possible so other passenger can use the door. This design will be connected to wifi to get the trip information from the NS app and accurate train arrival times. In order to be ready to dock to the train when it arrives, the disabled person has to activate the robot to move to the correct position 5-10 minutes before arrival of the train. It will have to avoid passengers and bags on the ground on its own, but ideally this problem is limited by either introducing a "wheelchair robot path" on the ground so people know where to avoid placing bags or it has sensors in front that enable it to manouvre around these objects. Because it has accurate trip information through the NS app the robot will know train arrivals in which a wheelchair is, so it needs to be ready to help this person get out of the train completely on its on, without any physical "log in" with the ns app.
Preliminary design
The Preliminary design is basically a combination of design 1 and ….. The design will be a autonomously driving vehicle that can be placed at each platform. The vehicle has 4 wheels and uses a horizontal plate that can be lifted up and down to be able to reach the right height to enter the train. It will only be able to drive in a straight line parallel to the train rails. It will be placed at one end of the platform which we will call its homing position. At his homing position a power station will be placed. The robot will always come back to the homing position and attach itself to the power station. The robot has to be equipped with different kind of sensor. For example the robot should be able to sense obstacles in its drive path. When the robot senses something is in its way it should stop and give some kind of signal to let it surroundings know that something is blocking the robot. Another design challenge is to find out how the robot can locate a door where the person can enter or exit the train. The first idea for a solution to this is to equip every train with a sensor at the very first and last door of the train these doors will then be used as an entrance for disabled people. An advantage of this solution is that the robot can always choose the door which is nearest to its homing position and therefore less people will walk in its driveway and the time to arrive at the door will be short.
Patent Check
There are no existing patents regarding the basic idea of autonomous train assistance.
Proof of concept
As can be read in the literature research part the idea to lift the a plate in order to enter the train is already used in some countries. However this principle is then used in the way the ramp is used in the Netherlands. The plate still has to be controlled by the train staff and therefore the disabled people can still not enter and exit a train all by their self. To be able to proof that our idea could work in real life a prototype is going to be build. Since it would be too extensive to build the entire robot the focus will be on determining how to reach a certain location. The lifting of the plate is already proven to work since it is already used. The last part of our idea that needs to be proven is how you can activate the robot and how to let it know which position it has to reach. This also applies when someone wants to exit the train, how does the robot locate the position of the person that wants to get off board? To solve these problems a literature research will be executed together with some brainstorming. To prove that the robot will actually be able to reach a certain position the prototype has some requirements, preferences and constraints.
RPC's prototype
Requirements
- Drive in a straight line and be able to correct its movement.
- Drive by one press of a button to a desired location, robot needs to find the right location and be able to reach it.
- Avoid hitting obstacles, therefore the robot needs to be able to sense objects in its surrounding that are at least within 1 meter of its own position. When an obstacle is too close the robot has to stop and let its surroundings know that something is blocking its path.
Preferences
- Not only drive in a straight line but determine a path and be able to make turns.
- Reach the desired location as fast as possible, without risking to hit an obstacle.
- Be able to sense an object in its surrounding and in case the object is in his pathway be able to alter its path to navigate around it.
- The prototype should be as cheap as possible.
Constraints
- Drive alongside the railway without falling of the platform.
- The prototype cannot cost more than €150,-
Prototype research
Motion Planning
Literature
In order to plan a path for the mobile robot to the train door there are some things to take into account. We started looking for papers about trajectory planning for mobile robots with kinematic constraints. Therefore we started searching for some interesting articles on the topic. several search terms were used (path planning, kinematic constraints, mobile robot, real-time path evaluation). path planning with kinematic constraints real-time path evaluation mobile robot
1. Real-time randomized path planning for robot navigation J Bruce, M Veloso - Intelligent Robots and Systems, 2002. IEEE …, 2002 - ieeexplore.ieee.org ... A higher value of this gain value (beta) results in shorter paths from the root to the leaves ... Several important lessons can be drawn from this work in the context of real-time path planning: ... for the extend operator may perform better than a more correct model when planning time is ... Geciteerd door 482 Verwante artikelen
2. Mobile robot trajectory planning with dynamic and kinematic constraints V Munoz, A Ollero, M Prado… - Robotics and Automation, …, 1994 - ieeexplore.ieee.org ... planner, a local path planner, and a path tracker to execute the planned paths [9]. The ... paper proposes a solution based on the combination of a simple local path planning algorithm, an ... according to the kinematic and dynamic constraints of the vehicle and the path's features. ... Geciteerd door 62 Verwante artikelen
3. New potential functions for mobile robot path planning SS Ge, YJ Cui - IEEE Transactions on robotics and automation, 2000 - ieeexplore.ieee.org ... X. Yun, and V. Kumar, “Control of mechanical systems with rolling constraints: Application to ... for publication by Associate Editor J. Ponce and Editor V. Lumelsky upon evaluation of the ... To overcome this problem, the repulsive potential functions for path planning are modified by ... Geciteerd door 794 Verwante artikelen
4. Guidelines in nonholonomic motion planning for mobile robots JP Laumond, S Sekhavat, F Lamiraux - Robot motion planning and control, 1998 - Springer ... Guidelines in Nonhotonomic Motion Planning for Mobile Robots 15 in an iterated algorithm that produces a path ending as close to the goal as wanted. ... These results are critical to evaluate the combinatorial complexity of the approximation of holonomic paths by a sequence of ... Geciteerd door 919 Verwante artikelen
5. A fuzzy-logic-based approach for mobile robot path tracking G Antonelli, S Chiaverini, G Fusco - IEEE Transactions on Fuzzy …, 2007 - researchgate.net ... To guarantee that the vehicle tracks the desired paths without exceeding the limits, the proposed approach uses the fuzzyfication module to slow ... [26] ——, “Experiments of fuzzy real-time path planning for unicycle-like mobile robots under kinematic constraints,” in Proc. ... Geciteerd door 172 Verwante artikelen
6. Dynamic path modification for car-like nonholonomic mobile robots M Khatib, H Jaouni, R Chatila… - Robotics and …, 1997 - ieeexplore.ieee.org ... [3] BH Krogh and CE Thorpe. Integrated path plan- ning and dynamic steering control for autonomous vehicles. In Proc. ... [8] S. Quinlan and 0. Khatib. Elastic bands: connect- ing path planning and control. ... Optimal paths for a car that goes both forwards and backwards. ... Geciteerd door 169 Verwante artikelen
So searching only gives us a lot more leads.... Sprunk2008 states that "Motion planning for wheeled mobile robots (WMR) in controlled environments is considered a solved problem. Typical solutions are path planning on a 2D grid and reactive collision avoidance."
Solution
It is difficult to plan a path, without a world view, because the environment is continuously changing (e.g. walking people). In order to be able build and program a working intelligent prototype for this problem, advanced programming skills are needed. The framework to sense and construct a world view is beyond the scope of this project. To still achieve our goal, we used our basic knowledge of programming to construct a state based algorithm. The algorithms main objective is to reach its goal. When the robots sensors sense an obstacle, it switches state to avoid collision and maneuver around it. The code is shown below:
%This is a function that finds the goal using position and orientation while pos ~= goal_pos % We want to loop until we reach the goal position % The first loop makes the robot move towards the goal as long as there % is no obstacle in it's way while S_F == Empty th_R = %ask angular position Robot th_G = %ask th_goal e = th_G - th_R T1 = -e*C1; T2 = e*C1; if e <= pi/32 T1 = T1 + C2 T2 = T2 + C2 end end S_G = S_F % the sensor that is looking at the goal is the sensor on front % Then the robot turns until the front is clear and drives on until the % way towards the goal is clear. while S_G ~= empty % update the sensor that looks towards the goal if dth =< pi/4 && dth > 7*pi/4 S_G = S_F elseif dth =< 3*pi/4 && dth > pi/4 S_G = S_L elseif dth =< 5*pi/4 && dth > 3*pi/4 S_G = S_B elseif dth =< 7*pi/4 && dth > 5*pi/4 S_G = S_R end dth = 0 th_R = %ask angular position robot % Turn until the front of the robot has clearance if S_F ~= empty dth = dth - pi/32 pause e = th_G - th_R + dth T1 = -e*C1 T2 = e*C1 else % move forwards if the front has clearance e = th_G - th_R + dth T1 = -e*C1 T2 = e*C1 if e <= pi/32 % keep the direction otherwise don't go forward this is to keep the vehicle safer T1 = T1 + C2 T2 = T2 + C2 end end end % This loops until the goal is reached so it will go back to the top % and start moving towards the goal end % Upon reaching the goal only the rotation matters and it is always the % same. So the goal orientation get's redefined and the robot starts % turning using a feedback loop. th_G = pi/2 while e > pi/180 %% 1 degree equals 1.6cm th_R = %ask angular position Robot e = th_G - th_R T1 = -e*C1 T2 = e*C1 end
% We still have some questions for which we need some help. % Q how to make the controller C1 for angular positioning % Q how to make the controller C2 for velocity control % Q what are the dynamics of the robot and motor. % Q is it possible to do these complex loops in an Arduino
The code represents a possible start of a simulated implementation in Matlab. The robot will facilitate an Arduino, hence the algorithm will change form, and it is interesting to already mention some of Arduino statements that could be used. So, instead of all these while loops the Arduino will run several states. A switch within a while loop will choose the state for each iteration. Inside the states certain conditions change the state variable, which the switch will detect. Furthermore, presently a lot of repetitive code is used. Especially for going forward en turning. This will ideally become separate functions that are requested. We are planning on making a more comprehensive code in order to make it clearer.
Position and Orientation Determination
In the algorithm that enables the robot to find the goal, there are positions and orientation's requested. This section will elaborate on the triangulation of positions and orientations. To triangulate the position there are three beacons required [math]\displaystyle{ (A, B, C) }[/math]. These beacons have positions [math]\displaystyle{ [A, B, C] = [(0,0), (0,B), (C,0) }[/math] in which [math]\displaystyle{ B }[/math] & [math]\displaystyle{ B }[/math] are constant values since the beacons do not move. Next we calculate the distance to all the beacons from the sender/receiver on the robot. We use the timestamp -[math]\displaystyle{ t_{X,i} }[/math]- and the speed of the signal - now assumed to be light speed - [math]\displaystyle{ C }[/math]. The [math]\displaystyle{ i }[/math] refers to the sender receiver node to which the distance applies. In other words the [math]\displaystyle{ i }[/math] refers to the corresponding coordinate system.
[math]\displaystyle{ r_{X,i} = (t_{X,i} \cdot C)^2 }[/math] with [math]\displaystyle{ X \in [A, B, C] }[/math]
These distances and the rule of cosines are used to calculate the x and y position:
[math]\displaystyle{ Y_i = \frac{B^2 + r_{A,i}^2 - r_{B,i}^2}{2B} }[/math]
[math]\displaystyle{ X_i = \frac{C^2 + r_{A,i}^2 - r_{C,i}^2}{2C} }[/math]
The angle is calculated using the two positions on the robot
[math]\displaystyle{ \theta = Atan(\frac{Y_2 - Y_1}{X_2 - Y_1}) }[/math]
One of the main uncertainties up until now is the determination of the distance towards the beacons. That still needs some further research.
Collaboration process
In this section we will discuss the team process and how the team collaborates. Every week a short update is given on what was done during the week and what was discussed in meetings.
4 September
This day our team was formed. We immediately established each other’s strengths, depending on our background. We discussed some ideas and concluded our main idea would revolve around the train environment. Throughout the week, we communicated who would take on what role in terms of the presentation of 11-9. On Wednesday, part of the group met up again to further refine the main concept. It was then decided we would focus on the boarding of a train by disabled people. Karlijn started working on the presentation, and wrote about the subject, objectives, users and approach. Luka maintained the wiki, while Gijs created an elaborate planning by means of a Gantt chart. Tjacco defined the milestones and deliverables. Throughout the week, a new group member, Jeroen, joined. He started creating the questionnaires we are going to use further in this project. On Sunday, we defined the group roles for the coming few weeks: Luka will maintain the wiki in terms of design process and help with the prototype, Karlijn will do qualitative research on the user requirements by means of the questionnaires and maintain the wiki in terms of collaboration process, Jeroen will do literature research on the state-of-the-art in the field, and Tjacco and Gijs will work on the prototype.
11 September
This day we presented our idea. We received some substantive feedback which we immediately incorporated in the planning: this week we will clearly define the RPC’s, after which we will all create a concept. Moreover, we finish all questionnaires, which enables us to start distributing the questionnaires from Tuesday. On Wednesday we meet again to compare the concepts, and refine our idea. We also received feedback saying we should be clear about the scope of the boarding process we would focus on. Due to that, Gijs started working on a block diagram which would map the entire process from start to finish, to gain clarity. We decided we wanted to focus on every part of the process. Jeroen will in this week start doing literature research, to gain insight in the current situation at the NS. All team members are very involved in the process and all work is divided among the group. Clear deadlines are set and processed in the planning.
18 September
In the section above you can read about the plans that were made for week 2. In the following section, the results of that week will be described we will pinpoint the following steps.
• In week 2 a list of general RPC’s was made; that is, a list that contains the RPC’s that the hypothetical system in real life should adhere to. We decided however that those RPC’s are not applicable to the prototype that we are aiming to build. This week, Luka will define an additional list of RPC’s specific to the prototype.
• On Wednesday, the team met up, and after discussing the concepts we concluded our idea would be largely based on Jeroen’s concept: a lift.
• In addition to the block diagram that Gijs made, the scope of this project will be further defined this week. Moreover, we have picked a specific part of the boarding process that we will focus on, namely, the docking of the robot near the train. This will be further described by Luka. Moreover, Luka will describe the ideal process. Karlijn will describe the process as is.
• Last week, Jeroen has indeed started doing literature research and found out that Canada and France already use the lift system that we have come up with. It does not however autonomously navigate. This Monday, we discussed this in a meeting with the teachers, and came to the conclusion that this is positive: since the lifting part of the system already exists, we can focus on the docking. Moreover, the existing systems can serve as an inspiration and can be a starting point from whereon to start developing our system.
• Karlijn and Tjacco finalized the questionnaires, after which Karlijn started handing out the questionnaires at NS stations. Moreover, questionnaires were distributed via personal networks and Facebook. This has however not yielded as many response as we had hoped for. Because of this, we have decided to extend the deadline one week and we will start collecting all answers and interpreting the data in week 3.
• This week, Gijs and Tjacco will do further research on motion planning, motion tracking and obstacle avoidance.
• This week, Jeroen will focus perform more practical work; besides finishing his literature research he will inform at the Innovation Space what options there are with regard to material and Arduinos and he will update the planning.
• This Monday, when meeting with the teachers, multiple conclusions were drawn with regard to the team. We openly discussed the collaboration to this day. Karlijn, and other team members, missed a leading figure within the group that has an overview of what everybody is doing during the week and if everybody is meeting their deadlines. Therefore, from now on, every week another group member will be that week’s group leader. He or she will check during the week if all is going as planned, and if everybody can finish his or her work before Sunday afternoon. This week Karlijn is group leader. Moreover, we missed clear deadlines last week and a large part of the group only started working on Sunday. This week, the entire group is therefore expected to finish his/her part before Friday. Friday, we will meet to discuss our work and define some final tasks that can be finished in the weekend. This will allow wiki maintainer Luka to upload all sections before Sunday.