Idea: Why Osmand should have OBDII plugin

[okias]

Osmand should have integration with OBDII adapters. Simply because getting data directly from ECU can move Osmand to another level and get improved driving experience.

How? All cars approx. since 2003 supports OBD-II. You can buy simple small adapter ELM327 (price starts about $2 ) and connect it directly into car. This adapter proviedes data over bluetooth or wifi directly into your phone. Now it's turn on Osmand, which picks all useful data and process them into enhancing navigation experience.

What can OBD-II connection proviede to Osmand?

• actual speed of vehicle (useful in tunnels or when GPS is out)
• fuel status (thx @hakuchi )
• when driving and "Check engine" lights up, it can offer you closest repair center
• and much more!

Who? We need our hero! Someone, who will write this great plugin and gets all glory!

List of testers (feel free drop comment, if you're willing test OBD-II plugin with some ELM327 adapter):

• @okias
• @hakuchi

Technical examples under open licences are available here: https://f-droid.org/repository/browse/?fdfilter=OBD&fdpage=1&page_id=0

[hakuchi]

Great idea! I also can test this with my OBD Link MX module

[yxnyqcpw]

OpenStreetview uses this. I don't know if their code could be of any use.

https://github.com/openstreetview/android

[okias]

I don't think it's usable, maybe some OBD android apps from F-Droid (opensource ones). I added them into first post.

[hakuchi]

A other option what OsmAnd can have with OBDII modules is, to check fuel level, and if it go under 10 liter OsmAnd can search a fuel station around ca.70km from my position and I can add it to actual route.

Also I think, this should be a plugin(like parking, ski, contour lines), so this not make the app to large.

[sonora]

Just for the record: This seems to be the European convention of what ODBII delivers:

• P00xx – Fuel and air metering and auxiliary emission controls.
• P01xx – Fuel and air metering.
• P02xx – Fuel and air metering (injector circuit).
• P03xx – Ignition system or misfire.
• P04xx – Auxiliary emissions controls.
• P05xx – Vehicle speed controls and idle control system.
• P06xx – Computer output circuit.
• P07xx – Transmission.
• P08xx – Transmission. The following two characters would refer to the individual fault within each subsystem

Looking at this list, frankly, I see a lot of car diagnostics OsmAnd cannot really usefully turn into any value-add? Yes, we could process and display things like speed or fuel level, but that is displayed by the car itself?

So all we could try for value-add is draw conclusions in terms of automatically suggesting a repair shop or a gas station, and I am not sure there is much advantage over a user performing this action in OsmAnd, because they may have additional preferences we do not know about?

So while I hear the message in this issue, I am really missing the surefire user story which would make this a killer feature?

[okias]

@sonora most important is speed, because when you're in out-of-GPS area, Osmand is totally powerless without informations from car.

There is many areas (tunnels, parking lots etc.), where GPS can't reach, that's where has in-car navs advantage, they can read these data. Also when your phone has bad day and sometimes just lose GPS.

I heard that Waze trying to fix this issue by selling beacons which you can place inside tunnels etc., but this seems much cleaner solution.

Also would be nice to have access to streering wheel angle (direction report for Osmand), but that's kinda vendor specific extension, so not sure about that.

[sonora]

Yes, but speed without direction is also not usable, right? What good is it to know speed when you drive around in a covered parking structure? Please note: I see the possible power of doing something here, but I am very doubtful this is useful with today's scope of data, and lack of ideas what we do with it ...

[hakuchi]

There are tunnels with exits inside or some meters after exit from tunnel, and after exiting from tunnel the GPS need time to find position and so OsmAnd not gives correct voice prompts.

for example "Richard-Strauss-Straße" in München: if I enter this way(https://www.openstreetmap.org/way/230701031) the maxspeed is 50km/h and after some meters the GPS signal is lost. inside the tunnel(https://www.openstreetmap.org/way/292781215) the maxspeed increase to 60km/h and if I take the exit(https://www.openstreetmap.org/way/85564754) the maxspeed is 50km/h

the used maxspeed inside the tunnel can change by high traffic load and OsmAnd is not able to detect speed and to give correct voice prompts for exit.

Other exits inside tunnel: https://www.openstreetmap.org/#map=17/40.41660/-3.72167&layers=N -> Madrid https://www.openstreetmap.org/way/27792332#map=16/59.9092/10.7312 -> Oslo https://www.openstreetmap.org/way/4493103 -> Berlin https://www.openstreetmap.org/way/27792332 -> Paris https://www.openstreetmap.org/way/38364752 - London

Intersection close after tunnel exit: https://www.openstreetmap.org/way/234910416 https://www.openstreetmap.org/way/24380800 https://www.openstreetmap.org/way/208535356 https://www.openstreetmap.org/way/441410140 https://www.openstreetmap.org/node/80075661

In tunnel simulation mode, OsmAnd can use OBD speed to simulate position on map and to give exact voice prompts for turns. Also it can give warning when you drive to fast(more and more tunnels have speed cameras).

I think this feature should be a plugin, because you have to buy a external OBDII device to become this functions available in OsmAnd and also PlayStore site can giving more information about functions/installation/etc.

[KOLANICH]

Some more ideas is to use distance sensors like radars or sonars some cars have to detect road side structures like fences, lampposts, traffic barriers, etc and this way to provide OSM with new data.

[dinamic]

I have an ELM327 and would gladly test such plugin, if available. I fancy the idea of having the extra functionality in my car!

One has to also take into account the difference of speed between GPS and ECU.

On my Ford Mondeo 2007 vehicle the difference is about 10%. If I am driving with 60km/h, the ECU reports 66km/h and the speedometer shows about 70km/h.

[Codain]

I also see a need to get GPS position from the car instead of from the phone (via an option for instance):

• car's GPS may sometime be of a better quality (because of algorithms coupled with speed/direction of the car, because it it outside of the metalic structure of the car...)
• this would allow to reduce phone power consumption (GPS can be greedy, so if I can turn it off...)

I totally agree with the comment regarding tunnels and parkings. I have a big one close to my House, several km long, with exits inside. OsmAnd is totally useless to catch the good one. Having an inertial position based on car data can be very helpfull to at least know when we arrive close to the exit. And I wonder if GPS data coming from the car is not already making this computation for you!

[Larry0ua]

Some vehicles have steering wheel angle data sent to OBD-II. Combining with always-present vehicle speed, this can be very helpful to predict location when driving with GPS signal lost (especially in tunnels).

[dr2okevin]

I would like to see support for OBD Data. At least speed should be easy do get, and is even on my 15 years old car available. I can already read that with the torque app. I think it is a great benefit to the tunnel simulation, and can also help to avoid gps jumps on red traffic lights. Maybe the Track Plugin can also use OBD to collect various vehicle data to each track point.

[lucumon]

Yes, but speed without direction is also not usable, right?

Osmand could probably use the smartphone's compass to get that direction

[jkufner]

It might be interesting to have fuel consumption and other data attached to the GPS log (in the GPX file).

[lordfolken]

Yes, but speed without direction is also not usable, right?

Osmand could probably use the smartphone's compass to get that direction OBDII Data also has the angle sensor for the wheel, so you have direction from that.

[lucumon]

OBDII Data also has the angle sensor for the wheel, so you have direction from that.

That data is not part of obd standard. Some cars provide that data but coding varies depending on the brand or even the model. Compass data is standart and avaliable on all recent android phones.

[lordfolken]

OBDII Data also has the angle sensor for the wheel, so you have direction from that.

That data is not part of obd standard. Some cars provide that data but coding varies depending on the brand or even the model. Compass data is standart and avaliable on all recent android phones.

You are right, its not listed here: https://en.wikipedia.org/wiki/OBD-II_PIDs However a compass inside a metallic cage such as a car has to be calibrated to get a useful result.

[seniorm0ment]

This could possibly be integrated as a plugin using the FOSS AndrOBD app which I would highly be interested in.

https://github.com/fr3ts0n/AndrOBD

[532910]

OBD reports wrong speed as it depends on tires, but combining it with GPS will produce an accurate instant speed, thats for it's used in OpenStreetview.

[lucumon]

If OBD is reporting wrong speed because of tires, then car's owner is not taking care of it. Every time you make a tire change, you should do a recalibration of your speedometer.

Obtener Outlook para Androidhttps://aka.ms/ghei36

---

From: sergio notifications@github.com Sent: Sunday, October 18, 2020 2:27:28 AM To: osmandapp/OsmAnd OsmAnd@noreply.github.com Cc: lucumon vacamaribu@hotmail.es; Comment comment@noreply.github.com Subject: Re: [osmandapp/OsmAnd] Idea: Why Osmand should have OBDII plugin (#3204)

OBD reports wrong speed as it depends on tires, but combining it with GPS will produce an accurate instant speed, thats for it's used in OpenStreetview.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/osmandapp/OsmAnd/issues/3204#issuecomment-711098072, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AF6N2EZ5V2ICA3NSTWH5HBTSLIY7BANCNFSM4CUCRB3Q.

[dr2okevin]

I don't know any car where it is possible to calibrate the speedometer. But OsmAnd could generate automatically a offset when driving with good GPS signal, and save that for later use.

[lordfolken]

My saab from 2004 had this function. If you changed the rim-size you hit that function and it would re-calibrate in combination with the gps.

[derkrasseleo]

Is this feature still considered? I think there are many data points that could be used. For example, vehicle velocity could be reported to some server to detect traffic jams.

KartaView's (formerly OpenStreetView) OBD implementation is not really reliable though, I would wait for them to fix it before implementing it in OsmAnd.

I would also help with testing (Carly OBDII Adapter).

[joaocandre]

What is the status of this? Is it even being seriously considered? I do think it could help to provide accurate fuel consumption stats to better decide between alternative routes, as well as recommended re-fueling adjustments to the travel plan.

Perhaps even a more detailed trip management like overall cost, which can be useful when carpooling?

[derkrasseleo]

I think the only problem that we need someone who knows how to actually implement it. Another question would be: could such a low level feature be provided by a plugin? Or do we need to change something in the main application? Also, is there documentation of how to write and test an OsmAnd plugin?

[hakuchi]

ANT+ gets implemented right now in #15459, so why not the obdII? There are arround 1000 mobile phones they have ANT+ build in, but all phones can use Bluetooth OBDII when they buy a cheap device.

[derkrasseleo]

If OsmAnd supports Bluetooth IO, it's probably not too hard to implement the OBDII protocoll as well. Maybe the implementation in KartaView could be useful?

Here's the source: https://github.com/kartaview/android/tree/master/app/src/main/java/com/telenav/osv/obd

[Sonwon1]

FYI, A work around if you have a tablet is to run the ODB2 software and OsmAnd in split screen mode.

[gkarre]

Hello,

No news for this implementation? I was trying to develop an autonomous app in .NET MAUI to come on top of OsmAnd just for that. We are a community of motorcycle riders and we are using Samsung Galaxy Active Tab as navigation devices. As they are quite big, sometime they are hidding screen of our machines. This is why I had the idea of developping an app. But that could be even better to have it directly in OsmAnd as we are all using it. It seems that plugins are developped in Java, which is a bit a pain in the ass for me as I know .net but not java. But I can learn and I would be very glad if anyone could provide a tutorial on how just to develop plugin. Then, I'll see what I can do.

[vshcherb]

If you can share what would be the minimal widgets set you would like to see and how you would like to see it could help us with implementation. Full implemenation of ODBII might be too big so we can't take as 1 step

[Sonwon1]

For me, engine temp and system voltage (to monitor the battery and charging health).

[gkarre]

Hi,

As for me and MattAdventure, our MVP would be:

1. Engine Temp
2. Battery Voltage
3. Error ODB (check engine)
4. RPM
5. Fuel Level
6. Gear Engaged (Neutral displayed in Green if possible)

We are ready to be alpha/beta testers if you need anyone.

Thanks a lot

[ser]

RPM for me please! it is very important to have it recorded on GPX track, it makes route modeling much better

[dr2okevin]

If you can share what would be the minimal widgets set you would like to see and how you would like to see it could help us with implementation. Full implemenation of ODBII might be too big so we can't take as 1 step

I'm not sure what you mean with widget, but as I mentioned almost 5 years ago, I would like to have the speed data to fix stuck or jumping GPS. Navigation always struggles with tunnels, especially if you have a traffic jam inside. Very tricky are also junctions inside tunnels.

[ntruchsess]

First of all I suggest to define a plugin-API that would allow to develop Vehicle-data-providing plugins independent from the actual source (OBDII being just one of them). Depending on the manufacturer there can be other ways to retrieve an equivalent set of data directly from the hardware. E.g. for BMW there is http://github.com/bimmergestalt

[lordfolken]

If you can share what would be the minimal widgets set you would like to see and how you would like to see it could help us with implementation. Full implemenation of ODBII might be too big so we can't take as 1 step

I'm not sure what you mean with widget, but as I mentioned almost 5 years ago, I would like to have the speed data to fix stuck or jumping GPS. Navigation always struggles with tunnels, especially if you have a traffic jam inside. Very tricky are also junctions inside tunnels.

This. Basically a fallback odometer that would warn in the right place of a junction or speed cam. Also Speed limit changes at exits of tunnels could be predicted more easily, as it always takes time for the GPS to reacquire signal upon exit of a tunnel. Potentially even the dark/light theme change and when to reinitialize the GPS connection (for a faster lock) could be steered with such a feature.

[gkarre]

First of all I suggest to define a plugin-API that would allow to develop Vehicle-data-providing plugins independent from the actual source (OBDII being just one of them). Depending on the manufacturer there can be other ways to retrieve an equivalent set of data directly from the hardware. E.g. for BMW there is http://github.com/bimmergestalt

You dont need a specific implementation per motorcycles brands. Basics information of ODB are fully standard.

[derkrasseleo]

First of all I suggest to define a plugin-API that would allow to develop Vehicle-data-providing plugins independent from the actual source (OBDII being just one of them). Depending on the manufacturer there can be other ways to retrieve an equivalent set of data directly from the hardware. E.g. for BMW there is http://github.com/bimmergestalt

Are there other popular (not ancient and or exotic) diagnostic protocols than OBD? BMW also uses OBD right? Of course, the datasets look different depending on the manufacturer. But the OBD II PIDs are standardized, so if we focus on implementing them, that would probably cover most vehicles on the street. Also, are we all on the same page that we interface via some type of ELM327 Bluetooth transceiver?

[lordfolken]

I think ODB-II should cover it.

1996: The OBD-II specification is made mandatory for all cars sold in the United States. 2001: The European Union makes EOBD mandatory for all gasoline (petrol) vehicles sold in the European Union, starting in MY2001 (see European emission standards Directive 98/69/EC[7]). 2004: The European Union makes EOBD mandatory for all diesel vehicles sold in the European Union 2006: All vehicles manufactured in Australia and New Zealand are required to be OBD-II compliant after January 1, 2006.[8] 2008: All cars sold in the United States are required to use the ISO 15765-4[9] signaling standard (a variant of the Controller Area Network (CAN) bus).[10]

Yes some ELM327 bluetooth adapter should suffice. The main value you are interested in is 0D 13 1 Vehicle speed 0 255 km/h A {\displaystyle A}

[ntruchsess]

Are there other popular (not ancient and or exotic) diagnostic protocols than OBD? BMW also uses OBD right?

BMW (cars) have an api that allows to read quite a lot of vehicle-data via bluetooth-connection or usb without using an OBD-adapter. (see http://github.com/bimmergestalt](https://github.com/bimmergestalt ). Just the app on the phone - that's it - no additional hardware required. I've used this api in the past and would love to implement a plugin that feeds that data into OSMAnd. Such plugin would benefit a lot from a hardware-independent plugin-api in osmand. (Of course a plugin that reads equivalent data via OBD would benefit the same).

[Sonwon1]

ODB2 works with my Honda motorcycle too so that would be great! I have a bluetooth OBD2 device plugged into the OBD2 port and display it in split screen mode on a tablet. However I would rather have the OBD2 info available in a widget so I can see more map data.

[sjvudp]

• actual speed

I'm late on this train, but for my older car the indicated speed is about 10% too high, compared to GPS. So always preferring the OBD speed may not be the best idea.

[Codain]

• actual speed

I'm late on this train, but for my older car the indicated speed is about 10% too high, compared to GPS. So always preferring the OBD speed may not be the best idea.

Regarding the difference between OBDII speed and GPS speed, this can be solved by an algorithm which can determine a compensation offset/percentage when both info are available. Determinate and compare the difference of both in time can help determine how to compensate, so that when GPS is lost, a GPS-like speed can be determined based on OBDII.

Little bit off-topic: In many countries cars are required to provide a speed to the driver which is higher than the measured speed by a certain offset/percentage. There are two reasons for that: Benefit for the driver to avoid having a speed ticket when they do not obviously exceed the limit (and because the car as its error in sensing and displaying, especially with needles) ; Benefit for the state who need to consider a margin of error on the radar side and can then reject protestations in many cases (this is the same reason why the speed considered for the fine is not the sensed speed but a speed reduced by a similar offset/percentage). As far as I know the navigation devices are not subject to car requirements so can display the real speed (to be then used at risk regarding speed limits since there is no margin and accuracy fluctuates).

Not off-topic: There are two needs expressed here: Display the speed from OBDII (less difficult) and use the speed from OBDII (more difficult). Let's not mix them.

For me the main advantage of OBDII interface (or another independent source for speed) is to allow a Dead Reckoning (DR) mode (as in aviation): If you do not have GPS anymore, you can project the speed (and other info available such as heading, turn rate...) on the path you are supposed to follow to get an idea of where you are (with an error growing in time before you acquire GPS again). But this means that the challenge is not only to get a speed from the car, it is also (and mainly?) to implement this DR mode.

[jkufner]

Little bit off-topic: In many countries cars are required to provide a speed to the driver which is higher than the measured speed by a certain offset/percentage. There are two reasons for that: Benefit for the driver to avoid having a speed ticket when they do not obviously exceed the limit (and because the car as its error in sensing and displaying, especially with needles) ; Benefit for the state who need to consider a margin of error on the radar side and can then reject protestations in many cases (this is the same reason why the speed considered for the fine is not the sensed speed but a speed reduced by a similar offset/percentage). As far as I know the navigation devices are not subject to car requirements so can display the real speed (to be then used at risk regarding speed limits since there is no margin and accuracy fluctuates).

This is very true.

When using car's speedometer, this must be compensated automatically, because all cars behave like that for the legal reasons. The user cannot be expected to enter any compensation manually and Osmand has GPS data for calibration. I think that the best and relatively simple approach would be to collect a transformation table when both OBD and GPS is available, then apply the transformation with some interpolation when GPS signal is not available. A simple "subtract 10%" is not good enough as the difference in the measured speed from the reality depends on the speed, tire pressure, and few other things.

[dr2okevin]

that was already discussed almost 4 years ago. https://github.com/osmandapp/OsmAnd/issues/3204#issuecomment-711147008