FoxtrotGPS: Difference between revisions

From Wildsong
Jump to navigationJump to search
Brian Wilson (talk | contribs)
Brian Wilson (talk | contribs)
 
(4 intermediate revisions by the same user not shown)
Line 2: Line 2:


Website: http://www.foxtrotgps.org/
Website: http://www.foxtrotgps.org/
== Wish list ==
Cursor that shows heading
User selectable cursors
OBD II information:
Complete sensor information from [[OBD II]], both raw and processed
Advanced GPS information page (Like gpsmon output!) including:
* Satellite information
* DOP
Ham radio integration
* [[APRS]]


== User guide ==
== User guide ==
Line 65: Line 80:
Peeking at the code, it looks like it's using "curl" to send messsges to a Web server.
Peeking at the code, it looks like it's using "curl" to send messsges to a Web server.


The projects list at FoxtrotGps.org suggests that standards would be better and that a couple possibilities are XMPP (Jabber) and YouLoc.net
The projects list at FoxtrotGps.org suggests that standards would be better and that a couple possibilities are [[XMPP]] (Jabber) and YouLoc.net


I am looking at GeoRSS and wondering if it's applicable. GeoRSS supports drawing shapes (not just points) on a map, so for example the extent of a flood could be transmitted as a polygon.
I am looking at GeoRSS and wondering if it's applicable. GeoRSS supports drawing shapes (not just points) on a map, so for example the extent of a flood could be transmitted as a polygon.
Line 135: Line 150:
It runs!
It runs!


=== Contributing changes ===
== Contributing changes ==


Overview of the steps:
Overview of the steps:
# Log in (you only have to do this once on a computer)
# Log in (you only have to do this once on a computer).
# Create a branch
# Create a branch.
# Edit files, fix your bug or add your change
# Edit files, fix your bug or add your change.
# Commit the files that changed (which only affects your computer)
# Commit the files that changed (which only affects your computer).
# Send the changes to the maintainer, there are several ways to do this.
# Send the changes to the maintainer, there are several ways to do this.
# The maintainer(s) will evaluate your change and if they are acceptable, merge them into the trunk in a timely fashion.
# The maintainer(s) will evaluate your change and if they are acceptable, merge them into the trunk in a timely fashion.
Line 148: Line 163:
More details:
More details:


'''Logging in'''
'''Log in, using your own email address.'''


  ~/src$ '''bzr whoami "Brian Wilson <brian@wildsong.biz>"'''
  ~/src$ '''bzr whoami "John Doe <jdoe@gmail.com>"'''


'''Creating a branch''' is almost the same as the first step to building from source. You should check out code to your own branch, for example I am working fixing bug 663102, so I do it like this. This makes it easier to tell your branch from the trunk when you submit patches.
'''Create a branch''' This is almost the same as the first step to building from source. You should check out code to your own branch. For example, I am working fixing bug 663102, so I do it like this. This makes it easier to tell your branch from the trunk when you submit patches.


  ~/src$ '''bzr branch http://www.foxtrotgps.org/branches/foxtrotgps-dev/ foxtrotgps-663102'''
  ~/src$ '''bzr branch http://www.foxtrotgps.org/branches/foxtrotgps-dev/ foxtrotgps-663102'''
Line 159: Line 174:
If you are working on a new feature instead of a simple bug fix you might name the branch after the feature, for example "foxtrotgps-usng-support".
If you are working on a new feature instead of a simple bug fix you might name the branch after the feature, for example "foxtrotgps-usng-support".


'''Make your change''' or addition or whatever. "One change" means you want to do the minimum necessary to, for example, fix just one bug, not several bugs. This makes evaluating the work you did easier for the maintainers, and therefore decreases the turn around time on your changes being incorporated (and increasing the probability that the changes will be accepted!)
'''Make your change''' or addition or whatever. "One change" means you want to do the minimum necessary to, for example, fix just one bug, not several bugs. This makes evaluating the work you did easier for the maintainers, and therefore decreases the turn around time on your changes being incorporated (and increases the probability that the changes will be accepted!)


(And it goes without saying, compile and test thoroughly before sending changes in.)
It goes without saying, compile and test thoroughly before sending changes in.


'''Commit your change'''  
'''Commit your change'''  


For example,  
Now that you have updated one or more some files, you need to commit the changes. From your source directory, execute the commit command along with a brief but meaniningful message. For example,  


  ~/src/foxtrotgps-663102$ '''bzr commit -m "These changes fix bug number 663102"'''
  ~/src/foxtrotgps-663102$ '''bzr commit -m "These changes fix bug number 663102"'''


The bazaar model is to keep the code on your machine until you publish the changes. So you can do many commits until you are ready to share the changes. This makes sense if you are adding a new feature and want the benefits of version control without having to publish non-working code.
Unlike other version control systems (such as subversion), when you perform a commit with bazaar the changes stay on your own machine. The changes do not get sent to the remote repository until you execute a "publish" command.
You can do many commits and/or reverts before you share the changes. This makes sense, because if you are adding a new feature and you have all the benefits of version control without having to publish any non-working code.


