gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
humble

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
jazzy

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
kilted

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
lyrical

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
rolling

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

No version for distro ardent showing humble. Known supported distros are highlighted in the buttons above.

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
humble

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

No version for distro bouncy showing humble. Known supported distros are highlighted in the buttons above.

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
humble

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

No version for distro crystal showing humble. Known supported distros are highlighted in the buttons above.

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
humble

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

No version for distro eloquent showing humble. Known supported distros are highlighted in the buttons above.

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
humble

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

No version for distro dashing showing humble. Known supported distros are highlighted in the buttons above.

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
humble

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

No version for distro galactic showing humble. Known supported distros are highlighted in the buttons above.

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
humble

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

No version for distro foxy showing humble. Known supported distros are highlighted in the buttons above.

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
humble

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

gps_umd repository

gps_msgs gps_tools gps_umd gpsd_client

ROS Distro
iron

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	ros2-devel
Last Updated	2026-09-20
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_msgs	3.1.1
gps_tools	3.1.1
gps_umd	3.1.1
gpsd_client	3.1.1

README

gps_umd

This package contains messages for representing data from GPS devices and algorithms for manipulating it. It uses GPSd as the underlying method of reading data from GPS receivers.

GPSd Integration and Usage

By default, this package is built against the version of GPSd shipped with the Linux distribution the underlying ROS 2 software is built against. However, the gps_umd package supports building against arbitrary versions of GPSd and matching its behavior to the GPSd API version supplied by the library.

Depending on the GPS receiver, GPSd is capable of providing a great deal of information. By default, the package publishes a condensed version of this data as a gps_msgs/GPSFix message. Alternatively, the information may be published as a standard ROS 2 sensor_msgs/NavSatFix message. These messages provide the localization and error estimates that most robots need to operate in most conditions.

gps_umd can also publish the entire set of information provided by GPSd. These messages are in the gps_msgs package and published as GPSDRaw<MAJOR>v<MINOR> types, where <MAJOR> and <MINOR> correspond to the GPSd API version that provides the information. The table below lists the currently support set of GPSd and API versions the system is built and tested against.

Three GPSd API versions are not matched to a GPSd version. These GPSd versions are given as their commit hash instead. To add more version of the GPSd API, see: docs/adding-a-gpsd-api-version.md.

gpsd_client Parameters

Both gpsd_client components (see Managed (lifecycle) Node) accept the following parameters. Some are used to configure GPSd, and others are used to work around quirks of GPSd with certain hardware. In general, gps_umd attempts to retain the behavior of GPSd as much as possible, and deviate only to match ROS 2 conventions and robot needs.

Parameter	Type	Default	Description
`host`	string	`localhost`	Hostname or address of the GPSd server to connect to.
`port`	int	`2947`	TCP port of the GPSd server.
`frame_id`	string	`gps`	`frame_id` set on the header of published `GPSFix` and `NavSatFix` messages.
`publish_rate`	int	`10`	How often, in Hz, to poll GPSd and publish. Values `<= 0` are rejected with a warning and fall back to 1 Hz.
`use_gps_time`	bool	`true`	Stamp `NavSatFix` messages with the time reported by the GPS receiver instead of the current ROS time.
`check_fix_by_variance`	bool	`false`	Discard fixes whose reported variances (`epx`/`epy`/`epv`) are not finite. GPSd reports a status of OK even when there is no current fix, as long as there was one previously; this rejects those stale results.
`override_augmentation_source`	bool	`false`	When GPSd reports a DGPS fix, always report it as an SBAS fix, whether or not a satellite with an SBAS ID was used in the solution. Useful for receivers that apply SBAS corrections without listing the SBAS satellite in their skyview. Affects both `NavSatFix` and `GPSFix` status.
`publish_gpsd_raw`	bool	`false`	Also publish a near-verbatim mirror of GPSd’s `gps_data_t` on `gpsd_raw`, in a message named after the libgps API this package was built against. Off by default: the message is much larger than `GPSFix`, and neither the publisher nor its parser is created unless this is set.
`publish_gpsd_json`	bool	`false`	Publish every report GPSd sends on `gpsd_json`, as the raw JSON line. This contains much more than the information published on `gpsd_raw`, such as RTCM and SUBFRAME data. Only AIS information from GPSd is intentionally omitted.

These node defaults can be overriden by setting a parameter. The file gpsd_client/config/gpsd_client.yaml contains these parameters as well. The launch file gpsd_client-launch.py can load these YAML files for convenience.

Managed (lifecycle) Node

gpsd_client ships two components. They are the same client, take the same parameters and publish the same topics; they differ only in when the node connects to GPSd and starts publishing.

