Don't run final optimization in visualize_pbstream.launch - #1157
Conversation
Replaces the offline node with the normal node. The problem is that the offline node immediately runs a final optimization with `visualize_pbstream.lua`, which is most likely not the configuration that was used to generate the pbstream. This can lead to effects like distortions in the map e.g. due to different weights, even though the actual saved state is fine.
|
You only get a warning now that there are no input topics, but this can safely ignored. Note: I think I already tried this and it didn't work a few months ago before #1089 was merged, because back then the node couldn't finish trajectories that were just waiting for their topics. But now the node terminates cleanly ;) |
|
If you do not intend to optimize the loaded trajectory, why not freeze it instead? |
Then the constraints wouldn't be displayed. |
|
Hmm, I see. I still feel loading an unfrozen trajectory for this purpose is not a robust solution, because the moment it gets optimized, it will get screwed up. I see two things which would both help to solve this robustly. The first would be to indeed load it frozen. Not loading the constraints for frozen trajectories is a memory saving-optimization, and perhaps deserves an option to disable it. The second would be to able to ensure the same pose graph options are loaded. I actually implemented this in a private branch and it works well; if there's interest, we can look into upstreaming it. The idea is that the complete node options (including the map builder options) are stored in the .pbstream header, like I envisioned in this rfc from some time ago. You would then be able to tell Cartographer to use the node configuration from the .pbstream header instead of a new configuration_basename. |
Yes, however: when would that happen? Unless there's sensor input it just does nothing. The only scenario I could think of is that you have a sensor publisher publishing the expected topics in parallel and the "visualization node" starts SLAMing, but this can be blocked by dropping all sensor data of the parent config
Unless there's another benefit I wouldn't want to change API only for this simple visualization tool...
This sounds useful, regardless of this PR. |
|
With the online node, instead of setting the sampler ratios to zero, I think it would make more sense just not to start the default trajectory. This is controlled by the flag |
|
Thanks, I forgot about this option. Then it also doesn't warn about waiting for topics. |
|
@gaschler merge? |
|
Related to my previous comment: cartographer-project/rfcs#38 |
…er-project#1157) * Don't run final optimization in visualize_pbstream.launch Replaces the offline node with the normal node. The problem is that the offline node immediately runs a final optimization with `visualize_pbstream.lua`, which is most likely not the configuration that was used to generate the pbstream. This can lead to effects like distortions in the map e.g. due to different weights, even though the actual saved state is fine. * Drop all /echoes or /imu messages. * Use -start_trajectory_with_default_topics=false
…er-project#1157) * Don't run final optimization in visualize_pbstream.launch Replaces the offline node with the normal node. The problem is that the offline node immediately runs a final optimization with `visualize_pbstream.lua`, which is most likely not the configuration that was used to generate the pbstream. This can lead to effects like distortions in the map e.g. due to different weights, even though the actual saved state is fine. * Drop all /echoes or /imu messages. * Use -start_trajectory_with_default_topics=false
4 participants
Replaces the offline node with the normal node.
The problem is that the offline node immediately runs a final
optimization with
visualize_pbstream.lua, which is most likely not theconfiguration that was used to generate the pbstream. This can lead to
effects like distortions in the map e.g. due to different weights, even
though the actual saved state is fine.