'''Send the changes the maintainer.''' If the change is relatively small, you can "send" the changes to a patch file and then attach the file to the bug in the comments section of the bug tracking system.  
'''Send the changes the maintainer.''' If the change is relatively small, you can "send" the changes to a patch file and then attach the file to the bug in the comments section of the bug tracking system.  
Line 181: Line 197:
Now you can use a web browser to connect to the bug tracker, add a comment to 663102, attaching the file fix663102.patch.
Now you can use a web browser to connect to the bug tracker, add a comment to 663102, attaching the file fix663102.patch.


If you are working on a big change and you have access to your own publicly accessibly SFTP site, you can set up SFTP access, upload your changes to your site, and then tell people the URL either by email or in the bug tracker.
If you are working on a big change and you have access to your own publicly accessibly SFTP/Web site, you can use SFTP to upload your changes to your site, and then share the Web URL with other developers either by email or in the bug tracker.


Now you have to wait for the changes to be accepted, and merged into the trunk.
After letting us know about your changes, the next step is to wait for the changes to be accepted, and merged into the trunk.


To work on a NEW bug or feature, you'd start the whole cycle again, checking out a new copy of the code so that you are starting from the trunk.
To work on a NEW bug or feature, you'd start the whole cycle again, checking out a new copy of the code so that you are starting from the trunk.


====Setting up an SFTP site====  
=== Publishing your branch with SFTP ===  
 
To publish code, you need a server that is accessible over the Internet. Many cheap hosting services (hostmonster.com is one) include ssh and sftp access. If you have an account at one of these, then all you need do is place a bzr repository on the server in a space that is accessible by both sftp and http. Then you can directly publish code with bzr commands, and give the repository http URL to friends.
 
If you run a public Web server, and it has the openssh server package installed, all you need to do is edit its configuration file to enable sftp access.
 
More details of setting up an sftp server are really beyond the scope of this little document. Please don't let access to an sftp server stop you from participating; let us know and we'll work something out.
 
=== Sample sftp commands ===
 
If you have a domain called mydomain.com the publish command would be
 
bzr push --create-prefix sftp://[email protected]/~/public_html/foxtrotgps
 
Bazaar will create the foxtrotgps directory on the remote server and push your branch to it.


Setting up sftp is really beyond the scope of this little doc, if you want to commit changes and this is beyond you, I am sympathetic! We want your help, and we will make other arrangements.
This makes your repository accessible with bazaar with


I use a service (hostmonster.com) that comes with ssh and sftp access, so all I needed to do was place a bzr repository on the server in a space that is accessible by both sftp and http. Then I can publish code with bzr commands, and give the repository http URL to friends.
$ bzr branch http://www.mydomain.com/foxtrotgps

Latest revision as of 00:06, 17 April 2012

Notes on FoxtrotGPS, a friendly open source GPS navigation program.

Website: http://www.foxtrotgps.org/

Wish list

Cursor that shows heading User selectable cursors

OBD II information: Complete sensor information from OBD II, both raw and processed

Advanced GPS information page (Like gpsmon output!) including:

  • Satellite information
  • DOP

Ham radio integration

User guide

Foxtrot on the Openmoko

Command line option: (just one) --fullscreen to start in fullscreen mode

Sidebar

There are 7 buttons on the left sidebar

  1. Show info - toggle a panel on the right side on/off
  2. Fullscreen toggle
  3. Zoom in
  4. Zoom out
  5. Autocenter - Keeps the map centered on the current GPS position.
  6. Next - Selects the next map source - the list of map sources is set in the Configuration panel
  7. Prev - Selects the previous map source

Map

Context menu

this point

show friends

show POIs

show photos

ways & routes >

POIS >

photos >

my position >

map download

map detail >

Right panel

Toggled on/off with the i button.

Arrows at top rotate through 4 panels:

1 Trip Meter

2 Friends

3 Tracks

4 Configuration

Friends

Looks like you can register at a central web server, and send updates on your position at a selectable interval (default 5 minutes). You can set a status ("What are you doing")

Peeking at the code, it looks like it's using "curl" to send messsges to a Web server.

The projects list at FoxtrotGps.org suggests that standards would be better and that a couple possibilities are XMPP (Jabber) and YouLoc.net

I am looking at GeoRSS and wondering if it's applicable. GeoRSS supports drawing shapes (not just points) on a map, so for example the extent of a flood could be transmitted as a polygon.

I am also wondering how to fit APRS into the picture. I'd like to have APRS stations appear on my FoxtrotGPS map.

Configuration

Set up gpsd after connecting a GPS device by first figuring out which port your GPS is on and then running dpkg-reconfigure gpsd.

Testing gpsd: run the command line program, gpsmon it will give you all it knows about where you are. For example,

