Build on Linux

Hello. I am very interested in this software because I am going on a road trip this summer. I'm glad you decided to write this software just now, because it is just in time for me to use it.

I have a Linux (Ubuntu) netbook with Bluetooth. Because I was so impressed with this software, I have purchased an OBD dongle and a GPS receiver, each with Bluetooth. They are coming in the mail, but in the mean time I built the software on Linux. I had to install gpsd, gpslib-dev, fluid, and fltk. After I installed those packages, it built with no errors. I can run the GUI and see the instruments.

It would be fun to have the GUI up and running on the netbook while I'm driving (for my copilot to look at, of course), and also logging things to the background database. If I can get all that to work, I'll be pretty happy. My thought is that I could write a script to run when I plug in my USB camera -- the script would export the obdgps data to a KML file, then I'd parse the KML file and insert references to my pictures, and geo-tag the photos by comparing the photo timestamp to a timestamp in the KML. I want some way to link to the resulting KML file from a blog, so that people can follow my progress, see the photos, see my route, and the vehicularly inclined can see some nerdy car data.

I have done some programming, so if this effort needs a technical hand, I offer my help. My road trip begins in six weeks. Perhaps I can help with bug testing, or perhaps I can assist with some feature enhancements.

Glad to hear it has been good so far :-D

Quote:

---

It would be fun to have the GUI up and running on the netbook while I'm driving (for my copilot to look at, of course), and also logging things to the background database.

---

That's the whole idea of the gui, actually. The core software is a commandline app that does logging [and happens to be able to spam what it reads to stdout]. The GUI simply spawns the commandline app to do logging and display the output.

Let me know when you get a chance to try it, and any successes or problems you have. I'm always totally stoked to see people actually using projects I've worked on :-)

Gary (-;

I have now had an opportunity to look thru the generated KML files and thru some of the code. The first thing I noticed is that the output does not include time tags, which would be an essential part of the mix for my needs. I don't know the KML spec well enough to estimate the difficulty of adding time tags. Google Earth supports time tags and can show a little animation. That would be great for my needs -- so you could see a little icon of my Jeep traveling along the route, leaving a trail behind it, with icons representing photographs along the way. I will look up the KML spec and look in your code to see about adding time tags.

I also tried to find a good KML library. All I found was libkml from Google, which looks nice but is only for reading KML, not for writing it (according to my limited understanding).

Huh, I'd never heard of that. Reading the spec, it's really easy to add, I'll try and get it done this evening if I have time

Gary (-;

Huh. So, neat stuff. I added time to the main plot [the height & color one], but it doesn't give the best usability for non-time-related scenarios.

I'm leaning towards adding a new plot, purely time vs position. I'd do it in a thicker line of a different color, so you can see it next to the other plots it already does. That way, you'd be able to add photos to certain points on it more easily, without them getting confused in a mass of other data. Does that make sense, or do you have something better in mind?

I'm fully open to suggestions, since I'm not really sure a good way of plotting this much data all on the same graph at the same time. Currently the main, default, plot shows position, velocity, and mpg. Adding a fourth dimension to that makes it a bit messy on-screen [and confuses me, but I'm pretty simple].

Gary (-;

Oh, and I meant to say; I haven't yet committed it, since I really don't actually like the output. I'll try to figure something out tomorrow, but please let me know if you have any ideas

Gary (-;

Hi Gary. I have now received my OBD dongle and my GPS transceiver. I was able to us the Bluetooth-configuration software on both my Mac and my Linux machines for both devices, so I know the devices can be connected to. Then I launched your software (the GUI) and hoped for the best, but got nothing. I imagine I need to change the OBD Serial Port, but I don't know how to find the right port, because I bought a different dongle than you have. Mine shows in the Bluetooth Preferences as "CAN OBDII".

Then, even if I could find the right port, how do I then connect the GPS software? Do I run the obdgpslogger from the command line, to get its information into the sqlite DB?

Good stuff! Let's see:

Going back after reading all this, it sounds a lot longer and more complicated than it really is. My apologies.

As I invest more time in development, things are getting a lot easier for end users, but I still sometimes forget how the little things I configured once, long ago, can be a pita.

0) obdgui is just a front end for obdgpslogger. Whether you use the gui or not, the sqlite db will be created and logged to. The GUI just presents an easy way of starting the logger [it actually fork/exec's the logging tool]. While debugging and getting stuff working, the command-line is easier.

1a) Device Names, OSX:
When configuring the devices on your mac, you had to specify a serial port name, although the mac populated a sensible default. You can still find that in your bluetooth configuration panel. Typically the mac will call serial ports /dev/cu.{something}. Just root around, it's really obvious when you find it.

You could also try just "ls /dev/cu.*" in the terminal.

1b) Device Names, Linux:
Linux being linux, no two distributions will ever do the same thing twice, which can be a pain. For that matter, *Linux* will rarely do the same thing twice. Someone on the python mailing list here explains the "correct" way to make sure your bluetooth devices get consistently named, although chances are good that your modern distro did some of this for you.

For quick and easy testing under linux without udev futzing, you might try just a "tail -f /var/log/messages" while attempting a bluetooth connection from your machine using your distro's control panel or something. You may find it's called "rfcomm1" or similar.

2) Run "./obdgpslogger -s /dev/{obd device}" to see if it works

3) gps. Same as for the OBD Device, you need the serial port. I'm using gpsd to actually talk to it, so as soon as you figure it out, open a console and type "gpsd -N -b /dev/rfcomm2" [replacing your device path, obviously]. You should see a bunch of console spam. Assuming that's working, try starting obdgpslogger again, and you should see success.

If you don't have gpsd on osx, this post is for you.

4) OSX Kool-aid: I've been doing most of my development on the mac, so there's a few useful nods in that direction:
4a) After building everything on osx [assuming the gui built fine too], try "make package". It creates a .dmg with an app bundle in it.
4b) The GUI now ["now" as in "committed to svn last night"] has a gpsd launch wizard that you can use to start gpsd. If you use "make package" as above, gpsd is actually copied into the app bundle.
4c) I will probably change the device chooser widget to an editable drop-down list pre-populated with a list of likely devices. This will work better on OSX than on Linux


I plan to do a real software release today or tomorrow, and I'll post an osx package, which comes with its own copy of gpsd inside the app bundle. If you don't want to spend time futzing getting things to build, that may be easier.

Have fun,
Gary (-;

I just committed device-guessing code.

On OSX, you should find that the gpsd wizard and obd device filename inputs are populated with some sensible guesses.
On Linux they're also populated, but it's a likely to be a bit more scatter-shot.

Gary (-;

I just posted a test OSX intel package, hopefully it should resolve most of your problems on OSX

OBDGPSLogger-0.5-Darwin-intel.dmg

Gary (-;