Build on Linux

longfeltwant · 05-09-2009, 04:16 AM

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.

chunkyks · 05-09-2009, 12:19 PM

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 (-;

longfeltwant · 05-09-2009, 09:00 PM

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).

chunkyks · 05-10-2009, 06:47 PM

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 (-;

chunkyks · 05-11-2009, 01:34 AM

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 (-;

chunkyks · 05-11-2009, 01:35 AM

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 (-;

longfeltwant · 05-20-2009, 01:58 AM

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?

chunkyks · 05-20-2009, 01:42 PM

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 (-;

chunkyks · 05-20-2009, 08:59 PM

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 (-;

chunkyks · 05-21-2009, 11:10 AM

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 (-;

longfeltwant · 05-22-2009, 02:42 AM

Oh, excellent! A built package of OSX is helpful right now. Eventually I want to use my Linux laptop, but right now I want to set it up on my Mac laptop. Thanks for that.

So I actually need to ask a preliminary question not at all related to your software. I bought the same G-Sat GPS receiver you have, and I have a Mac like you must have. I open Bluetooth Preference Pane and add my device there. But when I'm done with the little configuration wizard, the GPS device shows up in the list, but the little icon is red and it says Not Connected. Is there something I'm missing about how to get the these two devices to connect to one another?

chunkyks · 05-22-2009, 11:16 AM

The mac will magically make the connection for you as soon as you try to actually *use* it. ie, just try launching gpsd -Nn /dev/cu.{whatever it is}. You don't need to "connect" to it first.

I was experimenting again with linux bluetooth last night, and while it was pretty doable, there were still the odd difficulty [such as ubuntu 8.10 not actually making a connection if I went through the GUI]. I'll gladly provide some help when you get to that stage, too :-)

Gary (-;

longfeltwant · 05-22-2009, 12:24 PM

Right you are, thanks, as soon as I ran gpsd (which on my Mac is gpsdX -- is that the same for you?) the G-Sat started blinking blue once per second, which is its signal for being connected, and the Bluetooth Prefs Pane showed it as connected. Wonderful.

Then I started up obdgpslogger

Code:

./obdgpslogger -s /dev/cu.BT-GPS-37C5BE-BT-GPSCOM-1

and I got this

Code:

Opening serial port /dev/cu.BT-GPS-37C5BE-BT-GPSCOM-1, this can take a while
Successfully connected to serial port. Will log obd data
Successfully connected to gpsd. Will log gps data
Didn't get parsable data back for cmd 05: 25,17,168,,21,15,109,,09,06,058,,07,04,320,*7B
$GPRMC,161420.760,V,,,,,,,220509,,*22

And a bunch more $GPRMC lines after that. I get more of those $GPRMC lines every few seconds, always preceded by the line saying it didn't get parsable data back for cmd 05. Does that refer to the OBD dongle? That's my guess because I am in fact in my living room, not sitting in my Jeep with the dongle.

So that's all pretty good. I was doing that on my Mac from a Terminal inside your OSX package (in /Content/Resources/bin). Next thing I'll try to do is to sit in range of my OBD dongle, and I'll try running the GUI.

I also have downloaded the source from SVN but haven't built it on my Mac. I got stuck on the first step, which uses cmake. I figured I didn't have cmake because I didn't have the Apple dev tools, but then I installed the dev tools and still don't have cmake. Did you just manually install that? I googled and see that there are some Mac packages for cmake.

chunkyks · 05-22-2009, 12:44 PM

Oooo.

The -s parameter to OBD GPS Logger is for the OBD device, not the GPS one. Just run

Code:

obdgpslogger --spam-stdout

And you'll see the gps stuff being reported. That's all there is until you sort your OBD device.

I'm not actually using gpsdX; I'm using a gpsd that I downloaded and built myself from the gpsd homepage

I should clarify; By using gpsd, you don't have to configure anything in obdgpslogger to work with the gps; it magically just works.

Gary (-;

longfeltwant · 05-23-2009, 04:09 AM

Great! I passed the next hurdle. I went out to my Jeep and sat there with my Mac, my GPS, and the OBD. I ran

Code:

obdgpslogger --spam-stdout

And I instantly saw some GPS output

Code:

gpspos=58.304787,-134.410629,59.500000

Then I added the OBD to the mix:

Code:

./obdgpslogger -s /dev/cu.CANOBDII-DevB-1 --spam-stdout

And I saw both GPS and OBD data!

Code:

>BD reported NO DATA for cmd 10: NO DATA
GPS acquisition complete
gpspos=58.304760,-134.410614,64.500000
temp=43.000000
rpm=906.000000
vss=0.000000

So that is great, it means all my hardware works, at least minimally. So at times I would see the note saying NO DATA for cmd 5 or 10 -- I'll look in the code to see what that means. Also, I tried without success to use the GUI. I launched it, and when I went to choose my OBD dongle, when I select the dongle in list in the dialog box, the application seemed to hang. I have it a long time to process, maybe five minutes, but eventually I force-quit.

I am now trying the convert log feature. Hmmm... when I click Convert the progress bar says Conversion Progress, but nothing else seems to be happening, no progress is ever shown.

So in theory, I should be able to forget the command line stuff, launch the GUI, set my GPS and OBD, then press Go, and everything would work. Is that the right idea?

User Name		Remember Me?
Password