> For the complete documentation index, see [llms.txt](https://campus-rover.gitbook.io/lab-notebook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://campus-rover.gitbook.io/lab-notebook/fiiva/lab-robots/minirover/mruse.md). # mruse.md ## Turning it on It is important that you follow a rigid procedure when turning the robot on and off. Assuming it is totally off: 1. Make sure the battery pack is correctly connected to the robot. 2. Switch on the battery pack 3. Click the micro button on the red board ![Button to reboot](https://4196336753-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LULg3WmBk4r0dWAdK9A%2Fuploads%2Fgit-blob-56ad8cf04b2b859ff42cdc32c5de95ab138fc740%2Fbutton.jpg?alt=media) 1. Look at the Raspberry Pi (not the "red board") You will see tiny red and green LEDs blinking. Wait until the green one has settled down to slow flickering. ## Turning it off 1. From your ssh command line on the remote computer, type `sudo shutdown now` 2. Once the Raspberry Pi has stopped blinking you can turn off the power switch on the battery pack. ## Charging the Battery The Battery pack came with a charger. It has a light on which is red while charging and green when fully charged. *Note that the battery will not charge when its switch is set to off*. ## rset command We've implemented a very simple tool to set up the IP addresses correctly. It will be changing as I figure out how to make it better. So for now\... 1. If you have a cloud desktop and want to run simulations without a actual miniRover" `rset cloud` 2. If you have a cloud desktop add a real robot, run `rset robot` on your cloud desktop and `rset pi` on the actual miniRover (over ssh) 3. If you have a local docker based desktop, run `rset docker` there. rset by itself displays the current status (I know a combination is missing and plan a revision of this) ## Starting the MiniRover ROS applications Note that all we run on the MiniRover itself are roscore, and the nodes needed for the motors, lidar and camera. Everything else runs on your "remote". The following commands are to be done on the MiniRover from \~/catkin\_ws ``` # launch the motor controller and lidar roslaunch minirover mr_bringup.launch # launch camera (optional if you need the camera) roslaunch gpg_bran raspicam.launch ``` ## Web Desktop tools Note that this includes all flavors, cloud based, local docker based, and gpu based browser desktops. If you just want to use the simulators on their own and are not using an actual miniRover, then: `rset cloud` is enough. At that point you can run your ROS programs. There are numerous scripts, programs and launch files that are preinstalled on your ROS wegpgb desktop. I will document only some of them here but you can look around and find more that are interesting. All of them from the book are here. I have not renamed any of them for that reason. ``` # Fun prr examples rosrun prrexamples red_light_green_light.py rosrun prrexamples wander.py # Visualize robot with rviz roslaunch gopigo3_navigation gopigo3_rviz.launch # Or with gazebo (not as useful) roslaunch gopigo3_navigation gopigo3_gazebo.launch # Run different simulated stages to experiment with roslaunch roslaunch turtlebot3_gazebo turtlebot3_stage_1.launch roslaunch turtlebot3_gazebo turtlebot3_stage_2.launch roslaunch turtlebot3_gazebo turtlebot3_stage_3.launch roslaunch turtlebot3_gazebo turtlebot3_stage_4.launch # Control the robot roslaunch turtlebot3_teleop turtlebot3_teleop_key.launch # Begin building the map on real robot roslaunch gopigo3_navigation gopigo3_slam.launch # Begin localization with AMCL roslaunch gopigo3_navigation amcl.launch ``` ## Rset Command In order to facilitate working in all the combinations of environments we have these commands: * rset pi - declare that this is the raspberry pi * rset cloud - declare that this is a cloud desktop working with sim * rset robot - declare that this is a cloud desktop working with a real robot * rset - display settings ## Aliases There are a bunch of handy aliases: * `myip` - this computer's regular local ip * `myvpnip` - this computer's vpn ip if it has one * `stopnow` - immediately stop the robot * `teleop` - run a simple teleop tool * `ru` - connect to rosutils * `cm` - catkin\_make * `cw` - cd \~/catkin\_ws * `cs` - cd \~/catkin\_ws/src ## Accounts and passwords * miniRover * hostname `gopigo3` * default account `pi` * default password raspberry * Cloud or Docker Desktop * default password `dev@ros` * desktop: url: * vscode: ## Key Environment Variables `ROS_MASTER_URI=http:/100.94.206.80:11311` (example!) should always be set to the computer where roscore is running. If you are using a physical robot, then roscore runs on the robot itself. If you are in the web deskop and working just with simulation then roscore would run there. ### Robot ROS\_MASTER\_URI = robot's own ip address ROS\_IP = robot's own ip address #### Remote Computer ROS\_MASTER\_URI = robots ip address ROS\_IP = remote computer's own IP address These IP addresses are on different networks and cannot access each other. So instead we've created what is called a "virtual private network" that connects them together. Both your robot and your cloud desktop have an *alternate* ip address which they can both see. ## IP Addresseses * `myip` returns your local ip address * `myvpnip` returns your vpn ip address (if you have one) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://campus-rover.gitbook.io/lab-notebook/fiiva/lab-robots/minirover/mruse.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.