Mobile Arm Push Button

January 2024 - March 2024, NorthWestern-MSR

All code and documentation for this project is on github at Gray-Stone/robot-push-btm

This project uses low cost robot arm and mobile base to push buttons at everyday home/office environment through remote tele-operation. The main focus of the project is at system integration side, using existing algorism and hardware to create a mobile manipulator system that fits the target working environment. The tele-operation is designed to work with non-robotics experts and tolerate high latency and bandwidth limit.

The hardware choice is an Interbotix WX200 robot arm (5DOF), with a Interbotix LoCoBot mobile base. This choice is made mainly considering the working environment. A much larger 6DOF industrial robot arm with an industrial AGV styled mobile base will certainly be a lot more capable at its reach and capability. However, such robots are usually too large, an in industrial AGV would barely fit through the door way, not to say the industrial robot arm’s mounting, powersupply and connection would be very hard to fit into the home/office environment.

Overall assembily with wx-200 arm mounted on LoCoBot

The software of the system is built using ROS2, as it is the best generial robotics toolsets with integration to most robots. Rivz2 is also used as user interface as a quick proto type.

Key achievements

  • Use of ROS2 libraries and tools: Nav2, Moveit, Rtabmap, etc.
  • Custom C++ and python executable to integrate parts of the system.
  • Custom udev rule.
  • Large amount of documentation for each step of the process, showing design considerations and pitfalls for each component and library used.

The robot can be split into two major sub-systems, the manipulation and the mobile base. The development process first test and built each halfs of the sub systems, then integrate them into the final format.

Manipulation

The basic test bed for wx-200

This stationary test bed is used to check the wx200 robot arm’s ability to push buttons. The frame have mounted some typicle home light switches.

Moveit is used for the motion planning of the arm. With the intel-realsense D-435 camera depth camera to provide user with 3D point cloud for selecting the button to push. A ros2 node is written to initiate user’s selection into a motion planning for the arm in moveit, and execution on the actual arm.

A helper exectuable is created for a interactive alignment process between the wx-200 arm and the camera on the stationary test bed.

The idea is to alight the point cloud provided by the camera and the live 3d model of the wx-200 arm (base on arm’s joint values). After this, extenal objects’s location in the point cloud will also be accurate to the base of the robot arm (throught transformations)

For the arm itself, it is designed with Dynamixel servo motor. However by default, only proportional gains are set. Simply turn on integration gain will let the arm overcome gravity and reach actual commanded position. On the other hand the showder and elbow are prone to over torque at extended pose or high integration gain. Thus the gain is tuned for a balance between enough accuracy without torquing and throwing errors.

For pushing the button, the generic end effector is modified. Instead of a gripper, a hammer shaped round tip is used instead. The round tip simplifies the trajectory calculation greatly, and is more sturdy when applying force. Since the tool is 3D printed, the round head and body of the toop is intentionally designed into two pieces for easy manufacturing.

The basic test bed for wx-200

Mobile base.

The Interbotix LoCoBot base is added with a router to combat the networking difficulty. The Create3 base’s processor is not powerful enough to handle wireless communication and publish all the data at a steady rate. On the other hand, the default configuration provided by Trossen Robotics to use the onboard computer of LoCoBot as a network relay and using ros2-discovery server is also not relyable. Thus a wireless router is added to kept the NUC and Create3 base connected through wire, while letting the remote machine (with user interface) to connect wirelessly.

There are a few changes need to be made from the LoCoBot’s default configuration to have everything working. Overall, rtabmap is used for SLAM and proving mapped point cloud. Nav2 is used for controlling mobile base’s trajectory, and a small ros2 node is written to allow intuitive control of the onboard pan-tilt D435 depth camera.

Here is a video where the robot is drived around the lab and poke at random things.

Integration.

The robot arm is mounted onto the base by “clamping” it onto the flat alumnium deck at the top of the LoCoBot, with 3 pieces of 3d printed adaptors.

Clamp for holding down wx200 robot arm

Both the base camera pan-tilt motor and the wx200 robot arm are Dynamixel motors with U2D2 usb to serial adapter. Special udev-rules are made to disdinguish each adapter and have the proper process conencted to the right one.

Drawbacks and Future work

The main issue exposed during integraiton testing is the inaccuracy of the point cloud from rtabmap’s mapping process. During the stationary test, directly using the depth image from D435 for selecting pusing point result in sufficient accuracy. However, the point cloud from rtabmap, spacially those points generated while robot is moving, is far from accurate. And the rtabmap does not remove bad datapoints from new scans (which is a general problem in this kind of mapping system). This mean re-scanning slowly is not a good solution. On the other hand, I was unable to get the depth image feed from camera due to network issue.

The large amount of data from the point clouds really flooded the wireless network, which also caused huge delay on the visulizaton in Rviz2. I have to use 5GHz wifi for a decent operation, however the range dropoff for 5GHz is also very fast. Given more time for the project, I’m sure both of this network problem can be solved, with ros2 image transport and more optmized network tepology.

Here is a video showing the robot being cable to reach and push the elevator swtich, but had a bad planning and execution due to inaccurate data.

Another future improvement apart from the networking is to add additional depth camera at high point, or even on the robot arm provide better field of view and more accurate data.