Vehicle Tracking with Node-RED, Arduino GSM, GPS, and MQTT

[Andrew Jawitz]

 Hello All,

    I've been working on a long term project that seems to mesh with others' experiments on this forum.  The project began as a collaboration with a small town transit agency to provide a low cost vehicle tracking device for their small fleet of two busses.  It was further developed via a series of National Day of Civic Hacking events and documented on www.openvehicletracker.org.  The original idea was to use an Arduino GSM Shield to transmit coordinates received through the excellent Adafruit Ultimate GPS chipset, but it resulted in a Serial Port traffic jam under the default Software Serial library. Thanks to recent updates to the AltSoftSerial library it looks like we finally found a way around this. With this out of the way, I'm looking at some combination of MQTT and Node-RED to relay the raw NMEA coordinates to either a live google maps server or Mapbox.  I know there have been a number of different flows submitted that use either OwnTracks or a Raspberry Pi to forward location updates to Google Maps or Twitter,  Has anybody successfully used the Arduino PubSub client to push GPS coordinates over GSM?  It does appear that one of the forum contributors came pretty close with the project documented at- https://github.com/Hardware-Hacks/Arduino_Tracker_v2 but I havent seen any updates for the last few months.

   Furthermore, and this is probably a huge stretch right now, but our eventual goal is to design a device that can switch between a GSM signal and a long range wifi mesh based on OpenWRT (see www.commotionwireless.org for details).  Separately, we've been looking to integrate the Arduino Yun (wich is also based on a version of OpenWRT) into the mesh as a relay node.  This is one of the reasons I've been drawn to MQTT because of its network agnostic flexibility.  Now that the Yun has beta support for Node.js and the PubSub client, I wonder if we could accomplish our eventual goal by running the GSM shield and GPS receiver off of the Yun?

[chris mobberley]

Ah yes my failed arduino_tracker project.

Essentially it would have worked but I wanted to run the thing off battery for over 30 days. This required building a barebones arduino and then buying a GSM2 click board. I started to hit power and also memory issues (due to my inefficient coding). Also the GPS would sometimes function ok, but then other times just decide to do its own thing when I wanted to sleep it.

After all of that, like you say a complete mess trying to get the software/altsoft serial libraries functioning correctly. I spent weeks with this headache and by the end of it just lost all love for the project.

Theres a couple of projects on instructables which you could probably follow and these were powered directly off the car batter, which I didnt want to do. However they do work!

My project was mainly aimed at lowest possible power consumption. I did predict if I set my arduino to sleep or even espruino in a deep sleep and just send out a text message once an hour it should have lasted for 400ish days on a 6000mAh battery pack.

Anyway.. I know this response is all over the place..I did start to look in to possible using radio signals to do the job. I think at the moment GPS coords is very easy, however adding in GSM which is so power hungry and also causes loads of issues with interfacing it's just a step too far for me time wise to complete. Saying that though.... I did nearly commit a version 3 the other day!

[chris mobberley]

I just re-read your post.

I think if you are not concerned over power usage.. then this project is entirely possible. Mine only failed because I was so damn focused on power consumption and efficiency. Also I would steer clear of the official arduino GSM shield I've seen a few posts around the orange capacitor exploding. Not great for remote tracking when you want to just setup and forget it.

http://www.mikroe.com/click/gsm2/

Thats the gsm module I use. Excellent price!

[Edward Vielmetti]

You're in a car, so there should be plenty of power when the car is
moving. When it's not moving you need to be more careful.

> --
> http://nodered.org
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to node-red+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Edward Vielmetti +1 734 330 2465
edward.v...@gmail.com

[chris mobberley]

Yeap that was the issue. I wanted to use the tracker more for when I go away working for long periods of time and my car is left at home/in car parks. I would then be able to setup  a geofence and be alerted when the car left the area e.g. stolen or impounded. I didnt want to use the car battery for this as I have come back before to a dead battery due to being away for so long. A self sufficient tracker, with a solar panel for charging was going to the the route I went down.

[George Hahn]

If you tie into the car's CAN bus, you can go into deep sleep and wake on a new message. Cars tend to be very quiet on the bus when they're off.

[Dave C-J]

Or if really just worried about movement how about a tilt switch to wake from very deep sleep ?

[Andrew Jawitz]

Wow!  30 days on battery?! And I thought my own project parameters were challenging! I have some more updated documentation at http://publiclab.org/notes/code4maine/03-24-2014/mesh-networks-for-rural-transit that gets into the nuts and bolts of what we've been trying to accomplish.  For the most part you'll see that we've been focusing more on mesh integration then GSM, though the recent updates to altsoftserial might make GSM more viable again.  Especially as a backup option should the vehicle leave the mesh network.  The optimal device in my view would function more like a datalogger than a full time tracking device. The key would be setting it up so when it comes within range of usable signal it knows how much data to transmit depending on the strength or type of connection it has access to.  Even if set up in a secondary role GSM could be quite useful in assuring that a bare minimum of data (lat/long coordinates) would be transmitted no matter what.  

 Which brings me back to why I'm interested in MQTT.  It seems to me that MQTT would be perfect for this configuration based on its "lightweight" footprint and "scalable" configuration (enter buzzword here...).  However, I'm still trying to figure out how this might fit into the Arduino client as currently envisioned.  Owntracks is easy enough to figure out, but I can't quite picture how one would do the same thing with an Arduino+GSM etc...  

  As I've already touched upon, its possible that the pieces are already in play with the Arduino Yun's support for Node.js and PubSub. I wonder how difficult it would be to handle the MQTT messaging on the OpenWRT side while the Arduino side can measure the strength of the connections before sending out the data?

