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).
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Cheers,
Fred
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Hi,
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.
Cheers,
Fred
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.
Commited as 9124. Please double-check to make sure it works for you.
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?
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.
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.