Component	Node type	Behavior
`gpsd_client::GPSDClientComponent`	`rclcpp::Node`	Connects and publishes as soon as it is constructed, until it is destroyed. This is the default behavior.
`gpsd_client::GPSDClientLifecycleComponent`	`rclcpp_lifecycle::LifecycleNode`	Starts unconfigured and does nothing until something drives it through the managed node transitions.

The launch file picks one:

ros2 launch gpsd_client gpsd_client-launch.py                      # unmanaged
ros2 launch gpsd_client gpsd_client-launch.py use_lifecycle:=true  # managed lifecycle

A managed node publishes nothing until it is told to. Nothing transitions it on its own, so either a lifecycle manager or a person has to:

ros2 lifecycle set /gpsd_client configure
ros2 lifecycle set /gpsd_client activate

The transitions follow the two phases libgps already has – one call to connect, another to start the flow of reports.

Transition	What it does
`configure`	Reads the parameters, creates the parsers and publishers, and connects to GPSd (`gps_open`). An unreachable daemon fails this transition and leaves the node unconfigured, rather than leaving a node that exists but never publishes.
`activate`	Asks GPSd to stream (`gps_stream(WATCH_ENABLE)`) and starts polling it. The publishers, which drop messages while inactive, begin publishing.
`deactivate`	Stops polling and stops the stream, but holds the connection open so reactivating it does not force a reconnect.
`cleanup`	Destroys the publishers and parsers and closes the connection (`gps_close`), returning the node to unconfigured.
`shutdown`	Deactivates and cleans up, from whatever state the node is in.

Parameters are declared when the node is constructed but read during configure, so a parameter changed on a running node takes effect on the next cleanup / configure cycle.

Raw GPSd Details

With publish_gpsd_raw set, gpsd_client publishes everything GPSd reports on gpsd_raw, as close to verbatim as a ROS message allows. The type is named after the GPSd C API the package compiled against — gps_msgs/GPSDRaw<MAJOR>v<MINOR>. publish_gpsd_json adds gpsd_json, carrying every report as the raw JSON line generated by GPSd, including the RTCM and SUBFRAME information.

tools/generate_raw_msgs.py automatically converts the data structures in GPSd to these messages and their parsers.

These messages are complex due to the volume of information contained within them and how C structs and unions are mapped to ROS 2 message datatypes. There are also bugs and quirks in different GPSd versions that further complicate this translation. For more information, see the documentation in the following files.

docs/gpsd-raw-message-structure.md message layout and what changes between API versions
docs/gpsd-quirks.md — GPSd behaviours worth knowing before subscribing

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

File truncated at 100 lines see the full file

CONTRIBUTING

gps_umd repository

gps_common gps_umd gpsd_client

ROS Distro
lunar

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	master
Last Updated	2024-05-15
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_common	0.3.4
gps_umd	0.3.4
gpsd_client	0.3.4

README

gps_umd

This package is a space to stage messages and common GPS-processing routines. The previous maintainer has not released these packages since ROS Indigo; this fork was created in order to fix them up and release them for ROS Jade and Kinetic.

One change of note is that in the version of libgps in Ubuntu 16.04, the STATUS_DGPS_FIX flag was removed, so the gpsd_client package will be unable to indicate whether DGPS was used in a fix or not.

Otherwise, the API is unchanged; see http://wiki.ros.org/gps_common .

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from NavSatFix to GPSFix //-->
      <remap from="/navsat_fix_in"  to="/YOUR_NAVSATFIX_TOPIC"/>
      <remap from="/gps_fix_out"    to="/YOUR_GPSFIX_TOPIC"/>
  </node>

Translate from GPSFix to NavSatFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from GPSFix to NavSatFix //-->
       <remap from="/gps_fix_in"     to="/YOUR_GPSFIX_TOPIC"/>
       <remap from="/navsat_fix_out" to="/YOUR_NAVSATFIX_TOPIC"/>
  </node>

Only adjust the topic names after “to=” in each remap line.

CONTRIBUTING

gps_umd repository

gps_common gps_umd gpsd_client

ROS Distro
jade

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	master
Last Updated	2024-05-15
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_common	0.3.4
gps_umd	0.3.4
gpsd_client	0.3.4

README

gps_umd

This package is a space to stage messages and common GPS-processing routines. The previous maintainer has not released these packages since ROS Indigo; this fork was created in order to fix them up and release them for ROS Jade and Kinetic.

One change of note is that in the version of libgps in Ubuntu 16.04, the STATUS_DGPS_FIX flag was removed, so the gpsd_client package will be unable to indicate whether DGPS was used in a fix or not.

