Download
1 / 23
230 likes | 307 Views
Industrial project (234313) Building Indoor Maps by Crowdsourcing Students: Mohammed Gara Michael Margolin Supervisors: Dan Vardi Constantine Elster. Project Objectives.
E N D
Industrial project (234313) Building Indoor Maps by Crowdsourcing Students: Mohammed Gara Michael Margolin Supervisors: Dan Vardi Constantine Elster
Project Objectives Today’s GPS technology allow calculating and producing accurate positioning and tracking of the movement path in open environments. On the other hand … Inside a building or any dense urban environment, GPS has communication problems and it can’t help. So, the goals of this project was to: • Create android application which turns standard cellular phone into an accurate pedestrian tracking device, based only on low accuracy inertial sensors such as present on most of the modern cellular phones. • Implement recording server for gathering positions data from multiple devices running the tracking application described above, and display the gathered information graphically.
Experiment results • The experiments were made on Samsung Nexus 4 device and consisted of different walk scenarios in intention to test the aspects of the algorithm and its accuracy. • The average distance from the real (known) path was calculated using the following algorithm: PointToBrokenLineDistance (p – point, L – set of line segments): • minDistance <- Infinity • For each segment s in L: • minDistance <- min(distance of p from s, minDistance) • PointToBrokenLineDistance <- minDistance PointsToProkenLineAverageDistance (P – set of points, L – set of line segments): • distanceSum <- 0 • For each point p in P: • distanceSum <- distanceSum + PointToBrokenLineDistance(p,L) • PointsToBrokenLineAverageDistance <- distanceSum / |P|
Right angles path test Test 5 Test 1 Test 4 Real Test 2 Test 3
Curved path test Test 5 Test 1 Test 4 Real Test 2 Test 3
How it works? • Most of the modern cellular phones have accelerometer, gyroscope and magnetometer sensors. For this reason we choose to use those three sensors in our implementation. • The naive implementation would be calculation of second degree integral on the accelerometer data in three axes, which theoretically should produce current position relatively to the starting point. • Because of the low accuracy of the sensors and the high accelerations when walkers foot hits the ground, such strategy produces totally wrong results. • In our implementation the position calculation is done by a cyclic iterative algorithm, which is divided into three components: • Step detection algorithm: uses accelerations data and signals step ending combined with its length estimation. • Direction calculation algorithm: uses magnetometer and gyroscope sensors in order to produce current direction. • Position calculation algorithm: uses the two previous algorithms and combines their calculations into an accurate relative to the starting point position. • The algorithm is executed on the device and constantly produces position updates based on the last known position, it’s state and current sensors’ reading.
Algorithm data flow Step Detection Algorithm Accelerations Sensors Data Position Algorithm Step Indications & Length Current Position Direction Installation Angles Direction Calculation Algorithm Sensor Errors Magnetometer & Gyroscope Data
Step detection algorithm • This algorithm is based on “Pedometer” application, developed on previous semester project, but it found to be too specific to be used as is: • This application has been written and tested on a single device and didn’t work as expected on our device (nexus 4) as a result of sensor differences – almost a half of the steps haven’t been detected. • It’s algorithm uses only current step acceleration data for step length calculation, so there is a difference in step length between right and left steps (this is negligible when walking in straight line, but has high influence on the results for our purposes). • Step detection is done by acceleration pattern identification on the vertical and horizontal axes (forward and up) using acceleration borders. • We found that installing the device on one side of the body creates bigger acceleration on this side’s leg step in comparison to the other leg step, so we change the borders dynamically and separately for even and odd steps (image on the next slide). • Step length is calculated using ((accelerationDiff)0.25)*K formula which is an approximation to 2*h / tan(a), when accelerationDiffis a moving average on the difference between the maximum and the minimum accelerations during the step.
Direction calculation algorithm • This algorithm’s goal is to produce accurate heading indication in different environments including those which have magnetic disturbances. • Combining between magnetometer and the gyroscope sensors in a way that avoids each sensor’s weaknesses and maximizing each sensor’s advantages, is a quite hard mission: • The magnetometer is easily affected by magnetic disturbances in the environment, but it’s error is local and it isn’t accumulated. • The gyroscope values can be integrated in order to receive angular change, but it is accurate only for short time as it’s error is accumulated. • The solution is to use the magnetometer data when it is “clean” enough and to calculate an integral on the gyroscope readings when there are too many magnetic disturbances. • The question is: How do we know if the magnetometer reading values represent the true earth magnetic field or maybe a local magnetic field (disturbance)?
Disturbance detection • One way to answer this question that we found, is to compare the measured magnetic field power (magnetic vector size) to the known earth’s magnetic field power. If the measured magnetic power is too strong or too weak, there are magnetic disturbances. • This is a quite good way to examine magnetic measurements, but there are still many scenarios on which this method won’t detect a disturbed magnetic field. For example, another field in the opposed direction with double power will show as correct. What else can we do? • Another constant (in time) magnetic property is the magnetic vector inertial pitch (the angle between this vector and the horizon), so we can calculate the difference in the pitch angle between the measured values and the correct (known) pitch. • We combined both methods into one single accurate method for detecting magnetic interferences in the received magnetic values.
Position calculation algorithm • Till now we have step ending indication, last step length and the current direction, so in order to calculate the change in position we need to decide which angle best describes the step direction. • The azimuth at the end of the step found to be the most accurate expression of the step direction: • Step direction is the azimuth of the vector connecting the leg behind to the leg in front when they both on the ground, this is the direction when a leg strikes the ground. • Angular average has also been tried, and was less accurate.
Position correction • We already seen that the magnetometer accuracy can suffer from various local magnetic fields and in that case was decided to use gyroscope data instead. • The weakness of the direction calculation using gyroscope, is that it doesn’t rely on any absolute data, so its error tend to accumulate. • When the user exits the magnetic interference area, there will be some error in the calculated heading, that can be found by the difference between the integrated (gyroscope) angle and the real (magnetic) angle. We will call it θ. • Indeed the direction calculation algorithm corrects it’s calculation and from now on it will return the true direction, but assuming gyroscope linear error accumulation, there is already an error in the position. • We proposed a method of correcting this possible position error on the run, at the point of it’s detection.
Calibration • Calibration of the sensors need to be done to ensure accurate results: • There is a constant error in the acceleration sensors. • We need to know the parameters of the real earth’s magnetic field in the area in order to decide when there is an error in the measurements. • Android OS performs hard iron calibration (inner magnetic fields) for the magnetometer sensor on the flight. The device should be rotated for a while in three axes to ensure correct results. • For the other parameters, we have created calibration mode on the application level.
System structure overview • The system is composed of multiple android devices running the Pedotracker application, sending position message to the recording server. • The position message contains the step counter, initial location and the current position relative to that location. • The communication between the devices and the server is made above TCP protocol. Recording server
Pedotracker Android application design ObjectFactory Activities Object Factory SensorSampler MainLogic RecordingServerCommDevice UCTracking UCCalibration PositionCalculationAlgorithm StepDetectionAlgorithm DirectionCalculationAlgorithm
Pedotracker Android application • The SensorSampler runs on the main thread and when is activated, waits for sensor updates and collects the provided data. Its purpose is to provide random access to the most recent sensors data. • The MainLogic runs on the logic thread with 50 Hz cycle, collects triggers from the user interface, executes the UCTracking and the UCCalibration cyclic logic and updates interface if needed. • UCTracking is responsible for the algorithm operation by supplying it with the needed data from all the various sources (preferences, calibration data and sensors data), calling its cycle logic and sending and/or saving its calculation results. • RecordingServerCommDevice is executed on the communication thread and responsible for the connection maintenance and for sending messages to the server.
Recording server design MultiServer ClientsCollector ConnectedClient TracksChart XYSeries XYSeries
Recording server • XYSeriesis a list of points that represents a track in two axes chart. • TracksChartis a track drawer which is synchronized with adding and removing points to the XYSeriesthat it works with. The TracksChartdraws multiple plots on one single chart. • The MultiServerruns on the main thread and when is activated, waits for new clients (Android device) which try to connect to the server, and builds new sockets for communicating with each one of them. Also the MultiServerholds the TracksChart. • The ConnectedClientrepresents one client (one Android device) and holds all the points (the full track) that the device visited in it’s XYSeries. Ateach new received point, the TracksChartis updated to show the changes in the main chart.
Summary • The purpose of this project was to study the feasibility of implementing an accurate tracking device based only on low accuracy inertial sensors such as present on most of the modern cellular phones. • It was shown that such implementation can be made and can have acceptable accuracy of the position calculation results. • Further development option is to add a third axis (height) to the position algorithm. This can be very useful addition to the application for its intended environment - indoor. • Possible derivatives of this project, can use the developed algorithm for tracking, mapping and navigation. • This project exposed us to new fields of knowledge and experience, from learning to develop for android platform and understanding its API levels, physics of forces and body rotations, algorithmic calculations and more. We are pleased and satisfied from the project and its results.
