Posted by @aaronchongth:
Hi @Oussama-Dallali99! That’s awesome to hear.
The API server operates mostly using REST, but there are socket.io endpoints for some reactive updates (states, etc) as you mentioned. Once you have the API server up and running, you can check out the endpoints at http://localhost:8000/docs
, assuming you are running the server locally and following the README instructions
API Server Setup: How can I configure and run the api-server to connect it with Open-RMF? Should I use Docker or set up a custom configuration file?
This is up to the user, and use-case. We have a deployment template showing how we can set up the API server in a kubernetes cluster alongside an Open-RMF deployment, GitHub - open-rmf/rmf_deployment_template: This repo provides a template to deploy RMF. In this template, we do set up a custom configuration file, rmf_deployment_template/charts/rmf-deployment/templates/config/rmf-web-rmf-server-configmap.yaml at main · open-rmf/rmf_deployment_template · GitHub
Do take note that this deployment template is a template, and is only for reference, and may not reflect what a production deployment should or should not look like
API Client Usage: What is the best way to use the api-client library to subscribe to topics (e.g., robot states, task updates) and send commands (e.g., task submissions)?
Check out the docs here, rmf-web/packages/rmf-dashboard-framework/docs/getting-started.md at main · open-rmf/rmf-web · GitHub, where users can create/modify their own dashboard by using rmf-dashboard-framework
as a built library. By extension, this applies to the api-client
library too.
Custom Frontend Integration: Are there any specific considerations for connecting a custom frontend with Open-RMF using these tools?
I assume these tools
mean the overall architecture of Open-RMF deployments communicating with an API server over ROS 2 and websockets, using an ORM with databases, and with a separate dashboard app. With ROS 2 being one the communication protocols between the API server and Open-RMF, using these tools will require them to be running on the same machine, or in the same cluster, if not, have a way to properly pipe DDS messages across clusters/setups.
I’d say specific considerations would be entirely up to the user and user’s requirements. The architecture we chose like all other architectures, have their pros and cons, and this was the one that fit our use cases in the past. Users are encouraged to make the system design decisions that is best suited for their use-case.