Otherwise, the API is unchanged; see http://wiki.ros.org/gps_common .

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from NavSatFix to GPSFix //-->
      <remap from="/navsat_fix_in"  to="/YOUR_NAVSATFIX_TOPIC"/>
      <remap from="/gps_fix_out"    to="/YOUR_GPSFIX_TOPIC"/>
  </node>

Translate from GPSFix to NavSatFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from GPSFix to NavSatFix //-->
       <remap from="/gps_fix_in"     to="/YOUR_GPSFIX_TOPIC"/>
       <remap from="/navsat_fix_out" to="/YOUR_NAVSATFIX_TOPIC"/>
  </node>

Only adjust the topic names after “to=” in each remap line.

CONTRIBUTING

gps_umd repository

gps_common gps_umd gpsd_client

ROS Distro
indigo

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	master
Last Updated	2024-05-15
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_common	0.3.4
gps_umd	0.3.4
gpsd_client	0.3.4

README

gps_umd

This package is a space to stage messages and common GPS-processing routines. The previous maintainer has not released these packages since ROS Indigo; this fork was created in order to fix them up and release them for ROS Jade and Kinetic.

One change of note is that in the version of libgps in Ubuntu 16.04, the STATUS_DGPS_FIX flag was removed, so the gpsd_client package will be unable to indicate whether DGPS was used in a fix or not.

Otherwise, the API is unchanged; see http://wiki.ros.org/gps_common .

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from NavSatFix to GPSFix //-->
      <remap from="/navsat_fix_in"  to="/YOUR_NAVSATFIX_TOPIC"/>
      <remap from="/gps_fix_out"    to="/YOUR_GPSFIX_TOPIC"/>
  </node>

Translate from GPSFix to NavSatFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from GPSFix to NavSatFix //-->
       <remap from="/gps_fix_in"     to="/YOUR_GPSFIX_TOPIC"/>
       <remap from="/navsat_fix_out" to="/YOUR_NAVSATFIX_TOPIC"/>
  </node>

Only adjust the topic names after “to=” in each remap line.

CONTRIBUTING

gps_umd repository

gps_common gps_umd gpsd_client

ROS Distro
hydro

Repository Summary

Checkout URI	https://github.com/ktossell/gps_umd.git
VCS Type	git
VCS Version	master
Last Updated	2014-06-20
Dev Status	UNMAINTAINED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_common	0.1.7
gps_umd	0.1.7
gpsd_client	0.1.7

README

No README found.

CONTRIBUTING

gps_umd repository

gps_common gps_umd gpsd_client

ROS Distro
kinetic

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	master
Last Updated	2024-05-15
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_common	0.3.4
gps_umd	0.3.4
gpsd_client	0.3.4

README

gps_umd

This package is a space to stage messages and common GPS-processing routines. The previous maintainer has not released these packages since ROS Indigo; this fork was created in order to fix them up and release them for ROS Jade and Kinetic.

One change of note is that in the version of libgps in Ubuntu 16.04, the STATUS_DGPS_FIX flag was removed, so the gpsd_client package will be unable to indicate whether DGPS was used in a fix or not.

Otherwise, the API is unchanged; see http://wiki.ros.org/gps_common .

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from NavSatFix to GPSFix //-->
      <remap from="/navsat_fix_in"  to="/YOUR_NAVSATFIX_TOPIC"/>
      <remap from="/gps_fix_out"    to="/YOUR_GPSFIX_TOPIC"/>
  </node>

Translate from GPSFix to NavSatFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from GPSFix to NavSatFix //-->
       <remap from="/gps_fix_in"     to="/YOUR_GPSFIX_TOPIC"/>
       <remap from="/navsat_fix_out" to="/YOUR_NAVSATFIX_TOPIC"/>
  </node>

Only adjust the topic names after “to=” in each remap line.

CONTRIBUTING

gps_umd repository

gps_common gps_umd gpsd_client

ROS Distro
melodic

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	master
Last Updated	2024-05-15
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_common	0.3.4
gps_umd	0.3.4
gpsd_client	0.3.4

README

gps_umd

This package is a space to stage messages and common GPS-processing routines. The previous maintainer has not released these packages since ROS Indigo; this fork was created in order to fix them up and release them for ROS Jade and Kinetic.

One change of note is that in the version of libgps in Ubuntu 16.04, the STATUS_DGPS_FIX flag was removed, so the gpsd_client package will be unable to indicate whether DGPS was used in a fix or not.

