search

open-rmf / rmf-web

Apache License 2.0
87 stars 40 forks source link

[Dashboard]: Attempting to host rmf-web on AWS EC2 #1005

Closed MrOCW closed 1 month ago

MrOCW commented 1 month ago

Before proceeding, is there an existing issue or discussion for this?

Description

Hi, I am trying to get rmf-web 0.1.0 dashboard up. I am able to access api-server via {url}:8000/docs However, when I curl localhost:3000 in my EC2 instance after running rmf web dashboard, I am getting 404. This is my command: pnpm run --filter rmf-dashboard... build && serve -s build

However, running in development works as I am able to get a response with pnpm run start:react curl localhost:5173 I proceeded to configure my Load Balancer to point to 5173 and entered {url}:5173 but i get a 504 Gateway Time-out

aaronchongth commented 1 month ago

hey there @MrOCW, unfortunately this sounds like a configuration issue on your EC2 instance. Have you tried these steps on a local machine, and not on EC2?

Sanity check, are you certain that serve -s build was executed? A common issue I've seen is that serve might not be in PATH, and therefore the command fails

Closing as the root cause is not related to rmf-web

MrOCW commented 1 month ago

Hi @aaronchongth note that i am doing curl localhost:3000 in my EC2 instance and it is returning 404, which means that everything is local with respect to EC2

serve -s build was indeed being executed

Furthermore, accessing {url} on my web browser, which points to localhost:3000 on EC2, did have some logs showing that rmf-web was being queried and returned 404

dashboard   | 
dashboard   | > rmf-dashboard@0.1.0 build /rmf-web/packages/dashboard
dashboard   | > pnpm run --filter {.}^... build && vite build
dashboard   | 
dashboard   | Scope: 5 of 9 workspace projects
dashboard   | ../api-client build$ tsc --build
dashboard   | ../rmf-models build$ tsc --build && cp package.json dist
dashboard   | ../rmf-models build: Done
dashboard   | ../api-client build: Done
dashboard   | vite v5.3.5 building for production...
dashboard   | transforming...
dashboard   | ../../node_modules/.pnpm/three-stdlib@2.30.4_three@0.166.1/node_modules/three-stdlib/libs/lottie.js (13062:32): Use of eval in "../../node_modules/.pnpm/three-stdlib@2.30.4_three@0.166.1/node_modules/three-stdlib/libs/lottie.js" is strongly discouraged as it poses security risks and may cause issues with minification.
dashboard   | ✓ 14645 modules transformed.
dashboard   | [plugin:vite:reporter] [plugin vite:reporter] 
dashboard   | (!) /rmf-web/node_modules/.pnpm/date-fns@2.30.0/node_modules/date-fns/esm/locale/en-US/index.js is dynamically imported by /rmf-web/packages/react-components/lib/locale.tsx but also statically imported by /rmf-web/node_modules/.pnpm/date-fns@2.30.0/node_modules/date-fns/esm/locale/en-US/index.js?commonjs-proxy, /rmf-web/node_modules/.pnpm/@mui+x-date-pickers@6.19.0_@emotion+react@11.13.0_@types+react@18.3.3_react@18.3.1__@emotion+_rjgckvwv3lnvhvtg6llhomaiku/node_modules/@mui/x-date-pickers/AdapterDateFns/AdapterDateFns.js, /rmf-web/node_modules/.pnpm/date-fns@2.30.0/node_modules/date-fns/esm/_lib/defaultLocale/index.js, dynamic import will not move module into another chunk.
dashboard   | 
dashboard   | rendering chunks...
dashboard   | computing gzip size...
dashboard   | dist/index.html                                                1.41 kB │ gzip:   0.77 kB
dashboard   | dist/assets/roboto-vietnamese-300-normal-CnPrVvBs.woff2        5.47 kB
dashboard   | dist/assets/roboto-vietnamese-700-normal-SekShQfT.woff2        5.55 kB
dashboard   | dist/assets/roboto-vietnamese-400-normal-kCRe3VZk.woff2        5.56 kB
dashboard   | dist/assets/roboto-vietnamese-500-normal-CcijQRVW.woff2        5.60 kB
dashboard   | dist/assets/roboto-greek-700-normal-Cc2Tq8FV.woff2             6.94 kB
dashboard   | dist/assets/roboto-greek-500-normal-CpESfwfG.woff2             7.02 kB
dashboard   | dist/assets/roboto-greek-400-normal-BRWHCUYo.woff2             7.11 kB
dashboard   | dist/assets/roboto-greek-300-normal-ndiuWqED.woff2             7.12 kB
dashboard   | dist/assets/roboto-cyrillic-300-normal-D6mjswgs.woff2          9.58 kB
dashboard   | dist/assets/roboto-cyrillic-400-normal-DVDTZtmW.woff2          9.63 kB
dashboard   | dist/assets/roboto-cyrillic-700-normal-B5ZBKWCH.woff2          9.64 kB
dashboard   | dist/assets/roboto-cyrillic-500-normal-DAkZhMOh.woff2          9.84 kB
dashboard   | dist/assets/roboto-latin-ext-300-normal-DEsNdRC-.woff2        11.80 kB
dashboard   | dist/assets/roboto-latin-ext-500-normal-BWKy6SgX.woff2        11.80 kB
dashboard   | dist/assets/roboto-latin-ext-700-normal-BYGCo3Go.woff2        11.82 kB
dashboard   | dist/assets/roboto-latin-ext-400-normal-4bLplyDh.woff2        11.87 kB
dashboard   | dist/assets/roboto-cyrillic-ext-700-normal-CsrCEJIc.woff2     14.68 kB
dashboard   | dist/assets/roboto-cyrillic-ext-500-normal-G9W8hgzQ.woff2     14.97 kB
dashboard   | dist/assets/roboto-cyrillic-ext-300-normal-TzZWIuiO.woff2     15.00 kB
dashboard   | dist/assets/roboto-cyrillic-ext-400-normal-DORK9bGA.woff2     15.34 kB
dashboard   | dist/assets/roboto-latin-300-normal-ThHrQhYb.woff2            15.74 kB
dashboard   | dist/assets/roboto-latin-400-normal-mTIRXP6Y.woff2            15.74 kB
dashboard   | dist/assets/roboto-latin-700-normal-CeM5gOv8.woff2            15.86 kB
dashboard   | dist/assets/roboto-latin-500-normal-Dxdx3aXO.woff2            15.92 kB
dashboard   | dist/assets/roboto-latin-400-normal-CEBEUyyq.woff             20.34 kB
dashboard   | dist/assets/roboto-all-300-normal-lRRuIfal.woff               65.16 kB
dashboard   | dist/assets/roboto-all-400-normal-BZJ9QssU.woff               65.46 kB
dashboard   | dist/assets/roboto-all-700-normal-BfaNsj0k.woff               65.56 kB
dashboard   | dist/assets/roboto-all-500-normal-B0NPRryQ.woff               65.76 kB
dashboard   | dist/assets/index-DxbcFP-A.css                                18.61 kB │ gzip:   7.43 kB
dashboard   | dist/assets/index-DlGJ4c19.js                              2,965.14 kB │ gzip: 848.28 kB
dashboard   | 
dashboard   | (!) Some chunks are larger than 500 kB after minification. Consider:
dashboard   | - Using dynamic import() to code-split the application
dashboard   | - Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
dashboard   | - Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
dashboard   | ✓ built in 23.64s
dashboard   |  INFO  Accepting connections at http://localhost:3000
dashboard   |  HTTP  9/2/2024 9:43:59 AM 10.90.1.114 GET /
dashboard   |  HTTP  9/2/2024 9:43:59 AM 10.90.1.114 Returned 404 in 13 ms
aaronchongth commented 1 month ago

