Main Goals

• Reduce confusion for users over multiple ways to do things:

  • . /etc/ros/setup.bash vs. . /opt/ros/cturtle/setup.sh

  • "robot start" vs. "roslaunch /etc/ros/robot.launch"
• Remove /etc/ros/env so that all "setup.sh" files are generated consistently by rosinstall
• Improve the predictability of the web_interface by tying it to a proper ROS environment
• Allow developers to launch their own copies of the web interface
• Make the whole system easy enough to explain/understand

Current state of affairs

/etc/ros

• stores system configuration for ROS:
• "Default" environment:
  • Recommended environment for users without anything checked out.
  • Environment when restarting webinterface
• calibrated urdf for robot
• launch file for robot
• intermediate symlinks for sensors
• env is a bunch of files which get loaded into environment through some hackery
  • Not enough error checking in bash script
  • Different from how we typically do things.
  • Non-standard environment variables, i.e., not in a standard setup.sh
    • ROBOT (ROBOT_TYPE) -- This one is important for launch files.
    • ROBOT_NAME
    • ROBOT_START_LAUNCH_FILE
  • Some programs look at environment, while some look at contents of files -- synchronization not actually guaranteed
    • Looking at files directly prevents over-riding

web_interface

• currently reads config out of /etc/ros/env
  • Developers have to change /etc/ros/env to point to their development paths
  • apache has to be restarted after update
• want this to be easier to reconfigure

robot start

• robot start reads config out of /etc/ros/env
• implicitly claims robot
• kills running processes
• launches /etc/ros/robot.launch
• "robot start -e" assumes environment is set. Note: ROBOT, ROBOT_NAME, and ROBOT_START_LAUNCH might be absent, in which case some things would mysteriously break

ROBOT environment variable"

• There are many launch files in the system which make use of the ROBOT environment variable to include a file such as: $(env ROBOT).machine

• Needs to be set or else these launchfiles won't launch
• Would be nice to not require this in default case (presumably running on PR2)

Proposal

• First remove need for non-standard environment variables (ROBOT, ROBOT_TYPE, ROBOT_NAME) from default launch.
  • Nodes that care about ROBOT_TYPE should look at "/robot_type" on parameter server, not /etc/ros/env/ROBOT_TYPE
    • /robot_type param should be added to robot.launch
  • Launch files that care about ROBOT should use optenv
    • ROBOT is actually a bad variable name. Maybe something like: ROS_MACHINE_FILE.

    • <include file="$(find pr2_machine)/$(optenv ROS_MACHINE_FILE pr2).machine"/>

    • pr2_machine should export a single launch file entrypoint, such as auto.machine, which would contain the logic

    • <include file="$(find pr2_machine)/$(env ROBOT).machine"/> --> <include file="$(find pr2_machine)/auto.machine"/>

    • This gives us much more flexibility in the future
• Remove /etc/ros/env
• Proposed structure of /etc/ros becomes:
  • /etc/ros/:

    • distro -> (boxturtle|cturtle)

    • setup.sh -> distro/setup.sh

    • robot.launch -> distro/robot.launch

    • boxturtle/

      • setup.sh -> /opt/ros/boxturtle/setup.sh

      • robot.launch -- References "/etc/ros/boxturtle/urdf/robot.xml"
      • urdf

        • robot.xml -> robot_calibrated_2010_07_15.xml

        • ...
• For web_interface, apache can now run in userspace
  • gets launched as part of webui.launch
  • simply uses environment inherited from robot.launch

Robot start proposal

I split this section off since solution is less clear and likely more controversial:

• Robot claim / robot release are valuable
  • There is nice benefit to implicit claim with start, and release with stop
• If we remove robot start, taking over/using robot becomes multi-step
• One option is to keep robot start, but change it to always respect environment:
  • Essentially becomes alias for: "robot claim; robot stop; roslaunch /etc/ros/robot.launch"
• Another option is to instruct people to create the corresponding aliases themselves
• There is an argument that daemonizing is actually confusing and people would benefit more from still being forced to see the output of roslaunch
• This is the area that could use the most brainstorming/suggestions

Comments

• Eitan
  • I'm on board with the general proposal, though I'm not sure about how backwards compatibility is going to work when switching launch files from the ROBOT enviornment variable to something like ROS_MACHINE_FILE.
  • I don't think that the robot start command should exist. The points about claiming/releasing the robot are well taken, but I can't count the number of times I've gone to help someone who has no idea what's wrong with their robot and it turns out that nodes are dying like crazy and errors are spewing, but they don't notice it. There is an argument here that they should be running the dashboard, but in the case that a node dies on startup... they may not actually see any error messages over the console. People could go and look for the log files from their roslaunch to see what's going on, but this is also non-trivial since they're not necessarily sure how to find the process id for the roslaunch brought up by robot start. Overall, I'm not convinced that we gain that much with "robot start" and I think the command leads to a lot of confusion.
• Stu

  • Another vote for killing robot start. I've helped several people who wonder why they can't start non-standard controllers despite them being built and in the ROS_PACKAGE_PATH. The answer is always to stop using robot start.

• Wim
  • Great proposal, I can't wait to see /etc/ros/env disappear, and solve many of the problems it caused.
  • I'd also get rid of 'robot start'. Eitan explains the problems with this tool pretty well.
  • We should keep an equivalent of 'robot stop'.
  • Changing the ROBOT environment will be hard because it is used in may places, even in released and stable stacks.
• Tully
  • Robot type on parameter server seems like a good solution.
  • I support removal of /etc/ros/env
  • apache in userspace is very good and much clearer

  • robot start proposal I would suggest that making it "robot stop && robot claim && roslaunce /etc/ros/robot.launch and not deamonizing.

Conclusions from Meeting (07/28/10)

• Everyone was agreeable to plan to get remove /etc/ros/env.

• The confusion related to the ROBOT environment variable is going to need to be sorted out separately:

  • All stacks should be patched to use <include file="$(find pr2_machine)/auto.machine"/> to make the transition more straightforward.

    • Eitan pointed out there are Makefiles that set this environment variable as well for the purposes of the test system.

  • In short term, /etc/ros/setup.sh will simply contain:

    • . /etc/ros/distro/setup.sh
      export ROBOT=pr2

  • Another meeting needs to be scheduled to work out a more appropriate mechanism for dealing with parameterizable launch files that does not depend on environment variables.
• Robot start will go away.
  • The robot command will keep claim/release/stop.
  • Robot stop will no longer release the robot.
  • The claim/release issue will be solved socially. Recommended practice:

    • When you start using a robot, you issue a sudo robot claim.

      • This is an extra command when you first start using a robot. But it means you keep the robot claimed the whole time, even when not actively running.

    • When you stop using a robot, you issue a sudo robot release.

    • Robot users will be modified to report the effective idle-time for a user in case people inadvertently leave it claimed.