localhost:2947:               Generic NMEA>
????????????????????????????????????????????????????????????????????????????????
?Time: 2010-12-11T04:32:57.0Z  Lat:  44 32' 44.269" N  Lon: 123 15' 45.931" W  ?
?????????????????????????????????? Cooked PVT ??????????????????????????????????

Look and feel

I need to figure out how to make FoxtrotGPS look good on my 7" monitor on 8track. I know this is possible because it runs on Openmoko phones.

X resources

Developer stuff

FoxtrotGPS builds on a rich foundation of open source components.

Building on Ubuntu 10.04

Actually this works on my Debian 5.0 machine, too.

Prerequisites

Taken straight from the source

What I had to install

Starting with a machine that's been used to compile and build projects, I still had to install some stuff.

I downloaded and built curl and gpsd from source, Ubuntu version is outdated.

sudo apt-get install libgconf2-dev libglade2-dev curl sqlite3 libsqlite3-dev \
  libxml2-dev libexif-dev libcurl3
sudo apt-get install bzr
sudo apt-get install autoconf intltool libtool

bzr branch  http://www.foxtrotgps.org/branches/foxtrotgps-dev/
cd foxtrotgps-dev/
./autogen.sh
./configure
make
sudo make install
foxtrotgps

It runs!

Contributing changes

Overview of the steps:

  1. Log in (you only have to do this once on a computer).
  2. Create a branch.
  3. Edit files, fix your bug or add your change.
  4. Commit the files that changed (which only affects your computer).
  5. Send the changes to the maintainer, there are several ways to do this.
  6. The maintainer(s) will evaluate your change and if they are acceptable, merge them into the trunk in a timely fashion.
  7. Update your source code from the trunk

More details:

Log in, using your own email address.

~/src$ bzr whoami "John Doe <[email protected]>"

Create a branch This is almost the same as the first step to building from source. You should check out code to your own branch. For example, I am working fixing bug 663102, so I do it like this. This makes it easier to tell your branch from the trunk when you submit patches.

~/src$ bzr branch http://www.foxtrotgps.org/branches/foxtrotgps-dev/ foxtrotgps-663102
~/src$ cd foxtrotgps-663102

If you are working on a new feature instead of a simple bug fix you might name the branch after the feature, for example "foxtrotgps-usng-support".

Make your change or addition or whatever. "One change" means you want to do the minimum necessary to, for example, fix just one bug, not several bugs. This makes evaluating the work you did easier for the maintainers, and therefore decreases the turn around time on your changes being incorporated (and increases the probability that the changes will be accepted!)

It goes without saying, compile and test thoroughly before sending changes in.

Commit your change

Now that you have updated one or more some files, you need to commit the changes. From your source directory, execute the commit command along with a brief but meaniningful message. For example,

~/src/foxtrotgps-663102$ bzr commit -m "These changes fix bug number 663102"

Unlike other version control systems (such as subversion), when you perform a commit with bazaar the changes stay on your own machine. The changes do not get sent to the remote repository until you execute a "publish" command. You can do many commits and/or reverts before you share the changes. This makes sense, because if you are adding a new feature and you have all the benefits of version control without having to publish any non-working code.

Send the changes the maintainer. If the change is relatively small, you can "send" the changes to a patch file and then attach the file to the bug in the comments section of the bug tracking system.

The bug tracker is here: https://bugs.launchpad.net/foxtrotgps/

The send-to-a-file command looks like this.

~/src/foxtrotgps-663102$ bzr send -o ../fix663102.patch

Now you can use a web browser to connect to the bug tracker, add a comment to 663102, attaching the file fix663102.patch.

If you are working on a big change and you have access to your own publicly accessibly SFTP/Web site, you can use SFTP to upload your changes to your site, and then share the Web URL with other developers either by email or in the bug tracker.

After letting us know about your changes, the next step is to wait for the changes to be accepted, and merged into the trunk.

To work on a NEW bug or feature, you'd start the whole cycle again, checking out a new copy of the code so that you are starting from the trunk.

Publishing your branch with SFTP

To publish code, you need a server that is accessible over the Internet. Many cheap hosting services (hostmonster.com is one) include ssh and sftp access. If you have an account at one of these, then all you need do is place a bzr repository on the server in a space that is accessible by both sftp and http. Then you can directly publish code with bzr commands, and give the repository http URL to friends.

If you run a public Web server, and it has the openssh server package installed, all you need to do is edit its configuration file to enable sftp access.

More details of setting up an sftp server are really beyond the scope of this little document. Please don't let access to an sftp server stop you from participating; let us know and we'll work something out.

Sample sftp commands

If you have a domain called mydomain.com the publish command would be

bzr push --create-prefix sftp://[email protected]/~/public_html/foxtrotgps

Bazaar will create the foxtrotgps directory on the remote server and push your branch to it.

This makes your repository accessible with bazaar with

$ bzr branch http://www.mydomain.com/foxtrotgps