I am working on a Vehicle tracking commercial application. We need to find an efficient way to publish location updates that does not consume too much data and battery. We initially experimented with fixed time interval updates but these turned out to be very data hungry. We now have moved to distance based updates, so electron publishes a location update every 200 meters or so. However, we still think it can be improved. We are now thinking about publishing updates whenever vehicle takes a turn, this way we can accurately trace complete route and updates would be minimal.
We planned to send a location update whenever vehicle turned more than 15 degrees in any direction. To implement this I calculate direction/unit vectors using readX(), readY() and readZ() and then take arcCosine of the dot product of previous and current direction vectors and in the end convert the result from radians to degrees. However, I am not getting consistent readings and I sometimes see huge jumps even when the device is sitting still on my desk. Can anyone suggest a better and reliable way to do this? @rickkas7 or @Dave
I would like to ask if the accelerometer embedded in Asset Tracker Shield is capable enough to be used for this purpose? Can we expect to get proper libraries for the Shield to use it in commercial projects? To be honest, the AssetTracker library is very useful but it still seems like it is good enough for hobbyist projects. Here are some really serious issues with the lib
there is no GPS coords filtering and we often get jumpy readings that disrupt the route trace by adding 1000s of miles to it only because there was one very off coordinate pair reported by the device.
Accelerometer, the readings are never stable, data has lot of noise in it.
gpsFix() return true but coords are way off and sometimes even 0.
GPS based speed values do not make any sense
There is a function in the library header named ‘getOrientation()’ with no implementation. I noticed the same in the original library from Ada Fruit for LIS3DH. So I think Asset Tracker Library is just a direct port of different sensor libraries that were written for individual sensors without any focus on making it a proper solution to support vehicle/asset tracking applications as a whole like the product name says. Asset Tracker shield is as good as the software that powers it. If the software is not stable enough to be used commercially then I don’t see much value in the product. Many off the shelf Tracking devices offer location updates by time, distance and orientation change. Some of these devices are almost 10 years old. I am pretty sure Asset Tracker Shield can do much better than these if only its library is good enough.
Are there any plans to release a more stable and better update to the library? Is something in works at Particle for it?
What I am going to do now is to add some filtering to GPS and accel data and see if I can use it reliably. I will report my findings here soon. At the moment I don’t have any idea how I would do that so any pointers would be much appreciated. Thanks
Yes I am aware of the market conditions. Particle provides lot of flexibility by allowing writing your own firmware to cater to specific applications requirements. Most of the popular Vehicle tracking hardware devices in the market come with their own firmwares. They usually have a configuration utility application to setup the device according to your own needs. This is enough for most of the applications in this domain but for any unique and not so common scenarios these devices are not suitable.
Secondly, most of these devices have been around for over a decade and use custom communication protocols and require custom infrastructure written from scratch for data ingestion and storage. Therefore, developing solutions using these device require lot of effort in setting up the right infrastructure with hosted server boxes and responsibility to manage this infrastructure on your own. Scalability is a major concern in these infrastructures as well as costs attached to make it resilient and robust. On the other hand modern devices complying with IOT standards make it so much easier to develop such solutions that take advantage of recent advancement in cloud computing and dedicated IOT cloud infrastructures. You don't need to worry about managing infrastructure and deal with scalability. It is all handled for you automatically so that you can concentrate on the core features of your solution.
As I said, other tracking devices allow you to configure location update schedule based on time, distance or steering angle.
Yes the device will be powered by vehicle (scooters). This is not as much of a concern. When the vehicle is parked and its engine not running, we need to run the device off of its own battery. This is where we can use sleep function.
Curious, why not add a cheap compass to the project? This would allow you to calculate direction fairly accurately. The method you are using will have trouble when the device is stationary.
Totally agree with you here. I was looking into using a gyro or a magnetometer. I guess magnetometers are much better for the job because gyros suffer from the same issues, the readings do not persist and you need to take readings over a time period and analyze to detect if vehicle has steered enough to publish a location event.
You could try pushing the GPS data to Ubidots via their direct UDP protocol which is best for the Electron to keep data usage down. They have built in GPS Google Maps and you can share the maps via simple iFrame code so you can embed it into your applications.
A compass would be a good idea, as well as an external GPS antenna if you can manage it, they make a huge difference. The accelerometer won’t give you direction, just acceleration. You can also use what’s often called a 9-DOF if you want to track an object’s movement / orientation / etc ( https://www.adafruit.com/products/2472 ), pairing that with a GPS would give you a ton of info.
It’s also a good idea to incorporate the quality value into your location, e.g. if your new coordinate is 1000 meters off the last one, but your accuracy / quality is reduced, draw a buffer around the new point, and use that, etc, etc. Or only use readings where the accuracy is under some limit, etc.
I work for automotive company and we are bumping into issues with tracking a target regularly. It is different than you are trying to achieve, we usually need quite high accuracy, but this stuff might inspire you some way. Long story short - it is trouble. Big trouble.
Compass / magnetometer - those things accuracy is not great. Especially near all the metal car is made of. Except regular errors in magnitude of 10 degrees. 20 if really unlucky.
Accelerometer + gyro is much better, but you can’t rely on accelerometer data holding the trajectory for too long. It diverts very soon, due to accumulation of error.
Since it is a scooter, you most likely don’t have access to vehicle CAN / OBD data. In cars, reading real speed and yaw rate (how fast vehicle rotates around Z axis) gives pretty good results (if you get compensated yaw rate, but it is even longer story). Not sure how much of this gets to OBD though, we usually connect directly to CAN, where we have everything. This is serious vehicle modification though and you would need a test vehicle license plates.
In your situation, I would rely on hybrid solution, ie. sending update if any of heading, distance or time changes.
If you want great tracking accuracy though - get whatever data you can get, most likely GPS and gyro + accelerometer (I would not bother with compass, but it may be of some use - it gives you absolute heading). Then run it through Kalman filter - this is where real magic starts. You need to tune weights of different signals (ie. gyro and accelerometer will be accurate in short intervals, while GPS may jump there, but in long time GPS is much more stable, same as compass is). Kalman filter kinda averages all incoming channels into more accurate value than any of sources (if weighted well).
And if you pull this off, it might be rather different product, but it might sell great. These things tend to be rather expensive.
Its not as much about how much data is sent per publish but how frequent. the objective is to send minimum possible publishes so that accurate route can be traced. Ubidots is good for quick prototyping but I dont think it is flexible enough to support full range of custom features like drawing polylines custom markers, animated route guidance clues etc. you cant even send map coordinates directly. you need to expose a variable and send these coords as context of that variable.
I am using Google cloud integration with Firebase to get realtime location data pushed to Android and web applications. Its very fast with very low latency and you can use native Google maps sdk to visualize location data on these platforms allowing you to add other advanced map features as well.
Thanks for the valuable tips. How can I get the quality parameter that you mentioned and what are good values to set for it when deciding if a position is good to keep
Sure thing! I’ve got an example app here that is pulling the fix quality:
What quality to use depends on how reliably you can get a good satellite fix, and what the Nyquist Rate of what you’re tracking is. For example if you’re moving at 60 mph (88 feet per second), and you want to update the map once a second, then you want to know you’re going to be within that 88 foot bubble of what you’re drawing on the map. I’m cheating a bit here, but a 30-40 foot fix would be a really strong fix, so settling for something like a few hundred feet is more reasonable. I’m abusing the concept of the Nyquist rate here, but I’m just trying to say sample more / have more accuracy then you need, or show users your accuracy and let them decide.
Most in-vehicle GPS systems lie about their fix and snap you to a nearby road to make them seem more accurate.
Thanks for the code example. I am using AssetTracker library and it exposes a function getGPSAccuracy that uses HDOP, whereas you are using ‘fixquality’. What is the difference between the two and I know about HDOP but what unit this ‘fixquality’ attribute represent? Is it an accuracy measure in terms of distance?
What you suggest sounds good but seems quite complex to achieve. I have looked at Kalman filters briefly and it is not a straight forward solution to implement. All I want is to detect if vehicle has steered in a direction above a threshold value and send location update. But let’s say if I decide to follow that route, when you say combine inputs from gyro, accelereometer and GPS. I understand that I can get x,y values from gyro and accel but what input do I need to include from GPS?
Yes it is not really needed for what you are doing. It is rather complex, I am also struggling to fully understand it. Primary message was you can’t rely on individual sensors very well and if you want to merge them for better accuracy, it is hard (but possible).
I would suggest using GPS as primary source for location data. And accelerometer with gyro to keep it in control when GPS gets confused. You can estimate next X, Y from accelerometr / gyro data, but the value doesn’t stay correct for long.
I found another very easy method for cleansing GPS data of inaccuracies. Google has introduced Roads API, what it basically does is that you provide it a list of location coordinates that represent a route and it returns a list that ‘sticks’ those pairs to nearby roads. I have seen some examples and it is not a simple stick-to-road algorithm, it has the ability to infer points that match your overall heading and route so if there are multiple road paths nearby a point, it mostly sticks your point to the ‘right’ road and that is quite smart. I bet they would be using some machine learning magic there To get ideal result APIs requires that your points should not be more than 300m apart
Accelerometer and gyro can be used for dead-reckoning and produce quite accurate results but because the data is numerically integrated over time it loses accuracy gradually this is where GPS location data can be plugged in again using Kalman filter to keep it on course. For now I am going to use Roads API and will post my results here. I am hopeful that it will save me from all that filtering stuff
Now the other problem of steering angle detection. I am planning to have a stab at just using the accelerometer to see how reliable the results are, if not I will think about adding a gyro to the mix. I am hesitant in introducing any external sensors to the asset tracker shield because more components I add, harder it will get for me to find a commercial grade housing to pack all the components before installing it in the bikes.
@noumanh FYI Adafruit is now carrying the new v3 of the Ultimate GPS receiver which may give you some better performance. Not sure if you can simply replace the current unit or not but figured you would like to know there is another GPS receiver out there.
so any pointers would be much appreciated. Thanks
To get ideal result APIs requires that your points should not be more than 300m apart
