Resolving Isaac ROS nvblox Invalid Service Type Error

The service call succeeds after loading the Isaac ROS workspace in the same terminal and replacing the shell-relative output path with an absolute path. The screen message The passed service type is invalid points to type discovery in the command-line environment, not to the completed static reconstruction.

What is the terminal error telling you?

The static reconstruction can run correctly while a separate terminal rejects nvblox_msgs/srv/FilePath. Each shell has its own environment. Launching the nvblox node from a configured shell does not automatically configure another shell used for the service call.

The ROS 2 command-line tool must locate the installed interface definition before it can serialize the request. If the terminal has not loaded the workspace, the type token is present in the command but unavailable to the type-support lookup. ROS 2 then reports the type itself as invalid before the request reaches /nvblox_node/save_ply.

Screen observation	Likely layer	What to check
Static reconstruction operates	Node and reconstruction pipeline	Leave the running configuration unchanged
The passed service type is invalid	Calling terminal environment	Load the workspace setup file
Type resolves but the call cannot reach the service	ROS graph or node state	Check service discovery and service name
Call reaches the service but no file appears	File-path or filesystem layer	Use an absolute writable path

Checkpoint: treat this exact message as a terminal-side type-resolution failure until the interface can be resolved in that terminal.

Which workspace setup must the terminal load?

Load the generated setup script from the installed Isaac ROS workspace:

source /workspaces/isaac_ros-dev/install/setup.bash

Run this command in the same terminal that will execute ros2 service call. Sourcing modifies the current shell; running it elsewhere does not repair the environment of an already-open command terminal.

Setting	Location	Effect
/workspaces/isaac_ros-dev/install/setup.bash	Calling terminal	Adds the installed workspace resources to the shell environment
nvblox_msgs/srv/FilePath	Service-call type argument	Selects the request interface that ROS 2 must resolve
/nvblox_node/save_ply	ROS graph	Identifies the save service

If the setup file cannot be sourced, first check that the workspace has an install directory and that the path matches the workspace used to build the running system. Do not substitute a guessed workspace path; locate the actual generated setup file.

Checkpoint: in the calling terminal, verify that ROS 2 can resolve nvblox_msgs/srv/FilePath before changing the service request.

How should the save path be written?

Pass an absolute filesystem path in file_path:

/workspaces/isaac_ros-dev/super_cool_map.ply

Do not use ~/workspaces/isaac_ros-dev/super_cool_map.ply. Tilde expansion is performed by a shell only when the tilde appears in a shell-expandable position. Here the path sits inside a quoted YAML request, so it can reach the service as a literal character instead of the user’s home directory.

The original path also contains an unexpected > before isaac_ros-dev. That character changes the requested filename or directory text and must not appear in the corrected path.

Path form	Interpretation	Use
~/workspaces/isaac_ros-dev/super_cool_map.ply	May retain a literal tilde inside the request	No
~/workspaces/>isaac_ros-dev/super_cool_map.ply	Also contains an unintended greater-than character	No
/workspaces/isaac_ros-dev/super_cool_map.ply	Unambiguous absolute destination	Yes

Checkpoint: confirm that the selected directory exists and that the process running the service can write there.

What is the corrected service-call sequence?

1. Open the terminal that will make the request.
2. Load the installed workspace:

   source /workspaces/isaac_ros-dev/install/setup.bash

3. Confirm that the nvblox node providing the save service is running.
4. Call the service with the exact service type and an absolute output path:

   ros2 service call /nvblox_node/save_ply nvblox_msgs/srv/FilePath "{file_path: '/workspaces/isaac_ros-dev/super_cool_map.ply'}"

The outer double quotes keep the YAML request together as one command argument. The inner single quotes delimit the path value. This arrangement avoids splitting the request at spaces and passes the field as a string.

Both an already-configured terminal and a newly opened terminal followed by the source command can work. Explicitly sourcing the workspace immediately before commissioning is preferable because it makes the command’s dependency visible and removes doubt about which overlay the shell loaded.

Checkpoint: the command must progress beyond The passed service type is invalid. If that exact message remains, the active shell still cannot locate the installed interface.

Where should troubleshooting continue if the message changes?

A changed error is useful: it shows that type parsing advanced to another layer. Follow the request from type, to graph, to server, to filesystem instead of changing several settings at once.

Result after sourcing	Diagnostic target	Action
Same invalid-type message	Workspace installation or shell overlay	Check the sourced file and verify that the interface package exists in that installation
Service unavailable or not found	ROS graph	Check that the nvblox node is running and advertises /nvblox_node/save_ply
Request is rejected	Request schema	Retain the file_path field and inspect the installed interface definition
Call completes but no PLY file appears	Destination and permissions	Inspect the exact absolute path and directory write access

Do not diagnose a file-permission problem from the invalid-service-type message. Type validation occurs before the server can process file_path. Conversely, once type resolution succeeds, repeatedly sourcing the shell will not correct a missing service or an unwritable directory.

Checkpoint: identify the first layer that fails and change only the configuration owned by that layer.

How do you verify the fix end to end?

1. Start with the static reconstruction operating normally.
2. In the calling terminal, source /workspaces/isaac_ros-dev/install/setup.bash.
3. Verify that /nvblox_node/save_ply is present and associated with nvblox_msgs/srv/FilePath.
4. Issue the corrected request using /workspaces/isaac_ros-dev/super_cool_map.ply.
5. Confirm that the terminal no longer prints The passed service type is invalid.
6. Check the exact destination for super_cool_map.ply and verify that the file is readable as the expected PLY output.

A terminal response alone proves that the request was accepted, not that the intended artifact exists at the intended location. The file check closes the chain from shell environment through interface discovery, service execution, and filesystem output.

FAQ