• mjpc13M
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Yeah, although I don’t like this approach. Using containers seems to be the best choice here. In this way you can keep the default/custom Steam bindings, which is very useful. And you don’t have the audio, sleep, OS or battery problems they talk in the video. I would argue that “desktop use” is not the best use for a Steam Deck, but more as a field computer.

      • ruffslOPM
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        Any particular instructions you followed to install a container runtime? I don’t own one, but I’ve heard it uses a read only system install that you have to disable to alter system files.

        • mjpc13M
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          The downside to disable the read only system file is that you will delete any changed file and installed package when you update SteamOS.

          I used homebrew to install podman. Since homebrew creates a folder in /home/linuxbrew/ there is no problem with the read only system.

  • iaamp
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Interesting, but overall it seems to come down to basically just getting Ubuntu running on it, which of course works as steam OS is also just a Linux distro. And from there you can do all types of things. Programming wouldn’t be my choice though. But as a mobile introspection device maybe. How would it compare with a tablet? Does it have advantages?

    • mjpc13M
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      1 year ago

      Yes, I believe it has plenty advantages in using the steam deck vs android tablets. Instead of installing Ubuntu on my Steam Deck, I utilize Podman and Podman Compose to launch the necessary ROS nodes.

      My Steam Deck records compressed RGB+D and LiDAR data into rosbags, while running a LOAM-based algorithm and visualizing the map in real-time. During this process, the CPU usage remains around 70%. The primary consumer of system resources was Chrome, (running Foxglove), which accounted for approximately 17% of CPU usage. This leaves room to experiment with more resource-intensive algorithms (which I will be doing in the future). I think I could not have managed this in a tablet for the price of the Steam Deck.

      The presence of joysticks on the Steam Deck proves useful for utilizing it as a controller, another benefit versus using an Android tablet. Although I have not yet messed with the joysticks, only with the back buttons to add a few keybindings.

      • ruffslOPM
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        What display server does steam use on Arch/SteamOS? Wayland, X11? I imagine you’re using Foxglove with native browser install to work around the hassle of having to do display forwarding and GPU passthrough from the container to use rViz instead?

        • mjpc13M
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          It uses X11. I am using Foxglove on a container and exposing a port. I didn’t tried Rviz, but it probably is not straightforward to make it work. So I went directly to a web-based viewer.

    • ruffslOPM
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      If your referring to a tablet as in either an Android tablet or iOS iPad, then I’d say targeting the Steam Deck from a general software stack perspective would be a lot simpler, given its more like general compute hardware, like any laptop, rather than a limited mobile OS. Also, the amd64 CPU architecture may help in running other legacy components of a software stack that can’t be recompiled or are not source available. Having complete control and choice of desktop OSs in a handheld form factor alone would be great for field robotics; just not sure it could compete with similar arm based handhelds in terms of battery life convenience or power budget.

      That horse power could still be advantageous when dealing with tasks beyond a cheap SBC, but don’t require a workstation either. Like orbiting around high resolution 3D point clouds in a 3D viewer streamed from the robot in real time, or visualizing dense, uncompressed 3D meshes or voxel maps reconstructed from surveys using visual SLAM.