Skip to content

Instantly share code, notes, and snippets.

@ibrahiminfinite
Last active April 18, 2023 09:55
Show Gist options
  • Save ibrahiminfinite/fe800adbce8d1876e305ab4d5c3cda77 to your computer and use it in GitHub Desktop.
Save ibrahiminfinite/fe800adbce8d1876e305ab4d5c3cda77 to your computer and use it in GitHub Desktop.
Proposal draft for GSoC 2023 - MoveIt Servo

Improved Realtime Control with MoveIt Servo [GSoC 2023]



Abstract

The current MoveIt Servo has enabled users to utilize reactive control. However, in its current implementation MoveIt Servo only provides a ROS interface to users. While the ROS interface is very versatile, it can also be a bottleneck for users who need harder real-time performance guarantees. There are also many aspects of the software design of the package itself that can be improved.

This project proposes to reimplement MoveIt Servo with the following:


Benefits of the improved servo

  • Improved extensiblity allows users to adapt MoveIt Servo to their requirements easily.
  • Pose input allows a robot end effector to maintain the requiried pose in cases where
    • A mobile base or other joints needs to move.
    • There is a need to interact with a moving manipulation target.
  • Adjusting the IK goals at runtime is useful in smoothly transitioning between different types of motion.
    • Inserting a key in a lock and turning it.
    • Picking an object and placing it a basket.
  • Improved realtime performace through the use of C++ interfaces.

Thoughts on design.

The responsiblity of MoveIt Servo as a whole is to convert any type of input to a trajectory in the robot's configuration space. The things that happen within MoveIt Servo can be classified into :

  1. Input specific computations
    • checking validity of input
    • computing the joint states using IK
  2. Validations
    • Singularities
    • Collisions
    • Position and Velocity constraints of joints.
  3. Output specific computations
    • converting joint states to format required by controller.

These are the sequence of events that must happen in a single iteration of the servo loop. The current implementation uses multiple publishers and subscribers to obtain and provide information and locks to synchronize them, there is also some exception handling using try blocks which can slow down realtime performance.

The design can be improved in the following manner adhereing to the principles of OOP and SOLID. (This is purely theoritcal, no experiments have been run to verify the proposed ideas.)

  1. The various input types are currently handled using branching statements and multiple subscribers which result in reduced readability and increased bandwidth consumption. The inputs can instead be handled at:
  • ROS interface using a single subscriber accepting a generic Any message type.
  • C++ interface using runtime polymorphsim through namespaced function overloading.
  1. The IK solver will also be a separate class that provides an IK interface to servo with a default Jacobian based solver.

  2. The output from the input handling function is then fed into the validator class which will enforce all the conditions that must be satisfied.

  3. The different kinds of outputs are currently handled using yet another set of branching statements and publishers. Since the type of required output is known at construction time. We can use interfaces and subclassing to create an output class based on the required output type.

As a result of the above changes.

  • The code will be highly readable.
  • The performance is improved as a result of avoiding locks and branching.
  • The software can be easily extended to handle more input / output types.

Timeline

March 27 - May 4 (Before acceptance results) (in progress)

  • Gain a better understating of the current and potential future requirements of moveit_servo.
  • Evaluate the current implementation for its merits and scope for improvements.
  • Establish a test setup for evaluating realtime performance to quantify improvements.
  • Propose potential improvement strategies and iron out details of the new design.

May 4 - May 28 (Community bonding)

  • Get feedback on the design from maintainers and users from the community.
  • Finalize the design

May 29 - July 10 (Coding Term 1)

  • Implement C++ API for accepting twist command. (June 7)
  • Implement IK solver class and validators ( June 14)
  • Implement output types support (June 21)
  • Implement ROS interfaces. (June 30)
  • Add support for other input types like Joint states, Pose (July 7)

July 14 - August 21 (Coding Term 2)

  • Add test coverage for all functionalities.
    • Add benchmarking tests to verify the input->output loop times.
    • Add tests for all input-output type pairs
  • Any spilled over tasks or bug fixes
  • Documentations and tutorials

About me

  • An Engineer passionate about robotics.
  • Have worked using C++ and Python with some ROS mixed in.
  • Currently on a break from work to discover where I want to be.
  • Working on projects that seem fun.

Some interesting things I have worked on.

  • Robotic manipulators for testing of Human-Machine Interfaces, this involved writing the entire software stack for a manipulator robot from implementing a force controlled actuator controller to simulate human like touch, writing kinematic solvers and writing user interfaces. ( scara , cartesian )
  • Recovery controller for a quadrupedal robot, in simulation. ( was quite fun to see the robot flip over!) ( video)
  • Heightmap based terrain generator for use in simulation. ( code )
  • An exploration goal selection algorithm. ( code , video )

OSS contribution

  • Pyrobosim : ROS 2 enabled 2D mobile robot simulator for behaviour prototyping. ( contributions)

    • Added optimizations
    • Contributed a grid based A* planner.
    • Adding a new extensible planner interface.( in progress )
  • MoveIt2 : Easy-to-use open source robotics manipulation platform for developing commercial applications, prototyping designs, and benchmarking algorithms.

    • Reduce the number of waypoint duration extensions in Ruckig-smoothing (PR)

Why do this GSoC with MoveIt?

  • GSoC lets me work on fun stuff while getting paid.
  • Reading the MoveIt Servo code made me want to rewrite it.
  • Gain experience working within a large and complex software system.
  • I have already worked with the mentors (Sebastian Castro and Andy Zelenak ) in an OSS capacity on pyrobosim, and hence have an established understanding of how to effectively collaborate.
  • As I am on a break from work, the time I have available can be effectively utilised on this project to create more value for the community.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment