Bringing back the discussion about GPS's, did y'all ever calculate the covariance of x, y, and z for your GPS, because I noticed it was a todo in the code.  And further more does it matter?  We are going to be putting it into the extended kalman filter provided by ROS, but I am unsure how important these values are for the GPS data.  Our GPS has a dynamic kalman filter mode, but does not publish the covariance, it just transparently improves the accuracy given some information about maximum acceleration and/or velocity of the vehicle (they are grouped like walking, boat, car, ariplane, etc).

Any insight would be appreciated.

Thanks,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William Woodall
Undergraduate Software Engineering
Auburn University
w@auburn.edu
wjwwood@gmail.com
256-345-9938
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


On Thu, Apr 29, 2010 at 11:06 AM, Jack O'Quin <jack.oquin@gmail.com> wrote:
On Wed, Apr 28, 2010 at 10:32 AM, Ken Tossell <ktossell@umd.edu> wrote:
> We've been using a message based on gpsd's gps_data_t. It should have
> all of the fields you'd need for any GPS device, but it's pretty big:
>
> http://www.ros.org/doc/api/gpsd_client/html/msg/GPSStatus.html

I was not aware of that message, thanks for mentioning it.

As you say, it seems to have all we'd need. Providing all the gpsd
information is a good proof of concept. That looks like a good
starting point for a shared ROS message definition.

For me, the imbedded GPSFix message would nearly suffice. It could be
published on a separate topic, I suppose.

I chose to add the UTM easting, northing and zone to our GpsInfo
message. That is obviously unnecessary since those data can be
computed from the raw latitude and longitude by anyone interested.
But, it's a bit of a pain to do that, so I added those fields for our
own convenience. They should *not* be included in any general-purpose
GPS messages.

I also included the "quality" field from the Player message. That is
useful for detecting when differential GPS is or is not available.
That seems to correspond to the gps_data_t status field of <gps.h>,
but not the gps_fix_t mode field.

It seems slightly odd that GPSStatus has two Header fields (including
the one in GPSFix), but that makes it easy to publish GPSFix
separately. Perhaps the other status fields could be published by
themselves in a separate topic with the same time stamp. Then only
those needing the extra information would see it and there would be no
message passing overhead if no other node subscribed to it.
--
 joq
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users