The question is simple and direct.Please help.
I am working on bus ETA projects where all the datum i get are:
1.Real time GPS locations from bus
2.Distance between each stop
Do we need more data than these?
My Big question is:
How to make use of these data to calculate the ETA for customer?
My thoughts:
ETA is all about distance/speed,
so at first: I tried to simply get distance from 2 GPS coordinates to calculate
speed and use stop's distance to calculate ETA.
i.e.
while(true){
ETA = stopDis/2ptSpeed;
stopDis = stopDis - 2ptDis;
}
and upDATE next stop when stopDis<0
However, the problem is that the GPS datum will jump quite wildly and hence the
speed calculated is really messy.
Broken downed Question: How to smooth the GPS datum? Kalman Filter? Averaging?
Have heard of those but does not really know what to do ESPECIALLY Kalman filter!
Because of traffic and not-straight lines, distances and speed alone are not reliable indicators.
I think that your best bet is to use the history of the line to compare the current distance with the average distance at that time in the line, and to deduce a deviation from the average ETA.
I don't think it's that simple. What if there are lots of traffic lights between 2 stops or different speed limits.
And you have the gps coordinates so you can calculate distance, but that isn't the distance over the road. So you need to have someway to get the real distance the bus needs to travel (Perhaps the google maps api can help).
So to answer the "Do we need more data than these?" question: yes, i think you do.
Just an idea: The bus schedule already contains info about how much time is needed between stops on average. If you can just read from the GPS position if the bus is on a stop or between two stops you should be able to make a fairly accurate prediction.
I'm guessing you are talking about busses in a city, where GPS signals are weak and bus stops are not far apart.
Edit: This could be further improved with data about current traffic.
Collect travel time data from stop to stop on a continuous basis. Derive an expected travel time between stops from this historical data to use as a baseline. this can be continuously updated. Initial ETA at a stop is time of last stop plus most recent travel time average. If you have continuous GPS data, you can adjust in real time from that.
Related
How to stabilize the RSSI (Received Signal Strength Indicator) of low energy Bluetooth beacons (BLE) for more accurate distance calculation?
We are trying to develop an indoor navigation system and came across this problem where the RSSI is fluctuating so much that, the distance estimation is nowhere near the correct value. We tried using an advance average calculator but to no use,
The device is constantly getting RSSI values, how to filter them, how to get the mean value, I am completely lost, please help.
Can anyone suggest any npm library or point in the right direction, I have been searching for many days but have not gotten anywhere.
FRONT END: ReactNative BACKEND: NODEJS
In addition to the answer of #davidgyoung, we would like to point out that any filtering method is a compromise between quality of noise level reduction and the time-lag introduced by this filtration (depending on the characteristic filtering time you use in your method). As was pointed by #davidgyoung, if you take characteristic filtering period T you will get an average time-lag of about T/2.
Thus, I think the best approach to solve your problem is not to try to find the best filtering method but to make changes on the transmitter’s end itself.
First you can increase the number of signals, transmitter per second (most of the modern beacon allow to do so by using manufacturer applications and API).
Secondly, you can increase beacon's power (which is also usually one of the beacon’s settings), which usually reduces signal-to-noise ratio.
Finally, you can compare beacons from different vendors. At Navigine company we experimented and tested lots of different beacons from multiple manufacturers, and it appears that signal-to-noise ratio can significantly vary among existing manufacturers. From our side, we recommend taking a look at kontakt.io beacons (https://kontakt.io/) as an one of the recognized leaders with 5+ years experience in the area.
It is unlikely that you will find a pre-built package that will do what you want as your needs are pretty specific. You will most likely have to wtite your own filtering code.
A key challenge is to decide the parameters of your filtering, as an indoor nav use case often is impacted by time lag. If you average RSSI over 30 seconds, for example, the output of your filter will effectively give you the RSSI of where a moving object was on average 15 seconds ago. This may be inappropriate for your use case if dealing with moving objects. Reducing the averaging interval to 5 seconds might help, but still introduces time lag while reducing smoothing of noise. A filter called an Auto-Regressive Moving Average Filter might be a good choice, but I only have an implementation in Java so you would need to translate to JavaScript.
Finally, do not expect a filter to solve all your problems. Even if you smooth out the noise on the RSSI you may find that the distance estimates are not accurate enough for your use case. Make sure you understand the limits of what is possible with this technology. I wrote a deep dive on this topic here.
Looks like Fabric is recalculating or correcting the count for one of my events (iOS app) 6-12h later. The updated count is always lower, 20-30% down.
Mike from Fabric here. Yes, this can happen either for a count upward or downward around UTC midnight each day.
We have two layers of processing - speed and batch - that allow us to collect data in real-time, while at the same time correcting any errors that happen during the collection of the data. What you're seeing happen is the correction of the speed data layer by the batch layer.
As a result of having less time to calculate speed layer information we use probabilistic algorithms which let us calculate this information in real-time, but a cost of reduced accuracy. For most apps, the correction is extremely small, but there are outliers.
I've build an embedded GPS tracker which logs coordinates to a database, and I'd like to analyse this data and extract travelled routes and idle moments from it.
The way I think it should work:
Order the coordinates by UTC timestamp, find coordinates close together, and mark them as a 'route start'. Proximity could be found by simply comparing decimals, as I think GPS can be considered linear at a scale of ~3m. This brings up the trouble of selecting the 'center' of the idling: due to GPS inaccuracy, these decimals may drift around a little, potentially over the threshold to be grouped with the first.
10:15 to 15:12 - Idle
15:12 to 16:38 - [coordinates]
16:38 to 17:43 - Idle
etc.
How can I group coordinates in this fashion, and what complexities am I overlooking?
The first thing I would do is work with some experimental data. Are you sure there isn't some distance D, where if someone moved more than D from their previous location it must be they are on the move?
Now, assuming that there isn't. Say that GPS precision is usually within a reasonable accuracy, say 10m, but sometimes you just get a point 100m away. What I would do is: as long as the user didn't move more than, say, 20m, calculate a centre for the "idle location" (just the average of the x and y values of all the coordinates). When the user moves beyond distance 20m from your centre, don't immediately assume they started moving. Instead, check the next (one or more) values; only if you see them several times in distance of more than 20m from the centre, infer they started moving.
I imagine this simple solution should be good enough for most applications, though it depends on what exactly the user is doing (how stable they are during idle time, how fast moving when they move), and the quality of the GPS data. I would start with something like that and see how it works. If it fails, I would analyse in what cases it fails and proceed from there.
We're building a GIS interface to display GPS track data, e.g. imagine the raw data set from a guy wandering around a neighborhood on a bike for an hour. A set of data like this with perhaps a new point recorded every 5 seconds, will be large and displaying it in a browser or a handheld device will be challenging. Also, displaying every single point is usually not necessary since a user can't visually resolve that much data anyway.
So for performance reasons we are looking for algorithms that are good at 'reducing' data like this so that the number of points being displayed is reduced significantly but in such a way that it doesn't risk data mis-interpretation. For example, if our fictional bike rider stops for a drink, we certainly don't want to draw 100 lat/lon points in a cluster around the 7-Eleven.
We are aware of clustering, which is good for when looking at a bunch of disconnected points, however what we need is something that applies to tracks as described above. Thanks.
A more scientific and perhaps more math heavy solution is to use the Ramer-Douglas-Peucker algorithm to generalize your path. I used it when I studied for my Master of Surveying so it's a proven thing. :-)
Giving your path and the minimum angle you can tolerate in your path, it simplifies the path by reducing the number of points.
Typically the best way of doing that is:
Determine the minimum number of screen pixels you want between GPS points displayed.
Determine the distance represented by each pixel in the current zoom level.
Multiply answer 1 by answer 2 to get the minimum distance between coordinates you want to display.
starting from the first coordinate in the journey path, read each next coordinate until you've reached the required minimum distance from the current point. Repeat.
I'm using GPS units and mobile computers to track individual pedestrians' travels. I'd like to in real time "clean" the incoming GPS signal to improve its accuracy. Also, after the fact, not necessarily in real time, I would like to "lock" individuals' GPS fixes to positions along a road network. Have any techniques, resources, algorithms, or existing software to suggest on either front?
A few things I am already considering in terms of signal cleaning:
- drop fixes for which num. of satellites = 0
- drop fixes for which speed is unnaturally high (say, 600 mph)
And in terms of "locking" to the street network (which I hear is called "map matching"):
- lock to the nearest network edge based on root mean squared error
- when fixes are far away from road network, highlight those points and allow user to use a GUI (OpenLayers in a Web browser, say) to drag, snap, and drop on to the road network
Thanks for your ideas!
I assume you want to "clean" your data to remove erroneous spikes caused by dodgy readings. This is a basic dsp process. There are several approaches you could take to this, it depends how clever you want it to be.
At a basic level yes, you can just look for really large figures, but what is a really large figure? Yeah 600mph is fast, but not if you're in concorde. Whilst you are looking for a value which is "out of the ordinary", you are effectively hard-coding "ordinary". A better approach is to examine past data to determine what "ordinary" is, and then look for deviations. You might want to consider calculating the variance of the data over a small local window and then see if the z-score of your current data is greater than some threshold, and if so, exclude it.
One note: you should use 3 as the minimum satellites, not 0. A GPS needs at least three sources to calculate a horizontal location. Every GPS I have used includes a status flag in the data stream; less than 3 satellites is reported as "bad" data in some way.
You should also consider "stationary" data. How will you handle the pedestrian standing still for some period of time? Perhaps waiting at a crosswalk or interacting with a street vendor?
Depending on what you plan to do with the data, you may need to supress those extra data points or average them into a single point or location.
You mention this is for pedestrian tracking, but you also mention a road network. Pedestrians can travel a lot of places where a car cannot, and, indeed, which probably are not going to be on any map you find of a "road network". Most road maps don't have things like walking paths in parks, hiking trails, and so forth. Don't assume that "off the road network" means the GPS isn't getting an accurate fix.
In addition to Andrew's comments, you may also want to consider interference factors such as multipath, and how they are affected in your incoming GPS data stream, e.g. HDOPs in the GSA line of NMEA0183. In my own GPS controller software, I allow user specified rejection criteria against a range of QA related parameters.
I also tend to work on a moving window principle in this regard, where you can consider rejecting data that represents a spike based on surrounding data in the same window.
Read the posfix to see if the signal is valid (somewhere in the $GPGGA sentence if you parse raw NMEA strings). If it's 0, ignore the message.
Besides that you could look at the combination of HDOP and the number of satellites if you really need to be sure that the signal is very accurate, but in normal situations that shouldn't be necessary.
Of course it doesn't hurt to do some sanity checks on GPS signals:
latitude between -90..90;
longitude between -180..180 (or E..W, N..S, 0..90 and 0..180 if you're reading raw NMEA strings);
speed between 0 and 255 (for normal cars);
distance to previous measurement matches (based on lat/lon) matches roughly with the indicated speed;
timedifference with system time not larger than x (unless the system clock cannot be trusted or relies on GPS synchronisation :-) );
To do map matching, you basically iterate through your road segments, and check which segment is the most likely for your current position, direction, speed and possibly previous gps measurements and matches.
If you're not doing a realtime application, or if a delay in feedback is acceptable, you can even look into the 'future' to see which segment is the most likely.
Doing all that properly is an art by itself, and this space here is too short to go into it deeply.
It's often difficult to decide with 100% confidence on which road segment somebody resides. For example, if there are 2 parallel roads that are equally close to the current position it's a matter of creative heuristics.