Otherwise, the API is unchanged; see http://wiki.ros.org/gps_common .

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from NavSatFix to GPSFix //-->
      <remap from="/navsat_fix_in"  to="/YOUR_NAVSATFIX_TOPIC"/>
      <remap from="/gps_fix_out"    to="/YOUR_GPSFIX_TOPIC"/>
  </node>

Translate from GPSFix to NavSatFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from GPSFix to NavSatFix //-->
       <remap from="/gps_fix_in"     to="/YOUR_GPSFIX_TOPIC"/>
       <remap from="/navsat_fix_out" to="/YOUR_NAVSATFIX_TOPIC"/>
  </node>

Only adjust the topic names after “to=” in each remap line.

CONTRIBUTING

gps_umd repository

gps_common gps_umd gpsd_client

ROS Distro
noetic

Repository Summary

Checkout URI	https://github.com/swri-robotics/gps_umd.git
VCS Type	git
VCS Version	master
Last Updated	2024-05-15
Dev Status	DEVELOPED
Released	RELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
gps_common	0.3.4
gps_umd	0.3.4
gpsd_client	0.3.4

README

gps_umd

This package is a space to stage messages and common GPS-processing routines. The previous maintainer has not released these packages since ROS Indigo; this fork was created in order to fix them up and release them for ROS Jade and Kinetic.

One change of note is that in the version of libgps in Ubuntu 16.04, the STATUS_DGPS_FIX flag was removed, so the gpsd_client package will be unable to indicate whether DGPS was used in a fix or not.

Otherwise, the API is unchanged; see http://wiki.ros.org/gps_common .

NavSatFix vs. GPSFix

The node fix_translator converts sensor_msgs/NavSatFix messages to gps_common/GPSFix messages and vice versa. Usage examples:

Translate from NavSatFix to GPSFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from NavSatFix to GPSFix //-->
      <remap from="/navsat_fix_in"  to="/YOUR_NAVSATFIX_TOPIC"/>
      <remap from="/gps_fix_out"    to="/YOUR_GPSFIX_TOPIC"/>
  </node>

Translate from GPSFix to NavSatFix

  <node name="fix_translator" pkg="gps_common" type="fix_translator">
    <!-- Translate from GPSFix to NavSatFix //-->
       <remap from="/gps_fix_in"     to="/YOUR_GPSFIX_TOPIC"/>
       <remap from="/navsat_fix_out" to="/YOUR_NAVSATFIX_TOPIC"/>
  </node>

Only adjust the topic names after “to=” in each remap line.

gps_umd repository

ROS Distrohumble

Repository Summary

Packages

README

gps_umd

GPSd Integration and Usage

gpsd_client Parameters

Managed (lifecycle) Node

Raw GPSd Details

NavSatFix vs. GPSFix

Translate from NavSatFix to GPSFix

CONTRIBUTING

gps_umd repository

ROS Distrojazzy

Repository Summary

Packages

README

gps_umd

GPSd Integration and Usage

gpsd_client Parameters

Managed (lifecycle) Node

Raw GPSd Details

NavSatFix vs. GPSFix

Translate from NavSatFix to GPSFix

CONTRIBUTING

gps_umd repository

ROS Distrokilted

Repository Summary

Packages

README

gps_umd

GPSd Integration and Usage

gpsd_client Parameters

Managed (lifecycle) Node

Raw GPSd Details

NavSatFix vs. GPSFix

Translate from NavSatFix to GPSFix

CONTRIBUTING

gps_umd repository

ROS Distrolyrical

Repository Summary

Packages

README

gps_umd

GPSd Integration and Usage

gpsd_client Parameters

Managed (lifecycle) Node

Raw GPSd Details

NavSatFix vs. GPSFix

Translate from NavSatFix to GPSFix

CONTRIBUTING

gps_umd repository

ROS Distrorolling

Repository Summary

Packages

README

gps_umd

GPSd Integration and Usage

gpsd_client Parameters

Managed (lifecycle) Node

Raw GPSd Details

NavSatFix vs. GPSFix

Translate from NavSatFix to GPSFix

CONTRIBUTING

gps_umd repository

ROS Distrohumble

Repository Summary

Packages

README

gps_umd

GPSd Integration and Usage

gpsd_client Parameters

Managed (lifecycle) Node

Raw GPSd Details

NavSatFix vs. GPSFix

Translate from NavSatFix to GPSFix

CONTRIBUTING

gps_umd repository

ROS Distrohumble

ROS Distro
humble

ROS Distro
jazzy

ROS Distro
kilted

ROS Distro
lyrical

ROS Distro
rolling

ROS Distro
humble

ROS Distro
humble

ROS Distro
humble

ROS Distro
humble

ROS Distro
humble

ROS Distro
humble

ROS Distro
humble