I just saw Nick's post about what he and Dave are up to at Hacker School. One thing that I thought was particularly interesting was that they have some explicit social rules to help keep the environment friendly and conducive to learning. Nick lists 2 examples:

... "No well-actuallys" and "no feigning surprise."

No "well, actuallys" means you shouldn't correct minor inaccuracies in things others say when it has nothing to do with the conversation at hand. ...  Programmers have a bad habit of saying, "well, actually..."

No feigning surprise means you shouldn't act surprised when you find out someone doesn't know something, even if you think it's "obvious." If someone asks, "Who's RMS?" don't say, "You don't know who Richard Stallman is?!" ...

I've definitely done both of these without really thinking through the implications. I appreciate that these guys are talking about stuff like this because it's helped me become more aware of my stupidity.

I'd love to see another post where they talk more about their other social rules and what the result of implementing them has been.

Oh and if you think you'd be a good fit for Hacker School, apply for summer 2012!

ROS Development Tips & Tricks

I just participated in another hackathon with ROS and the PR2. After each hackathon, we think about ways to improve our process and code and this time around we tested out some ideas we came up with last time and they worked out well.

Here's my current list of tips and tricks for ROS and robot development. It's mostly intended for ourselves next time so it's very concise and I  won't spend any time trying to convince you why something is a good idea :-) Hopefully it'll be useful to you too!

• Use rviz
• Visualize intermediate steps. For example if the robot needs to get within grasping range of something and has some candidate destinations, visualize them and then visualize which candidate was chosen. This is way easier to read and understand than text output listing coordinates.
• Visualize detected objects. Then you can overlay them with video and make sure they're detected in the pose they're actually in. I think you can do this in rviz with markers although I haven't tried it yet.
• Ben's got a c++ library called pviz which visualizes the PR2. This is much better than putting an arrow at the base pose. Next time around, I'd like pull it into my future simple-ros library and expose it as a service.
• Speed up the process of testing changes
• Make your launch files respawn nodes when they die (respawn="true"). This way if nodes crash or you rebuild them and kill the old ones, you bring up a new node without wasting time tracking it down or worse, stopping and restarting the whole launch.
• Put constants in config files or the param server or anywhere that you can adjust them without rebuilding. This matters much more in c++ code than in python.
• Make long running nodes re-read their configs on each request or action so you can tweak settings and not need to restart the nodes.
• Nodes you write which provide complex services should have debug service calls or messages which do parts of the action. This makes debugging much easier. For example, a node which has a service to pick up blocks should also expose actions to put the arm in position, close the gripper, lift the block, etc.
• (Eventually) use the auto dev builder. It's a tool which detects changes to source files and tries to rebuild them and kill the running node so it can be respawned with the new executable. It doesn't support python programs yet and has a bug where it can run make in the wrong dir and use the wrong Makefile.
• Misc
• Set things up so you can run the robot while connected to power. If the robot has to move around in a limited area, run power from above using pulleys to take up the slack as the robot gets closer to where the cable comes from.
• If more than one person is involved, develop in simulation. Only push code to the central repo and test on the robot once a feature is done and working in simulation.
• If you're not using stacks which treat launch files as part of a stable api, don't use their launch files, especially with high level code. Copy and paste needed bits into your own launch files. In theory it's good practice not to duplicate code, but it's too hard to track down broken launches when they're spread out over many files and some launch files do strange things.
• Give packages unique names. ROS doesn't use the stack as part of the namespace so all packages must have unique names.
• If you're building a package which is meant to be reused, put it in its own stack and its own repo unless you're using svn and are sure no one will ever migrate the repo to a different vcs. With git, hg, etc, you have to check our the full tree and there's no good way to tell ROS you're only interested in a particular subdirectory. People who want to use one package get every package from the repo in their ROS path. If one of the other packages in the repo conflicts with something else (like a fork of the project) their life becomes difficult.
• Set up bash aliases:
  

  # Standard ROS setup
  source /opt/ros/electric/setup.bash
  export ROS_ROOT=/opt/ros/electric/ros
  export PATH=$ROS_ROOT/bin:$PATH
  export PYTHONPATH=$ROS_ROOT/core/roslib/src:$PYTHONPATH
  export ROS_PACKAGE_PATH=~/ros:/opt/ros/electric/stacks:$ROS_PACKAGE_PATH
  export ROS_PARALLEL_JOBS='-j4'
  export ROBOT=sim # or pr2, whichever you use most
  
  # Handy commands
  alias pr2dash='rosrun pr2_dashboard pr2_dashboard'
  alias rviz='rosrun rviz rviz'
  alias prl='export ROBOT=pr2 && export ROS_MASTER_URI=http://prl:11311'
  alias sim='export ROBOT=sim && export ROS_MASTER_URI=http://localhost:11311'
  
  # Show cameras
  alias rightwide='rosrun image_view image_view image:=/wide_stereo/right/image_rect_color theora ;'
  alias leftwide='rosrun image_view image_view image:=/wide_stereo/left/image_rect_color theora ;'
  alias rightarm='rosrun image_view image_view image:=/r_forearm_cam/image_rect_color theora'
  alias leftarm='rosrun image_view image_view image:=/l_forearm_cam/image_rect_color theora'
  
  # Show arm joint angles
  alias rightjoints='rostopic echo -n 1 r_arm_controller/state | grep -B1 -A0 "positions:"'
  alias leftjoins='rostopic echo -n 1 l_arm_controller/state | grep -B1 -A0 "positions:"'
  alias bothjoints='rostopic echo -n 1 both_arms_controller/state | grep -B1 -A0 "positions:"'
  
  # Show wrist pose in base footprint (middle of robot on floor)
  alias rightwrist='rosrun tf tf_echo base_footprint r_wrist_roll_link'
  alias leftwrist='rosrun tf tf_echo base_footprint l_wrist_roll_link'
  

