#666 GPS speed, course made good and time


This patch adds support for speed and course made good extracted from RMC strings as well as better time precision if available in RMC strings (for these RTK GPS units).

1 Attachments


  • Rich Mattes

    Rich Mattes - 2013-06-29

    Thanks for the contribution. I'm applying this patch with two changes:

    1) I put the recording of the new fields at the end of the logfile line in writelog, and in readlog the code checks to see whether or not the two fields are present in the log its reading. This small change allows us to keep backwards compatibility with reading logfiles generated in Player 3.0.2 and lower, while taking advantage of new fields in the Player 3.1. Similarly, old versions of Player will be able to read new logfiles and will ignore the extra log file entries.

    2) I changed the convention so that the speed is stored in the interface as meters/second instead of knots. This means that the driver is now responsible for the conversion rather than the client libraries. That way, the gps speed is consistent with speeds from other interfaces (like position interfaces). In light of this, I'm not sure whether it makes sense to keep course as degrees or change it to be radians like yaw angles from other interfaces.

  • flabrosse

    flabrosse - 2013-09-30


    Has this been applied? I can't see it in a just updated working copy.

    I thought I had responded to the question under #2 above, but clearly have not. So here it is again. Although the course has a different meaning than the yaw, I guess that for consistency reasons it does make sense to convert that to radians.



  • Rich Mattes

    Rich Mattes - 2013-10-06

    It hasn't been applied yet, I was waiting for a response then it kind of slipped my mind. I'll make sure that the course is in radians and commit it with the rest of the changes I outlined above.

  • Rich Mattes

    Rich Mattes - 2013-10-06

    Commited as 9124. Please double-check to make sure it works for you.

  • flabrosse

    flabrosse - 2013-10-16

    I haven't yet tested it, but looking at the code, the course conversion "simply" converts from degrees to radians (*pi/180). The course is a value between 0 and 360, positive from north to east (I believe, I'm no expert in sailing). The usual radian convention is to have a value between -pi and pi, positive to the left (ie the other way from course), as on the trigonometric circle. Should that be made like that?

  • Rich Mattes

    Rich Mattes - 2013-11-10

    I think that's probably a good idea. That way the GPS course can be used in the same context as other robot yaw measurements without conversion. I uploaded the following conversion as r9132:

    course = (2.0 * M_PI - course) + M_PI/2.0; // Convert from NED to ENU
    if (course > M_PI) {
    course = course - 2.0 * M_PI;

    That conversion first flips the sign of the angle so that positive is to the left, and then offsets by pi / 2 to account for the 90 degree rotation between the positive Y and positive X axes. Then it subtracts 2pi from any angle above pi.

  • Rich Mattes

    Rich Mattes - 2014-02-16
    • status: open --> closed-accepted
    • assigned_to: Rich Mattes
    • Group: Unstable --> Release-3.1
  • Rich Mattes

    Rich Mattes - 2014-02-16

    I think we're good to go here, so I'm going to close this report as accepted. If there are still issues let me know by re-opening or by filing a new report.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks