Re: [ros-users] robot_pose_ekf /vo input units

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
Delete this message
Reply to this message
Author: William Woodall
Date:  
To: ros-users
Subject: Re: [ros-users] robot_pose_ekf /vo input units
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


256-345-9938
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


On Thu, Apr 29, 2010 at 11:06 AM, Jack O'Quin <> wrote:

> On Wed, Apr 28, 2010 at 10:32 AM, Ken Tossell <> 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
>
> https://code.ros.org/mailman/listinfo/ros-users
>