Release - v1.1.1

From sdk-wiki
Revision as of 15:26, 15 May 2015 by Imcmahon (talk | contribs) (Links)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
We are pleased to announce the patch-release of a new version of the SDK software – v1.1.1! Baxter Research Robot SDK 1.1.1 is focused on adding fixes to further stabilize the SDK (both on robot and on the development workstation) with ROS Indigo.

Links

SDK 1.1.1 Update Instructions

GitHub 1.1.1 Software Update page

Previous Release: Release - v1.1.0

SDK 1.1.1 Release Notes

Changes

  • Migration from update_robot.py to the rethink-updater command on-robot via SSH

Additions

  • Added torso navigators to control the UI in Demo Mode

Fixes

  • Reduced overall robot restart/shutdown time
  • Added access to cmake, git, and wstool tools for the ruser account
  • Patched on-robot ros_comm Transport Memory leak
  • Upgraded on-robot OpenCV to 2.4.9 and recompiled with several plugins enabled (including gtk).
This fixes an issue that prevented xdisplay_image.py from displaying any image on Baxter's screen when
run from the ruser account
  • Fixed an issue that prevented on-robot ROSBridge from loading and communicating properly
  • Fixed a bug that caused the JTAS to error with a path of one or two points is supplied as a trajectory
  • Fixed an issue that caused the Joint Trajectory Action Server to throw an error when a path
of one or two points were supplied
  • Added use of mktemp in baxter.sh for Arch linux compatibility
  • Added a calculation to increase the amount of time allowed to move arm to the initial
pose of joint_trajectory_playback script in baxter_examples
  • Fixed an issue in syncing gripper playback with joint_trajectory_playback arm execution
  • Fixed a timing issue preventing joint_trajectory_playback from completing execution
  • Fixed an issue where the on-robot /cameras/list service returned only one camera if another camera
was broken (or unplugged)
  • Fixed an issue that caused the on-robot IK service to be too conservative in estimating if solutions
were feasible which resulted in an increase in No Solutions