Site menu:


Latest comments

Knowledge partners

polimi logo
ocu logo

Technology partners

g-red logo
cryms logo
applied technology logo

Supporters

osgeo.jp logo

infn_logo

Projects using goGPS

geoguard_logo

italrad_logo

brigaid_logo

Feeds

RSS InsideGNSS

goGPS project is warming up…

A collaborative project to develop goGPS in a fully-featured open source environment is starting.

Stay tuned for more news!

Comments

Comment from Stephen Jack
Time 2010/05/10 at 21:30

Hello interesting project, but please take a crash course in economics. Your October 2009 estimate on your product pricing $1000 – $1500 I found slightly expensive, $500 – $1000 I think should be your target. The March 2010 pricing for your product of $3000, well thats a killer, at that price I should seriously think about halting your project as you have no chance. As to you pricing of survey grade technology, $15000 in 2009 and then $30000 in 2010, heck blade technology starts at $6000 in the Ashtech ProMark 3.
What you have is high volume low price product. There is too much competition on the horizon to dream of $3000 a unit. Hope you find the feedback helpful.

Comment from ege010
Time 2010/05/11 at 07:03

Hi Stephen,

thank you for your feedback, but I think there is some misunderstandig here.

First of all, we don’t have any price target for goGPS, since goGPS is and will stay free software (both “free” as in “free speech” andfree” as in “free beer”). The $1000-$1500 that has become $3000 in the latest slides are just examples of the order of magnitude of the price for mid-level commercial L1 receivers (such as the Leica GS20 you see as an example). In fact goGPS stays between the mid-level example and the low-level example to show where it should fit as for its accuracy. The hardware prototype plans I wrote in the slides are just future developments we are interested in for research purposes. goGPS is just software.

Second, the price of survey grade receivers was increased from $15000 in 2009 to $30000 in 2010 because these are the prices I got from my own experience in Italy (2009 – but maybe it was cheaper because our university was collaborating with Leica) and in Japan (2010). I came here thinking I could have bought a double frequency instrument for $15000-$20000, but the prices I got here in Japan are exactly what I wrote: ~$30000. So I increased it in the slides to reflect the situation here in Japan. Please note that these are the prices for geodetic level double frequency GPS/GNSS receivers+antennas. So maybe crash courses in economics should be taken in each different national reality in order to have some value when you cross borders. 😉

Finally, I don’t know so much about Ashtech products (never used them), but the Ashtech ProMark 3 is a single-frequency DGPS receiver. So in my slides it would fit together with the Leica GS20. If you meant the Ashtech ProMark 3 RTK, it is the same single-frequency receiver but with RTK support. This is exactly what we are doing with goGPS: L1 RTK positioning. The difference is that goGPS comes free (and open source), then the accuracy you will get only depends on how much you are willing to pay for hardware that provides you with GPS raw data (code and phase measurements, SNR, etc.). In particular, results will mostly depend on the antenna quality.

Cheers

P.S. when I wrote those slides I was not really interested in the prices, anyway… I needed just to explain roughly to the audience the difference between a geodetic receiver, a mid-level receiver and what 99% of people think when they say “GPS“.

Comment from Stephen Jack
Time 2010/05/11 at 21:52

OK so I have my cart on top of the horse If not quite before the horse.

I familiar with the beagle board RTK reciever and RTKLIB software by Takasu. Am I correct in thinking that your project is a step forward from this, due to the fact that it can operate effectively while in motion?

I have had plenty of experience in setup up control networks, GPS controlled graders, but I am at heart a lego person. Give me the parts and instructions and I can build or assemble most things. So what I would like to know, do you envisage filling in the hardware gap?

Comment from Stephen Jack
Time 2010/05/12 at 06:08

A couple of other points. Is it possible to view the slide show full screen, as I can not read it very well in its current size?

Can you give some detail to the actual hardware that you have used?

How can GoGPS function out side of Japan and Italy where there is no base station support?

Thanks

Comment from ege010
Time 2010/05/12 at 10:39

Hi Stephen,

sorry for replying late.

Why do you say that RTKLIB does not operate effectively while in motion? I mainly used it for post-processing data acquired by receivers in motion and I didn’t notice problems. What level of accuracy are you trying to achieve?

As for the hardware, yes we are currently thinking that it would be nice to build some prototype as explained in the slides, but I’m not a hardware guy, so I could not say how long it will take. We are in contact with some people that could help, but there is no real plan yet, just ideas.

To view the slideshow full screen, just select “Menu” -> “View Fullscreen”, it should work.

What do you mean by details about hardware? We use u-blox AEK-4T and EVK-5T evaluation kits with their standard antenna, and recently we tried to connect a higher quality ANTCOM antenna to the AEK-4T. It works well, but I don’t have accuracy values yet. As master station, we use Virtual Reference Stations or a stationary double frequency receiver like the Leica GPS1200. Let me know if you want to know something else.

As for base station support, a lot of European countries already have national or regional networks of permanent stations. Here you can find a list of NTRIP casters, both free and non-free ones. If a network is not available, often a single station can be used, if you stay within 10 km from it in order to make atmospheric biases negligible. Otherwise, you can use a stationary receiver, with known coordinates, and use it as a temporary master station.

Thanks for your questions!

Comment from Stephen Jack
Time 2010/05/13 at 20:42

