Debugging Strategies - RethinkRobotics/sdk-docs GitHub Wiki

What to do when something is just not right? Here are some starter steps you can take when debugging Baxter, or just for when you want to inspect what's going on.

• [Understanding the Problem](#Understanding the Problem)
• [Hardware vs Software](#Hardware vs Software)
  • RSDK Software & System
  • ROS Software
  • Hardware failures
• Viewing Information
• ROS Topics and Messages
  • /rosout (/rosout_agg)
  • /diagnostics (/diagnostics_agg)
• Robot Log Files
  • FTP Log File Server
• ROS Logs & Bags
• Tools
  • Robot Monitor
  • rviz
  • rxconsole
  • rxbag (rosbag) - Record, view, and playback ROS topics (Command-line reference)
  • rxplot - Plot ROS topics data on a simple graph (Numerical and boolean data)

---

 

As a Research SDK user you are in a more free-form environment than standard Baxter customers, and often will be dealing with hardware, software, and environment configurations all at the same time. The first step in figuring out your problem is determing what type of problem it could be.

 

The first question is determining if you are facing a Hardware problem or a Software problem. Many Hardware issues are fairly apparent that something physical is broken - if there's a crack in a screen or a ripped cable, there's little mystery left. Other issues may be internal or electrical and need a bit of investigation to discover. There are a number of tools under the Diagnostics section that will let you monitor the robot for hardware error alerts.

If you face a Hardware problem, you will want to contact your customer service representative and start working with them to further diagnose the issue, and possibly schedule a service call.

If your problem doesn't seem to be related to a physical component of the robot, then you'll need to figure out if the issue is in the Software - and furthermore, which Software. The three major players in the software system will be ROS, the Research SDK (both on-robot and on-development machine), and of course, your own code. ROS introspection features and the Topic/Service based communication help out to easily inspect what's going on when debugging your code. Useful tools include rviz and rxbag (rosbag).

If you think you're having a software problem, checkout some of the other tools on the wiki and also the ROS documentation. If you've found a bug in the software, you can also see if it's in our GitHub tickting system, and if not, please add it! =)

If your problems seem to be dipping into the area of communication issues, there's a good chance that checking into your Network configuration and Environment settings is a very worthwhile step. See the Getting Started - Setup Guide and the Networking page to make sure your settings match the recommended environment. ROS and various network setups sometimes take a bit of TLC. Thankfully there is a great little checklist you can run through over at the ROS wiki that will help you sort out many of the possible issues.

One of the first steps in diagnosing any problem is gathering more information. In this case, that breaks down into diagnostics (primarily hardware issues) and robot