Path Planning with the youBot Manipulator

We developed a control program in ROS for automating the KUKA youBot arm.  This program takes advantage of the Moveit! ROS package that uses forward and inverse kinematics plan a feasible path for the arm that does not exceed its mechanical limits.  Using forward kinematics, a set of poses were saved and stored under names for quick and easy manipulation of the arm.  From these positions, individual joints could be singularly adjusted, allowing for refinements in positions without wasting significant time planning to unknown locations.  The positions required fine tuning as testing was conducted.

The youBot's manipulator was extensively tested to ensure that the arm could achieve the proper position without hitting certain limits or becoming a potential danger to objects or people within the vicinity of the arm.  One such limit was an overcurrent limit, which was meant to prevent damage to the motors controlling the linkages.  This limit would often be raised when the arm moved significant angles with the base rotation joint.  Part of this testing involved rapid iteration of setting goal positions, planning to those positions, and moving to those positions.  This was completed by writing and running python test scripts that would take user input and automatically set the goal state, plan to it, and move the arm to it.  This testing was done outside of the state machine meant to combine the youBot arm, the youBot base, and the soft robot into a single file controlling the entirely autonomous system.

Upon testing, a path planned with MoveIt! between the pickup and to drop-off positions resulting in a path that interfered with the youBot.  An effective solution was to plan a path with three points instead of two- an intermediate pose was placed between pickup and drop-off which forced the arm to raise the soft robot then plan between positions from a higher point in space where the soft robot would not be entangled in the wires.

Furthermore, to avoid obstructing the camera view and detection of the object to be retrieved, the soft robot had to be dropped off the right side of the robot.  Additionally, when retrieving the robot, the youBot was maneuvered to be just off the left side of the robot.  This prevented the robotic arm from circling almost three hundred and sixty degrees to reach the robot if it was off the left side of the youBot.  From the camera view, the robotic arms base rotation joint was moved in order to pickup the robot.  Since the arm was left in the position that dropped the soft robot on the ground, this was the simplest way to retrieve the robot and object.

Finally, the arm would need to return the soft robot, but the soft robot was now inflated and holding another object.  Because of this, a point higher off the back and centralized to the back plate was chosen.  This provided enough room for the soft robot to stay without rolling off the youBot from its momentum of being dropped.  Throughout all of this, the robot had to have repeatability to consistently be able to retrieve the robot.

Soft-Robot - youBot Manipulation Testing

Once the arm could operate smoothly without interaction with other objects, the arm was tested in moving the soft robot within the state machine created to control both the base and arm of the youBot.  This started with running the required positions without the soft robot, as shown by the attached videos.

Obvious from the videos is the error in the controller, creating significant deviation from set positions and jarring, sporadic motions.  Further refinement was required before the final integration with the soft robot to produce smooth motions.  To solve this issue, the controller parameters were adjusted and the velocity of the arm reduced.  An added  bonus of the reduced arm velocity was the reduced tension on the tubes of the soft robot when integrated.  In the final video found on the integration page, you will see that the arm moves incredibly smoothly and accurately due to the reduced velocity.

Testing Soft Robot Gaits

Unless otherwise indicated, all testing described in this section was conducted on a smooth plastic substrate surface on level ground. The rationale for this choice was to provide a surface that allowed for repeated experiments and may be easily marked to more readily evaluate gait performance.

For the five-legged soft robots, an undulating gait was used to test to move the robot forward. This gait was achieved by inflating the back three legs, then the front two, then deflating the back three legs, then the front two. The legs would inflate sharply and move the contact points with the ground forward, and deflate slowly so the contact points with the ground would not move back to their initial positions. We also developed a turning gait in which one leg was used as a pivot and the other four legs inflated and deflated in sequence. Using these two gaits, the soft robot can move to any point in a plane, with any orientation. By observing how much each gait cause the soft robot to drift while translating or rotating, an open-loop control motion sequence was created to keep the soft robot moving in a near-perfect straight line by correcting for drift, maintaining a heading along the line as well. However, with the turning gait, any change in angle occurred very slowly.

Since the four-legged designs were symmetric, a turning gait was not needed to allow the robot to move to any point in a plane. Instead, by composing the backward/forward motions with side-to-side motions, the soft robot could move to any point in a plane much faster than it would if it needed to rotate. To develop a translating gait, we used a paddling motion motivated by a soft robot gait previously used by Stokes, et. al., 2014.

In this scheme, the four-legged design independently actuated two channels per leg. The back channel would inflate first, increasing the curvature of the leg and pushing the leg forward. Then the front channel would inflate, increasing the curvature of the leg again while pushing the leg back. The back channel would then deflate, pushing the leg even further back and decreasing the curvature of the leg. And finally, the front channel would deflate, decreasing the curvature of the leg and ending the cycle. This sequence could be performed synchronously by diametrically opposed legs to move the soft robot perpendicular to the axis between both legs provided that the deflate times were longer than the inflate times (by the same reason as the undulating gait for the five-legged soft robots). By interleaving the inflation and deflation of opposite pairs of diametrically opposed legs, the soft robot could move quickly in a theoretically straight line while remaining raised up off the ground. To compensate for drift, a simple control system was implemented.

The Arduino code used for the quadruped robot in this project is provided below.

Testing the Grasping Function

The grasping command used for the five-legged soft robot was primarily motivated by the design with one channel servicing all five legs (a design used for gripping). By actuating all five legs at once, the soft robot could grasp items placed below it. Since the five-legged soft robot could not achieve a paddling motion and instead used an undulating gait, it could not raise itself over any objects without external help. This, along with speed, was a main motivator for moving to a four-legged design.

With the quadruped design, we initially attempted to inflate each of the eight channels to grasp objects once the robot had raised itself over them. However, the pressure in the manifold needed to translate the soft robot was too high for the grasping sequence, and while testing the sequence, a channel burst on one of the test robots.

We then attempted to pulse the valves in order to maintain a lower average pressure in each of the channels. With this method, the valves needed to open and close at a high frequency for the legs to hold onto an object (otherwise the pressure in the legs would vary too much around a mean value, and the object being grasped would be dropped). However, with all eight solenoid valves opening and closing at the necessary frequency, dangerous amounts of current were drawn from the Arduino.

To mitigate this problem, the same method was attempted but for only one channel per leg. This solved the problems with current drawn, but introduced new problems with excess strain on the legs now that each leg would twist as well as inflate. We resolved this issue by only actuating four channels on two diametrically opposed legs. This method grasped objects successfully and was used in our final demonstration.