mruse.md
Last updated
Last updated
Copyright (c) Brandeis University
It is important that you follow a rigid procedure when turning the robot on and off.
Assuming it is totally off:
Make sure the battery pack is correctly connected to the robot.
Switch on the battery pack
Click the micro button on the red board
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.
From your ssh command line on the remote computer, type sudo shutdown now
Once the Raspberry Pi has stopped blinking you can turn off the power switch on the battery pack.
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.
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...
If you have a cloud desktop and want to run simulations without a actual miniRover" rset cloud
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)
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)
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
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.
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
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
miniRover
hostname gopigo3
default account pi
default password raspberry
Cloud or Docker Desktop
default password dev@ros
desktop: url: http://vnc..ros.campusrover.org
vscode: http://code..ros.campusrover.org
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.
ROS_MASTER_URI = robot's own ip address ROS_IP = robot's own ip address
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.
myip returns your local ip address
myvpnip returns your vpn ip address (if you have one)