Unfortunately we don't have any information about your EC2 instance or how it's been set up. We'll help investigate further if you are unable to run it locally (on a local machine, not EC2), implying that the issue arises from rmf-web

otherwise, here are some search results that could be useful,

MrOCW commented 1 month ago

I am using this docker image from minimal-rmf LOCALLY this time. I am still getting 404 when accessing localhost:3000

ARG BASE_IMAGE=docker.io/ros:jazzy-ros-base
FROM $BASE_IMAGE
ARG BRANCH=main
ARG ROS_DISTRO=jazzy

### build minimal rmf

RUN apt update && apt install -y curl

# # fetch sources
RUN mkdir -p /rmf && cd /rmf \
  && curl -sL https://github.com/open-rmf/rmf_internal_msgs/archive/refs/heads/$BRANCH.tar.gz -o rmf_internal_msgs.tar.gz \
  && curl -sL https://github.com/open-rmf/rmf_building_map_msgs/archive/refs/heads/$BRANCH.tar.gz -o rmf_building_map_msgs.tar.gz \
  && mkdir -p /rmf/src/rmf/rmf_internal_msgs && tar zxf rmf_internal_msgs.tar.gz -C /rmf/src/rmf/rmf_internal_msgs --strip-components=1 && rm rmf_internal_msgs.tar.gz \
  && mkdir -p /rmf/src/rmf/rmf_building_map_msgs && tar zxf rmf_building_map_msgs.tar.gz -C /rmf/src/rmf/rmf_building_map_msgs --strip-components=1 && rm rmf_building_map_msgs.tar.gz

RUN rosdep update && rosdep install --from-paths /rmf/src -yi

RUN cd /rmf \
  && . /opt/ros/$ROS_DISTRO/setup.sh \
  && colcon build --merge-install --install-base /opt/rmf --cmake-args -DCMAKE_BUILD_TYPE=Release \
  && rm -rf /rmf

# install tools for rmf-web

RUN curl -fsSL https://get.pnpm.io/install.sh | bash -
# shell runs in non-interactive mode, which does not source .bashrc so we need to set the PATH manually
ENV PNPM_HOME /root/.local/share/pnpm
ENV PATH "$PNPM_HOME:$PATH"

# nodejs seems to have changed the official mirror, the default in pnpm is very slow now
RUN pnpm config -g set 'node-mirror:release' https://nodejs.org/dist && pnpm env use --global lts

