The Up Mouse!

I'm developing a new ergonomic mouse where you click by lifting your fingers. Check it out and pass along the word to anyone you know who has pain from using their mouse!

The Up Mouse Submitted to Kickstarter

I've been working on the Kickstarter campaign for my Up Mouse idea for a while. Today I finally did the last pass at editing the video and was all ready to make the campaign live and then learned that Kickstarter moderates them. Hopefully it won't take long!

Innovation

I just read an obscenely long New Yorker article about Peter Thiel, co-founder of PayPal, early investor in Facebook, etc. Here are some quotes which really resonate with me:


Peter Thiel pulled an iPhone out of his jeans pocket and held it up. “I don’t consider this to be a technological breakthrough,” he said. “Compare this with the Apollo space program.

The information age has made Thiel rich, but it has also been a disappointment to him. It hasn’t created enough jobs, and it hasn’t produced revolutionary improvements in manufacturing and productivity. The creation of virtual worlds turns out to be no substitute for advances in the physical world. “The Internet—I think it’s a net plus, but not a big one,” he said. “Apple is an innovative company, but I think it’s mostly a design innovator.” Twitter has a lot of users, but it doesn’t employ that many Americans: “Five hundred people will have job security for the next decade, but how much value does it create for the entire economy? It may not be enough to dramatically improve living standards in the U.S. over the next decade or two decades."

...America—the country that invented the modern assembly line, the skyscraper, the airplane, and the personal computer—has lost its belief in the future. Thiel thinks that Americans who are beguiled by mere gadgetry have forgotten how expansive technological change can be.


...without a new technology revolution, globalization’s discontents would lead to increased conflict and, perhaps, a worldwide conflagration.

The theory of an innovation gap as the main cause of economic decline has a lot of explanatory power, but it’s far from axiomatic. Trains and planes have scarcely improved since the seventies, and neither have median wages. What is the exact relation between the two? The middle class has eroded during the same years when the productivity of American workers has increased. (“I don’t believe the productivity numbers,” Thiel said flatly, defying reams of evidence. “We tend to just measure input, not output.”) Why, then, should breakthroughs in robotics and artificial intelligence reverse this trend? “Yes, a robotics revolution would basically have the effect of people losing their jobs, as you need fewer workers to do the same things,” Thiel said. “And it would have the benefit of freeing people up to do many other things. There would be social-dislocation problems, but I don’t think those are the ones we’ve been having. We’ve had a globalization problem.”

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