Putting crappy code online

I often put code for personal projects online. In part this is to share what I've done with the world so others can see how cool it is and maybe reuse part of it. It also makes it easier for me to find it in the future if I want to work on it further or see what I've done.

The downside is that sometimes if I'm just hacking something together, the code's a mess, and I worry that perspective employers may see this as representative of my work. If I was going to work on it or support it long term, I'd spend time to make sure the code was neat, but, for example, if I'm trying to get a robot to play instruments in 3 days, code organization has to take a back seat.

I guess the solution is to be clear about the state of the code and the reason for it when describing the project online or in the comments. Good developers should know that code doesn't always start off beautiful and if they value their time they should also know that it's not always worth it making it beautiful. As long as they know that I know it's a mess, I can't imagine they'll hold that against me.

Parasites

My friend Ben Wallick did a parody of Coldplay's Paradise called Parasites. I'm not sure I agree with the premise of the song, but it's funny and very well done.

http://soundcloud.com/ben-wallick/parasites-paradise-parody-ben

Thanks

I'm thankful that I get to do what I love every day, and get paid well to do it.

Then I can go buy whatever food I want whenever I want it without having to grow it months in advance with lots of hard work.

Life is good!

PR2 Poop Scoop

Success! We scooped poop and people talked about it!

I made some notes about problems we had during the hackathon and possible solutions:


Problem 1: Making changes to code requires recompiling and rerunning a node or event shutting down and re-running a lunch file.

Solution A: Load params dynamically (param server, dynamic reconfigure, flat file, etc) so we can change them at run time.

Solution B: Set launch file to respawn nodes if they die.

Solution C: Build a tool which monitors source files and rebuilds node executables as needed. I must also kill old instances of nodes when rebuilding them. I've written a prototype of this.


Problem 2: Had to edit nodes to test pieces of functionality.

Solution: Make sub-behaviors runnable via command line and/or ROS calls.


Problem 3: Battery running low at bad time.

Solution: Feed power cable from above so we can do some testing while it's plugged in.


Problem 4: When something didn't work, it took too much time to track down where the problem was.

Solution: All code should have very rebose ROS_INFO or loginfo calls.


Problem 5: Devs killing each other's nodes.

Solution A: Work in gazebo when possible.

Solution B: Maybe schedule time for each dev to test code on the robot.

Jeff Atwood just blogged about how logging in to sites could be done much easier. Three cheers for someone thinking about a solution for this insane situation!

At the end he lists 2 catches, one of which is that you need to trust some server online to be a secure place to store your passwords. I don't see why that should be though. If, as he says, you'd log in to your browser, why can't the browser encrypt the stored passwords and then store them to a not-so-secure place online?

Maybe he's concerned that an attacker could get them, wait a few years for a security problem to be found in the encryption, and then crack them. That scenario is somewhat mitigated by the fact that if a security problem is found, you could walk through the list of accounts and change the passwords for any important ones.

Maybe with the right meta tags or whatever, the change password process could be done automatically by the browser. If that was the case, the browser could change all your passwords periodically without there even being a discovered security weakness in the encryption. That would make all the security people happy who think changing passwords regularly is good. And in fact it would be good since it provides the advantages of changing passwords (limited exposure if a password is stolen) without the disadvantages (user inconvenience of  having to learn a new password).