RUN apt update && apt install -y python3-venv

docker run -it --name="rmf-web" --net=host --ipc=host --privileged --volume..... rmf-web-jazzy

proceeded to follow the instructions on the README and serve dashboard

MrOCW commented 1 month ago

decided to go along with running this command on my EC2

docker run \
  --network host -it --rm \
  -e RMF_SERVER_URL=http://localhost:8000 \
  -e TRAJECTORY_SERVER_URL=ws://localhost:8006 \
  ghcr.io/open-rmf/rmf-web/dashboard:latest

It is now accessible via my custom domain.. but the rendering of each floor of my building is extremely slow and only L1 and L2 is rendered out of 30+ levels.

console logs Mixed Content: The page at '{url}/' was loaded over HTTPS, but requested an insecure element 'http://localhost:8000/cache/#########################.png'. This request was automatically upgraded to HTTPS

aaronchongth commented 1 month ago

The images are passed from the API server to the dashboard via REST, so if your building is extremely large and the map sizes are very large, dips in performance is expected

especially since you are accessing the browser through your own machine, large transports will be affected. I would suggest reducing the quality of your maps. Overall the maps should start loading faster after you have done it once for every floor, your browser will help with the caching.

MrOCW commented 1 month ago

my L1 and L2 is loading fine after a while, however, the rest of my floors never loads unfortunately. In the previous version of 22.09 which we brought to production, all floors and infra were loaded. In the api-server, i see that the files are loaded to run/cache

aaronchongth commented 1 month ago

Can you verify that it doesn't work locally (not on EC2), using the docker images? you can check the dev console of your browser to see if any errors occurred, with debug logs

In the api-server, i see that the files are loaded to run/cache

this makes me suspect it is still a size or bandwidth issue sanity check, if the floors do not load, what about the doors or lifts on those floors? Do they get rendered?

aaronchongth commented 1 month ago

Just a few checks, any chance you could share the building map file, along with all the floor plans? So if it is an upstream issue we can investigate it further?

A minor check would also be to share the file sizes of the floor plans, for example the sizes for L1 and L2 (since they load fine for you), vs the other floors

sanity check, if the floors do not load, what about the doors or lifts on those floors? Do they get rendered?

the reason i asked this, is to check if the level is indeed situated correctly, or was it set up with large offsets and is somewhere else in the map and requires much zooming and panning.

edit: another thought that came to mind, do the other floors have walls drawn in their building map level? rmf-web uses the bounding box of the walls of a level to create a scene boundary, this ensures that the view of the level can encompass everything. If there are no walls, the scene boundary will not be valid

MrOCW commented 1 month ago

Can you verify that it doesn't work locally (not on EC2), using the docker images?

Yes same issue locally, L1 L2 loads, L3 onwards does not load

what about the doors or lifts on those floors

Not sure how this main version should look like but the entrances to the lifts, and the turnstiles are shown in green

this makes me suspect it is still a size or bandwidth issue

Possibly, but shouldnt this make the other floors still load albeit slower?

share the file sizes of the floor plans

L1: 3.1MB L2: 2.4MB L3: 1.3MB L5: 14.1MB L6: 1.1MB .... theres too many floors to share but they range from 1~14MB

do the other floors have walls drawn in their building map level

is this from traffic-editor?

MrOCW commented 1 month ago

image

Note that adapters are not up

aaronchongth commented 1 month ago

This looks normal

is this from traffic-editor?

yes, please review each floor in traffic-editor that there are walls drawn into the levels, according to the floorplan this generates walls in simulation if you're using building_map_tools, but also help rmf-web figure out what size the scene boundary should be

L1: 3.1MB L2: 2.4MB L3: 1.3MB L5: 14.1MB L6: 1.1MB ....

L5 will definitely be slow, but the other floors should not have issues loading.

Could you also check if there are any errors in the browser console log

MrOCW commented 1 month ago

Could you also check if there are any errors in the browser console log

image Upon L1 and L2 loading, the console starts spamming this: image

yes, please review each floor in traffic-editor that there are walls drawn into the levels

seems like only L1 and L2 have walls. Let me try and modify and update again

MrOCW commented 1 month ago

adding the walls fixed it! the floors with walls are now loading correctly thank you! might be worth adding this into documentation by the way, what kind of resolution would you recommend for the floorplans?

aaronchongth commented 1 month ago

good to hear that.

might be worth adding this into documentation

Good point, https://github.com/open-rmf/rmf-web/pull/1006

by the way, what kind of resolution would you recommend for the floorplans?

This is a tough question to answer, for the best performance, smaller resolutions are always better, as it will help with network transport, as well as loading in react-three-fiber overall. For folks with an amazing network (running everything locally for example), and users with powerful machines to view the dashboard, they can go as high resolution as they want. However if the dashboard has to work through rough networks, and the users are using relatively under-powered machines, the resolution will have to be reduced.

I would recommend to reduce resolution to the point where the artifacts desired (by the users) in the floorplans are at least still visible and sharp-ish.

We have plans to further optimize how we are rendering our maps, but how much more performance we can squeeze out is unknown at this point of time.