This was the paper I was referring to with regard to GoGPS being a step forward.
http://gpspp.sakura.ne.jp/paper2005/isgps_2009_rtklib_revA.pdf
“With a single-frequency receiver, at least a few minutes are necessary to obtain a first fixed solution. So, in the environment with many cycle-slips like for mobile vehicle navigation, low-cost receivers are not suitable for RTK-GPS. Though, for the application with continuous observation like crustal deformation monitoring, low-cost single-frequency”
The project I am working on is a micro survey boat just over 1m in length. Using GPS and an autopilot I’m aiming to navigate down 1m corridors and record location to an accuracy of better than 0.5m Recording the location should be feasible, however navigating within a 1m corridor even with survey grade systems is going to be a tough objective.
Is there any chance of you putting together a video of how you use GoGPS, showing all the stages in the process and how the equipment is setup?
Thanks again

Comment from ege010
Time 2010/05/14 at 10:25

goGPS and RTKLIB have different approaches. goGPS aims (mainly) at improving as much as possible the positioning accuracy with low-cost receivers and antennas, also in cycle-slips prone environments: to do this, it avoids trying to fix phase ambiguities and it keeps them floating and evolving in the Kalman filter (besides weighing measurements, using DTMs, etc). With this approach we don’t expect to get accuracies better than 30-50 cm.
RTKLIB, as far as I have understood, is more concerned with getting high accuracy (centimetric) even with low-cost receivers (but with high-quality antennas). To do this, it needs to fix ambiguities, but this procedure, as Takasu-san wrote, takes some minutes with a single-frequency receiver. So, if you are in a cycle-clips prone environment, you never manage to fix them because they have often to be re-initialized. Anyway, you can set RTKLIB to keep float ambiguities if you need so.

As for your project, how much sky visibility would the boat get in the corridors? If the sky visibility is very limited, it can be tough to get accuracies better then 50 cm.

We are actually planning to produce some kind of “demo” video about using goGPS, but keep in mind that goGPS is not ready for applications yet… it is still running in MATLAB (even if we hope to release a Java version soon), so it’s still “research-oriented” let’s say…

Comment from Stephen Jack
Time 2010/05/15 at 07:02

The corridors are imaginary, the limits of deviation for the survey vessel. The sky visibility should be excellent, no building trees or mountains, just low land and inland sea.

If I want to try using GoGPS I need Matlab, is this a free software or or commercial?

Want is the advantage to the Java version when it comes, how will it operate?

Comment from ege010
Time 2010/05/17 at 02:00

Unfortunately, MATLAB is not free… you need to buy a license to run it. Moreover, it’s not helping performance, since the system you want to run goGPS on needs first to be able to run MATLAB, and then run goGPS in MATLAB. That’s why I wrote that it’s still “research-oriented”.

The Java version will allow us to run goGPS independently from MATLAB, to release platform-independent executables, and hopefully to widen the user and developer base.

Comment from Chris
Time 2011/09/07 at 17:04

There are a number of so called “Matlab clones” out there, one example is GNU Octave.

I just stumbled across your project, so right now I am going to see if Octave contains the routines needed to run your software.The quickest way to see is to try it.

I’m running RTKlib under both Wine and under OS X natively (sans GUI apps) and my experience so far is consistent with what you said above.

Even for a newcomer, however, although its quite technical and a bit overtechnical for many, I’m sure, but for me its proven to be very enjoyable as under Windows/Wine you can visualize raw data as its received in real time – via rtkplot – and thats quite amazing for learning about what is happening, as you can explore the process by which its arrived at in detail.

I am excited to discover your project and about your Java program and would very much like to try out the CVS version when its possible.

Comment from ege010
Time 2011/09/08 at 01:25

Hi Chris,

I tried to keep goGPS Octave-compatible during the earliest stages of the development, but I’m afraid the compatibility was definitely lost when we started using serial port communication for real-time positioning. Maybe even the GUI has problems, I’m not sure.

If you disable everything related to serial ports (and maybe even the GUI – there is a flag for that at the beginning of goGPS.m), maybe you can manage to run goGPS post-processing functions in Octave too.
If you manage to do that, please let me know!

One of the good things about using MATLAB is that it is very easy to display any data at any stage of the processing, if you are interested in what’s going on “behind the curtain”.

About goGPS Java, we are planning to release it “officially” in the next few months, but if you want to give a look at its current stage of development, you can find the source code here: http://code.google.com/p/gogps/source/checkout
At the moment it has no GUI, and only the basic functionalities of goGPS MATLAB have been implemented, but it is already being used in a production environment. It works both in real-time and post-processing.

I am preparing some tutorials for both goGPS MATLAB and Java (in my spare time, so it’s a slow process!)… if you are interested, please write me an email to the address you can find in the Support page. I can send you the drafts.

Cheers,
Ege

Comment from ags
Time 2012/12/07 at 07:28

Hi Ege,

Does goGPS allow using a second receiver configured as a stationary base? We don’t really have virtual reference stations.

Cheers,
Alex

Comment from ege010
Time 2012/12/12 at 05:59

Hi Alex,

well, you can log the observations of a secondary receiver kept stationary on a point of known coordinates, create a RINEX file out of them and do post-processing using that as master station observations. If you want to do real-time, goGPS MATLAB currently only supports a RTCM stream coming from a server or an NTRIP caster. goGPS Java, on the other hand, only requires to set up an observation stream for the rover and one for the master, independently from the data format, so both could be set to receive observations from u-blox receivers (but I never tried).

Cheers,
Ege

Comment from Thorsten
Time 2013/06/07 at 15:51

Hi Ege,

Alex’ question would be also of interest to me, since vrs-signals are here (in Germany) quite expensive (more than 1-2000€/a) it makes no sense to have a low-cost GPS-rover with a high-cost base.
What accuracies can be expected with having e.g. an u-Blox Lea-4T as rover as well as a base-station (there are quite some free NTRIP-casters and servers or server-and-caster in one out there to download)?

Regards
Thorsten