One thing that really strikes me on hearing about other vehicle tracking projects is how much really depends on the specific use-case.  This may explain why IOT developers have had such a hard time with real-time location when it can't be implemented on a mass scale.  However,  I'm thinking this is where something like Node-RED could help the user, rather than the programmer, make some of the context-sensitive adjustments. Or it could be used to help a front-end designer make better use of the raw data feed in a Javascript format like Mapbox.  Either way it'll likely require additional experimentation in the field to help identify which issues might be context-specific so it can be presented to the user in a more accessible interface.

  

[Andrew Jawitz]

BTW- +1 to the CAN BUS idea!!!  Without the CAN Bus and OBDII port there's only so much data you could log anyway.  Besides lat/long I suppose it could give elevation, estimated speed between transmit points and maybe help with dispatch communications.  But that would be about it.  WITH the CAN Bus there's a whole new range of possibilities available including (theoretically) control of the vehicle itself!  I for one, would not be so inclined to go that far, but I have been ocassionally following the OpenXC platform which provides an Arduino-based SDK for interfacing with data accessed through the vehicles CAN BUS.  According to the OpenXC landing page "Some data is required by law and more can be unlocked with support from an automaker - or a little reverse engineering effort!".  Thus far Ford Motor Co. has provided an API for accessing in-dash controls in an effort to expand their Sync system.  I even got as far as building one of the DIY ChipKit-based Vehicle Interfaces, though I also got a hold of one of the reference dongles that Ford was sending out a few months ago.  The ChipKit VI design is basically the same thing as the 32 Bit Arduino Due with an OBD2 connector, but it came out before the Due was available so they used ChipKit instead.  Lately, I've been considering what would be possible if I were to use the UDOO, in place of the Chipkit since the UDOO includes a 32Bit, Due-equivalent microcontroller.  Of course, it also includes a ARM processor with FOUR TIMES the power of a Raspberry Pi!  So this might be overkilling just a bit...

[George Hahn]

Andrew, you bring up a really good point. If you have a cell data connection and the ability to talk CAN, you can do a lot more than just wake a logger. Imagine being able to use Node Red to roll your windows up or lock your car remotely! (Rain on the forecast -> windows up!)

NB: Depending on the car, you may or may not be able to hit the CAN you need from the ODBII port - cars have many data busses!

[chris mobberley]

I did quite a bit of research in to this stuff when I was looking at inspiration for my project. You can actually get trackers which build off the obd II connection.

Here is a great example:

http://www.norantracker.com/Products/Detail/2

You can also get electric/fuel cut offs based on geofence location changes or even a sms to the device to disable the car.

[chris mobberley]

This looks quite useful: http://chainwayits.en.alibaba.com/product/1377920105-213635642/OBD_II_Canbus_car_gps_tracker_engine_cut_off_99_accuracy_fuel_management_Android_APP_obd2_vehicle_gps_tracker.html

Sorry for just posting solutions! Much more fun to build yourself but it shows the possibilities.

[Nicholas O'Leary]

If you want to see a node-red controlled car, check this out - https://localmotors.com/awest/connected-car-project-internet-of-things/ :)

Nick

On 26 June 2014 12:38, chris mobberley <chrismo...@gmail.com> wrote:

This looks quite useful: http://chainwayits.en.alibaba.com/product/1377920105-213635642/OBD_II_Canbus_car_gps_tracker_engine_cut_off_99_accuracy_fuel_management_Android_APP_obd2_vehicle_gps_tracker.html

Sorry for just posting solutions! Much more fun to build yourself but it shows the possibilities.

--

[chris mobberley]

Out of interest Nick what are they using to internet that car up? Just standard GSM module as we are talking about here or something else? 

[chris mobberley]

Recently added some of my espruino code to git: https://github.com/Hardware-Hacks/Espruino_Tracker

[Andrew Jawitz]

I've been inching closer to my ideal hardware combo for vehicle tracking... I think...  With the new LininoONE I have essentially the same thing as an Arduino Yun in a much smaller footprint.  Furthermore, it seems to be somewhat easy to add GSM networking via a USB dongle.  They've also been experimenting with a Node.js-based dev environment called "IDEino" which runs .js scripts from a web-based interface.  

  Is this similar to Espruino?  Does Espruino require dedicated hardware?  Are sketches saved with a .js extension and if so would they be compatible with the IDEino IDE?  That would be great if I could simply port your Espruino Library to use with Linino/OpenWRT!

On Friday, 20 June 2014 10:59:34 UTC-4, Andrew Jawitz wrote: