Posted by @Villy01:
I deployed following the entire procedure described, but when I access the link to view the dashboard, I see a blank screen and the following errors in the console:
GET https://rmf.test/assets/index-CKkERlec.css net::ERR_ABORTED 404 (Not Found)
GET https://rmf.test/assets/index-BWe4IXhq.js net::ERR_ABORTED 404 (Not Found)
However, if I search for the file at this path, I can see it:
https://rmf.test/dashboard/assets/index-BWe4IXhq.js
It’s seems there is an error in the structure of the dashboard, did someone have the same issue?
The steps to produce this problem:
- Build docker images manually, with
docker build in every directory with a dockerfile
- follow readme to install and set up everything
- do a manual deployment via helm
- search on browser https://rmf.test/dashboard
Deploy monitoring stack command
helm install -n=monitoring --create-namespace rmf-monitoring charts/monitoring
Install rmf stack command
helm install -n=rmf --create-namespace rmf charts/rmf-deployment
Edited by @Villy01 at 2025-02-20T11:50:14Z
Posted by @akash-roboticist:
Hello @Villy01 , to isolate any build issues, could you test with the pre-built images ?
Posted by @Villy01:
Hi @akash-roboticist , thank you for the answer. That’s exactly what i was testing and i ended up with the same issue, these are the steps:
- clone the git repo
git clone git@github.com:open-rmf/rmf_deployment_template.git
- deploy infrastructure
cd rmf_deployment_template/charts/
./infrastructure/tools/helm_charts_build.bash
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
helm install -n=infra --create-namespace rmf-infra infrastructure
- add my cluster’s IP to
/etc/hosts to point to be able to resolve the address
- create and get the ca
kubectl apply -f devel/certs.yaml
kubectl -n=infra get secrets rmf-dev-secret --template='{{index .data "ca.crt"}}' | base64 -dw0 > ca.crt
- deploy monitoring stack
helm install -n=monitoring --create-namespace rmf-monitoring charts/monitoring
- install rmf stack
helm install -n=rmf --create-namespace rmf charts/rmf-deployment
- wait for keycloak to be ready
kubectl -n=rmf wait --for=condition=Complete --timeout=5m jobs keycloak-setup
- check that everything is ok
kubectl get pods --all-namespaces
- browse
http://rmf.test/dashboard (or http://rmf.test/dashboard/login ) , white screen and those errors in console
Additional information:
- If i browse
https://rmf.test/grafana/login i correctly see Grafana’s login page
- I try to browse
https://rmf.test/dashboard/assets/index-CKkERlec.css and i see the file, so i try to manually change dashboard’s html:
- open a shell in the pod
kubectl exec -it deployment/rmf-web-dashboard -n rmf -- /bin/bash
cd /usr/share/nginx/html/dashboard- modify the index.html from
<script type="module" crossorigin src="/assets/index-BWe4IXhq.js"></script>
<link rel="stylesheet" crossorigin href="/assets/index-CkkERlec.css">
to
<script type="module" crossorigin src="/dashboard/assets/index-BWe4IXhq.js"></script>
<link rel="stylesheet" crossorigin href="/dashboard/assets/index-CkkERlec.css">
- browse
http://rmf.test/dashboard , again white screen but different errors:
GET https://rmf.test/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/step1.html 404 (Not Found)WebSocket connection to 'wss://rmf.test/__TRAJECTORY_SERVER_URL__' failed: Error during WebSocket handshake: Unexpected response code: 404
Edited by @Villy01 at 2025-02-21T08:58:32Z
Posted by @aaronchongth:
The reason why __KEYCLOAK_URL__ and __TRAJECTORY_SERVER_URL__ shows up, is because the string replacement does not seem to be happening at start-time. The dashboard docker image injects variables to replace these placeholder strings with the accurate URLs, rmf_deployment_template/dockerfiles/rmf-web/dashboard/Dockerfile at main · open-rmf/rmf_deployment_template · GitHub
The deployment charts set these environment variables when launching the pods, rmf_deployment_template/charts/rmf-deployment/templates/rmf-web.yaml at main · open-rmf/rmf_deployment_template · GitHub. These values are also filled using baseUrl which should already be present in your values.yaml, rmf_deployment_template/charts/rmf-deployment/values.yaml at main · open-rmf/rmf_deployment_template · GitHub
You can try to isolate what the issue is by launching the dashboard docker image on it’s own and setting the environment variables manually.
Posted by @Villy01:
The environment variables are setted correctly in the image, i can see them accessing the pod, but it seems that in static files like index-BWe4IXhq.js they aren’t replaced.
I tried to replace them manually and previous error disappear (GET https://rmf.test/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/step1.html 404 (Not Found)), but i still have this one: WebSocket connection to 'wss://rmf.test/trajectory' failed: Error during WebSocket handshake: Unexpected response code: 404.
Moreover, after replacing variables, some element of the dashboard appear, but i have in browser’s console lot of 404 error for .css files not found. Nginx configuration expose these file at /dashboard/assets/, but index-CKkERlec.css search for them at https://rmf.test/assets/<filename>.
Posted by @Villy01:
I’m sorry but i don’t understand if i did something wrong in the deployment phase or there is an error in the images. Is there something i need to change in configuration files befor the deployment if i want to use pre built images from ghcr.io/open-rmf/rmf_deployment_template?
Posted by @aaronchongth:
The environment variable injection was broken since we shifted to a dashboard framework, I’ve started a potential fix and have verified that the variables are replaced by environment variables correctly now, Deployment template dashboard by aaronchongth · Pull Request #49 · open-rmf/rmf_deployment_template · GitHub
but i still have this one: WebSocket connection to ‘wss://rmf.test/trajectory’ failed: Error during WebSocket handshake: Unexpected response code: 404.
This might be due to the trajectory server not running, can you verify that the RMF trajectory server pod is running?
i have in browser’s console lot of 404 error for .css files not found. Nginx configuration expose these file at /dashboard/assets/, but index-CKkERlec.css search for them at https://rmf.test/assets/.
This is most likely due to the same migration changes faced by the variable injection. Still looking into this, will provide an update here when we get to it. In the meantime, contributions are also welcome! Since you already have a set up running, it might be quicker if you could help fix the nginx configurations or paths where the files are searched for.
Posted by @Villy01:
For errors 404 in console about assets file not found, i can see from browser’s source the dashboard index.html file is this
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<link rel="icon" href="/favicon.ico" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta
name="description"
content="Web application that provides overall visualization and control over the RMF system"
/>
<link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" />
<title>RMF Dashboard</title>
<script type="module" crossorigin src="/assets/index-BWe4IXhq.js"></script>
<link rel="stylesheet" crossorigin href="/assets/index-CKkERlec.css">
</head>
<body>
<div id="root"></div>
</body>
</html>
while the one in dashboard local repo is this
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<link rel="icon" href="%BASE_URL%favicon.ico" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta
name="description"
content="Web application that provides overall visualization and control over the RMF system"
/>
<link rel="shortcut icon" type="image/x-icon" href="%BASE_URL%favicon.ico" />
<title>RMF Dashboard</title>
</head>
<body>
<div id="root"></div>
<script type="module" src="/main.tsx"></script>
</body>
</html>
Errors are generated by these lines
<script type="module" crossorigin src="/assets/index-BWe4IXhq.js"></script>
<link rel="stylesheet" crossorigin href="/assets/index-CKkERlec.css">
I would like to understand how these lines are added and where that path is taken from, because it probably needs to be modified so that all resources are searched in dashboard/assets.
Posted by @aaronchongth:
I would like to understand how these lines are added and where that path is taken from, because it probably needs to be modified so that all resources are searched in dashboard/assets.
These paths are generated during the build process. It should not be modified, since it messes up the hash that is also appended onto the file name.
Can you check out the fixes I’ve started here, Deployment template dashboard by aaronchongth · Pull Request #49 · open-rmf/rmf_deployment_template · GitHub? I’ve verified that string replacement via env vars work, while the issue with the base URL you mentioned should be fixed via the definition in a new vite.config.ts
edit: I’ve verified that with these changes, the paths referenced in the build are all now /dasboard/assets/....
Edited by @aaronchongth at 2025-02-27T05:25:38Z
Posted by @Villy01:
Can you check out the fixes I’ve started here, open-rmf/rmf_deployment_template#49?
I tried to deploy with all the changes indicated here. Indeed, the issues with dashboard/assets paths are no longer present. However, when I try to view the dashboard, I see recursive errors in the browser console. The first one is
WebSocket connection to 'wss://rmf.test/dashboard/__TRAJECTORY_SERVER_URL__' failed: Error during WebSocket handshake: Unexpected response code: 200,
and the subsequent ones are
WebSocket connection to 'wss://rmf.test/dashboard/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/__KEYCLOAK_URL__/realms/rmf-web/protocol/openid-connect/3p-cookies/__TRAJECTORY_SERVER_URL__' failed: Error during WebSocket handshake: Unexpected response code: 200, exc.
All these errors are generated from the same line in the same file index-CfqOx13J.js:353
Edited by @Villy01 at 2025-02-27T13:43:27Z
Posted by @aaronchongth:
this looks like the strings for __TRAJECTORY_SERVER_URL__ and __KEYCLOAK_URL__ have not been replaced. Have those values been set similarly to __RMF_SERVER_URL__? These variable injection mechanism is the same for all these 3 variables, so if the server’s work, these might just not have been set
Posted by @Villy01:
I think there is a permission problem, the file 99-inject-env.sh can’t modify index.html, resulting in placeholders not being changed. The file can be modified by adding this instruction on top of it, giving it write access, in order to correctly set variables:
chmod 664 /usr/share/nginx/html/dashboard/index.html
Posted by @Villy01:
Despite the issues with the environment variables being resolved, I still encountered other errors.
When accessing the dashboard, I see this error in the console, which seems to be the same as the one related to the assets path.
GET https://rmf.test/resources/openrmf_logo.png 404 (Not Found)
Additionally, I’m still experiencing the same error I encountered earlier.
WebSocket connection to 'wss://rmf.test/trajectory' failed: Error during WebSocket handshake: Unexpected response code: 404
This might be due to the trajectory server not running, can you verify that the RMF trajectory server pod is running?
Should there be a specific pod for the trajectory server? Because in my deployment, I don’t see any pod with this name.
Moreover, this address is defined, but I don’t see any definition of an ingress in the code.
name: TRAJECTORY_SERVER_URL value: {{ .Values.baseUrl }}/trajectory
Posted by @aaronchongth:
I think there is a permission problem, the file 99-inject-env.sh can’t modify index.html, resulting in placeholders not being changed. The file can be modified by adding this instruction on top of it, giving it write access, in order to correctly set variables:
That’s odd, my new builds are performing the injection without any permission issues. Can you try building without cache, just in case? Also remember to pull new changes from my branch
# build image
git clone https://github.com/open-rmf/rmf_deployment_template -b fix/paths
cd rmf_deployment_template
. dockerfiles/build-args.sh
docker build -t check-dashboard-resources:latest $DASHBOARD_LOCAL_BUILD_ARGS dockerfiles/rmf-web/dashboard
# start built image without env
docker run check-dashboard-resources:latest
# enter container to check values
docker ps
docker exec -it CONTAINER_NAME_HERE bash
cat /usr/share/nginx/html/dashboard/index.html
# we should see the line `window.RMF_SERVER_URL = "";`
# close all containers
# enter container with env this time
docker run -e RMF_SERVER_URL=http://localhost:8000 check-dashboard-resources:latest
# enter new container to check values
docker ps
docker exec -it CONTAINER_NAME_HERE bash
cat /usr/share/nginx/html/dashboard/index.html
# we should see the line `window.RMF_SERVER_URL = "http://localhost:8000";`
Despite the issues with the environment variables being resolved, I still encountered other errors.
When accessing the dashboard, I see this error in the console, which seems to be the same as the one related to the assets path.
Thanks for flagging that, I’ve fixed where the resources are copied to in my branch.
Should there be a specific pod for the trajectory server? Because in my deployment, I don’t see any pod with this name.
Moreover, this address is defined, but I don’t see any definition of an ingress in the code.
You’re right, it looks like the ingress is missing from rmf_deployment_template/charts/rmf-deployment/templates/rmf-core-modules.yaml at main · open-rmf/rmf_deployment_template · GitHub. Can you help add that in by referencing rmf_deployment_template/charts/rmf-deployment/templates/rmf-web.yaml at main · open-rmf/rmf_deployment_template · GitHub?
Thanks for flagging the issues so far!
Posted by @Villy01:
Thanks for flagging that, I’ve fixed where the resources are copied to in my branch.
The resources are copied correctly, but the path it’s still wrong. It works modifying the path in main.tsx
logos: { header: '/dashboard/resources/openrmf_logo.png' }
You’re right, it looks like the ingress is missing from rmf_deployment_template/charts/rmf-deployment/templates/rmf-core-modules.yaml at main · open-rmf/rmf_deployment_template · GitHub. Can you help add that in by referencing rmf_deployment_template/charts/rmf-deployment/templates/rmf-web.yaml at main · open-rmf/rmf_deployment_template · GitHub?
I tried a bit to implement the ingress, but I didn’t understand if it’s enough to create the ingress or if it’s also necessary to create a pod. In case it’s necessary to create a pod, I wouldn’t know what image and ros commands to put in the pod.
While progressing with the development, when accessing the dashboard, I saw that in the console I get a 404 error because it couldn’t retrieve the building map. This is the error log from from the web server pod
msg="10.42.0.146:56036 - \"GET /rmf/api/v1/ HTTP/1.1\" 404" level="INFO" ts="2025-03-03T17:01:05.936+0000" src="httptools_impl.py:481" funcName="send"
Checking the structure of the pod where the map should be present, I see that everything is in order. Therefore, I can’t understand why the resource is not being found, and I also wouldn’t know how to further investigate the issue.
Posted by @Villy01:
Hi @aaronchongth , could you give me more information about the issue with the map not being retrieved on the dashboard?
Posted by @aaronchongth:
We will need some time to reproduce and verify all the issues mentioned before coming up with a fix. Will provide an update when we get to it.
While progressing with the development, when accessing the dashboard, I saw that in the console I get a 404 error because it couldn’t retrieve the building map. This is the error log from from the web server pod
msg=“10.42.0.146:56036 - "GET /rmf/api/v1/ HTTP/1.1" 404” level=“INFO” ts=“2025-03-03T17:01:05.936+0000” src=“httptools_impl.py:481” funcName=“send”
Checking the structure of the pod where the map should be present, I see that everything is in order. Therefore, I can’t understand why the resource is not being found, and I also wouldn’t know how to further investigate the issue.
Is the building map pod running at the moment? A few ways to debug, would be to check if the API server can indeed receive the building map. A few things I can think of to check at the moment,
- check that the building map pod is running
- exec into the API server pod, perform the usual
ros2 topic list and ros2 topic echo checks to see if the building map topic is reachable
Posted by @aaronchongth:
I’ve just managed to get the cluster up and running. So far, there are a few issues that I’ve found,
- robot icon scale (this is configurable, we’ll have the fix ready)
- trajectory server unreachable, since there is no ingress so this is expected
But other than that, I am able to submit tasks and view map from the dashboard. Depending on your setup at the moment, I suspect that perhaps the building map server pod is not active on your end. I am currently running the cluster according to README instructions, with ENABLE_RMF_SIM: true and ENABLE_RMF: false, where rmf-sim will launch an instance of rmf_demos which will start all the necessary nodes in a single pod, instead of individual pods for each node.
edit: some more logs
aaron@u24:~/rmf_deployment_template$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
argocd argocd-application-controller-0 1/1 Running 0 11h
argocd argocd-applicationset-controller-57778d964f-rphr4 1/1 Running 0 11h
argocd argocd-dex-server-745656cb69-jmz5h 1/1 Running 0 11h
argocd argocd-notifications-controller-bf9944448-6gd8q 1/1 Running 0 11h
argocd argocd-redis-7464595f54-fzfpf 1/1 Running 0 11h
argocd argocd-repo-server-6784487c7f-zjfc5 1/1 Running 0 11h
argocd argocd-server-7dbdcc97b9-46sk7 1/1 Running 0 11h
infra rmf-infra-cert-manager-7496d57b49-jb98n 1/1 Running 1 (134m ago) 11h
infra rmf-infra-cert-manager-cainjector-77fd8869c9-f5xwj 1/1 Running 0 11h
infra rmf-infra-cert-manager-webhook-84987745d7-4j9r9 1/1 Running 0 11h
infra rmf-infra-ingress-nginx-controller-6656cb587f-48qnf 1/1 Running 0 11h
kube-system coredns-ccb96694c-7h5xx 1/1 Running 0 11h
kube-system local-path-provisioner-5b5f758bcf-hfmlz 1/1 Running 0 11h
kube-system metrics-server-7bf7d58749-q56tn 1/1 Running 0 11h
monitoring loki-canary-bldlx 1/1 Running 0 11h
monitoring rmf-monitoring-alertmanager-0 1/1 Running 0 11h
monitoring rmf-monitoring-grafana-6b7955c445-q465g 2/2 Running 0 11h
monitoring rmf-monitoring-kube-state-metrics-59799d5d6d-wfc67 1/1 Running 0 11h
monitoring rmf-monitoring-loki-0 1/1 Running 0 11h
monitoring rmf-monitoring-loki-chunks-cache-0 2/2 Running 0 11h
monitoring rmf-monitoring-loki-gateway-7889cb6c87-x5rng 1/1 Running 0 11h
monitoring rmf-monitoring-loki-results-cache-0 2/2 Running 0 11h
monitoring rmf-monitoring-prometheus-node-exporter-5hhww 1/1 Running 0 11h
monitoring rmf-monitoring-prometheus-pushgateway-797d577f5c-qt5tq 1/1 Running 0 11h
monitoring rmf-monitoring-prometheus-server-758d8d84dc-kp94h 2/2 Running 0 11h
monitoring rmf-monitoring-promtail-z72p9 1/1 Running 0 11h
rmf keycloak-7764bcd867-znfhc 1/1 Running 0 104s
rmf keycloak-db-744d945977-t6x2f 1/1 Running 0 104s
rmf keycloak-setup-h672j 0/1 Error 0 104s
rmf keycloak-setup-hbxzr 0/1 Completed 0 33s
rmf rmf-sim-94b58ddc8-4rtp2 1/1 Running 0 104s
rmf rmf-web-dashboard-75fd57645d-6qr57 1/1 Running 0 104s
rmf rmf-web-rmf-server-6676866b69-9m79s 1/1 Running 4 (58s ago) 104s
rmf rmf-web-rmf-server-db-fb7dcff9b-4kfvb 1/1 Running 0 104s
Edited by @aaronchongth at 2025-03-06T04:38:52Z
Posted by @aaronchongth:
@Villy01, check out changes in Deployment template dashboard by aaronchongth · Pull Request #49 · open-rmf/rmf_deployment_template · GitHub
I believe the ingress works as intended, and so far things are working well on my end.
Posted by @Villy01:
I have tried the changes, and I can confirm that the trajectory server issue should be resolved. I am still having problems with the map display, but I am investigating it; it is probably an issue on my end. Thank you a lot for your help!
edit @aaronchongth
I checked more carefully following your suggestions, and the building map server pod is in a running state, as is the API server pod. Inspecting the topics, I see that the first pod is a publisher on the /map topic and is correctly publishing the message containing the map information, but it doesn’t see any subscribers. On the other hand, the second pod is subscribed but doesn’t see any publisher. With the command ros2 topic list, I see that the list of topics shown in the two pods is different. My suspicion is that the pods are unable to communicate with each other.
I’m not using rmf-sim but a real system.
Some logs from the two pods:
root@davide-HP:/ros2 topic info -v /map
Type: rmf_building_map_msgs/msg/BuildingMap
Publisher count: 1
Node name: building_map_server
Node namespace: /
Topic type: rmf_building_map_msgs/msg/BuildingMap
Topic type hash: RIHS01_04a3cde4e7f13d13ba94efc8e10fafd7a808bf748dabb51920f5493865492b5e
Endpoint type: PUBLISHER
GID: 01.10.93.73.2b.fd.46.86.9b.91.27.34.00.00.18.03
QoS profile:
Reliability: RELIABLE
History (Depth): KEEP_LAST (1)
Durability: TRANSIENT_LOCAL
Lifespan: Infinite
Deadline: Infinite
Liveliness: AUTOMATIC
Liveliness lease duration: Infinite
Subscription count: 0
root@davide-HP:/# ros2 topic list
/adapter_door_requests
/door_states
/map
/mutex_group_request
/mutex_group_states
/parameter_events
/rosout
/site_map
root@davide-HP:/# echo $ROS_DOMAIN_ID
15
root@rmf-web-rmf-server-6fb5d99c54-mg4vh:/ws/packages/api-server# ros2 topic info -v /map
Type: rmf_building_map_msgs/msg/BuildingMap
Publisher count: 0
Subscription count: 3
Node name: floorplan_visualizer
Node namespace: /
Topic type: rmf_building_map_msgs/msg/BuildingMap
Topic type hash: RIHS01_04a3cde4e7f13d13ba94efc8e10fafd7a808bf748dabb51920f5493865492b5e
Endpoint type: SUBSCRIPTION
GID: 01.10.23.22.82.c3.83.41.96.0a.92.39.00.00.19.04
QoS profile:
Reliability: RELIABLE
History (Depth): KEEP_LAST (10)
Durability: TRANSIENT_LOCAL
Lifespan: Infinite
Deadline: Infinite
Liveliness: AUTOMATIC
Liveliness lease duration: Infinite
Node name: rmf_api_server
Node namespace: /
Topic type: rmf_building_map_msgs/msg/BuildingMap
Topic type hash: RIHS01_04a3cde4e7f13d13ba94efc8e10fafd7a808bf748dabb51920f5493865492b5e
Endpoint type: SUBSCRIPTION
GID: 01.10.7c.e8.b6.4c.83.ff.16.3b.32.3c.00.00.25.04
QoS profile:
Reliability: RELIABLE
History (Depth): KEEP_ALL
Durability: TRANSIENT_LOCAL
Lifespan: Infinite
Deadline: Infinite
Liveliness: AUTOMATIC
Liveliness lease duration: Infinite
Node name: building_systems_visualizer
Node namespace: /
Topic type: rmf_building_map_msgs/msg/BuildingMap
Topic type hash: RIHS01_04a3cde4e7f13d13ba94efc8e10fafd7a808bf748dabb51920f5493865492b5e
Endpoint type: SUBSCRIPTION
GID: 01.10.b5.11.42.fb.ef.19.0d.61.fa.eb.00.00.18.04
QoS profile:
Reliability: RELIABLE
History (Depth): KEEP_LAST (1)
Durability: TRANSIENT_LOCAL
Lifespan: Infinite
Deadline: Infinite
Liveliness: AUTOMATIC
Liveliness lease duration: Infinite
root@rmf-web-rmf-server-6fb5d99c54-mg4vh:/ws/packages/api-server# ros2 topic list
/adapter_door_requests
/adapter_lift_requests
/alert
/alert_response
/beacon_state
/building_systems_markers
/clock
/delivery_alert_request
/delivery_alert_response
/dispatch_states
/dispenser_states
/door_states
/fire_alarm_trigger
/fleet_markers
/fleet_states
/floorplan
/ingestor_states
/lane_states
/lift_requests
/lift_states
/map
/map_markers
/mutex_group_manual_release
/nav_graphs
/parameter_events
/rmf_obstacles
/rmf_task/bid_notice
/rmf_task/bid_response
/rmf_task/dispatch_ack
/rmf_task/dispatch_request
/rmf_traffic/blockade_cancel
/rmf_traffic/blockade_heartbeat
/rmf_traffic/blockade_reached
/rmf_traffic/blockade_ready
/rmf_traffic/blockade_release
/rmf_traffic/blockade_set
/rmf_traffic/heartbeat
/rmf_traffic/itinerary_clear
/rmf_traffic/itinerary_delay
/rmf_traffic/itinerary_extend
/rmf_traffic/itinerary_reached
/rmf_traffic/itinerary_set
/rmf_traffic/negotiation_ack
/rmf_traffic/negotiation_conclusion
/rmf_traffic/negotiation_forfeit
/rmf_traffic/negotiation_notice
/rmf_traffic/negotiation_proposal
/rmf_traffic/negotiation_refusal
/rmf_traffic/negotiation_rejection
/rmf_traffic/negotiation_repeat
/rmf_traffic/negotiation_states
/rmf_traffic/negotiation_statuses
/rmf_traffic/participants
/rmf_traffic/query_update_1
/rmf_traffic/registered_queries
/rmf_traffic/schedule_inconsistency
/rmf_traffic/schedule_startup
/rmf_visualization/parameters
/rosout
/schedule_markers
/task_api_requests
/task_api_responses
/task_state_update
root@rmf-web-rmf-server-6fb5d99c54-mg4vh:/ws/packages/api-server# echo $ROS_DOMAIN_ID
15
Edited by @Villy01 at 2025-03-06T10:27:29Z
