Checking arguments and return types

Two decorators named as @accepts and @returns can be used to check types of functions and methods of a class. In case that an argument passes to the function or method is not from specified type a ValueError is raised, same thing for the return type. Decorators could be used independently.

Example:

>>> @accepts(str, int)
... @returns(int)
... def test_function(a, b):
...   return 1
 
>>> test_function('hello', 100)
... 1

>>> class Test(object):
... @accepts(object, str, int)
... @returns(int)
... def test_method(self, a, b):
...   return 1
    
>>> t = Test()
... t.test_method('hello', 100)
... 1

Code:

def accepts(*args_types, **kwargs_types):
    """
    Decorator to check argument types.

    Usage:
        @accepts(str) for functions
        @accedef accepts(*args_types, **kwargs_types):
    """
    def wrapper(func):
        def wrapped(*args, **kwargs):
            if len(args) > len(args_types):
                raise TypeError("%s() takes at most %s non-keyword arguments (%s given)" % (func.__name__, len(args_types), len(args)))
            args_pairs = zip(args, args_types)
            for k,v in kwargs.items():
                if k not in kwargs_types:
                    raise TypeError("Unexpected keyword argument '%s' for %s()" % (k, func.__name__))
                args_pairs.append((v, kwargs_types[k]))
            for param, expected in args_pairs:
                if param is not None and not isinstance(param, expected):
                    raise TypeError("Parameter '%s' is not %s" % (param, expected.__name__))
            return func(*args, **kwargs)
        return wrapped
    return wrapper

def returns(return_type):
    """
    Decorator to check return type.

    Usage:
        @returns(int)
    """
    def wrapper(func):
        def wrapped(*args, **kwargs):
            result = func(*args, **kwargs)
            if not isinstance(result, return_type):
                raise TypeError("return value %r does not match %s" % (result, return_type))
            return result
        return wrapped
    return wrapper

References:

• Type enforcement in Decorator Libary
• Python check arguments types at Mathieu Leplatre’s Blog

Muliple dispatch

Python is a dynamically typed language, so the concept of overloading simply does not apply to it. However, it is possible to use multiple dispatch (aka multi mehtods) to simulat this behavior. Multiple dispatch is a feature of some OOP languages in which a function or method can be dynamically dispatched based on the run time type of its arguments.

Example:

   >>> from multipledispatch import dispatch

   >>> @dispatch(int, int)
   ... def add(x, y):
   ...     return x + y

   >>> @dispatch(object, object)
   ... def add(x, y):
   ...     return "%s + %s" % (x, y)

   >>> add(1, 2)
   3

   >>> add(1, 'hello')
   '1 + hello'

References:

• Understanding the multiple dispatch technique
• Multiple Dispatch package

The NJ controller is programmed using the SYSMAC Studio IDE and it can control 64 servo-drives through the EtherCAT field bus. Due to that, the visualizer is installed on a normal PC with an EtherCAT slave card; and it runs on Ubuntu 14.04 LTS and ROS Indigo.

The visualizer is composed by two main parts:

• The simulator of EtherCAT slaves.
• The ROS meta-package that visualizes the family of delta robots.

The EtherCAT slave simulator reads the axes commanded positions sent by the controller, forwards them to a ROS node, and closes the loop providing feedback to the controller. After that the ROS meta-package calculates the full positions of the delta robots based on the provided positions and visualizes them using RViz.

The work was done by F. Martí during his winter internship at OMRON Industrial Automation. And in his Vimeo account you could see the video of the system working at the Robotics Lab of the MDT that is placed in Barcelona (Spain).

Information about this project was also published in ROS Blog.

The content of my presentation was:

• Flexible machines: Robotics & Vision
• Path recognition with on-fly robot synchronization
• How the system works
  • Vision process
  • Robotics process
• Easy programming

Ideas of the presentation are: (1) robots represent a ready-to-use solution with large degrees of freedom that allow to simplify the mechanical problems so that the product handling becomes easier and more suitable with the increasing amount of different formats, and (2) vision systems can detect the products and thanks to advanced shape recognition algorithms the teaching of new format get easier.

Therefore, let’s use these technologies to increase the flexibility of the new machines.

Below you could see a video done during PPMA Show 2015, in this video the ideas and technology I was presented in ISOLA conference were shown.

And the conclusions of the talk were:

• Flexible machines will become more and more important.
• Robots and vision systems are technologies that allow to do flexible machines.
• Easy programming is important for machine builders.
• Machine builders require specific libraries, wizards and tools based on family of machines.

Therefore, I developed a GNU/Linux application in C++ and QT. The application was divided in three components: simulations, graphics and model importer.

The simulation of the RU kinematics was done using KDL and a PTP movement using a polynomial 3 profile was created. For the visualization engine I used directly OpenGL.

Below you could a see video of the application that is upload in my channel. And the code is stored in GitHub.

This code was a quick prototype developed due to a special requested, I did it in 25 hours of effective work. As it was I developed in my free time, it is not completed, for example the importer is missing.

This code was used on ROS Hydro and MORSE v1.2-11. And it is available in GitHub.

In this talk I focused on my experience with this technique, and how/when we are applying it in the company I work. You could find the slides I used here.

A laboratory notebook is a document that researchers use for writing their hypotheses, experiments, initial analysis and interpretation of these experiments. And a personal electronic laboratory notebook (ELNB) for replacing a hand-written notebook. This software application is also named as note taking application or personal wiki.

The mandatorory features that this type of application has to have are:

• Local application, not a web server.
• Windows and Linux versions, it should be used in both OS.
• A kind of blog with categories and tags.
• Dynamic tree views of the notes.
• Notes can be ordered by date.
• Caterogies and tags for notes, as in wiki.
• List all notes by creation date, category and tag.
• Inter links (notes links) and external links (files and web).
• Write a note using a WYSIWYG editor.
• Embed images, videos and so on.
• Export notes to RTF, XML and PDF.
• Spellcheck.

And some extra feature that are interesting:

• Drag and drop support for images, text and video, mathematics
• LaTex Eq. support.
• Power search engine: ext, name, date, categories and tags. Use a Desktop Search (Copernic, Google Desktop, etc) application for doing this task could be an option.

TW-WNB as my note taking solution

As I was not able to find any application that matches my expectations after using several of them, I decided to build mine over TiddlyWiki. TiddlyWiki is a reusable non-linear personal web notebook . It’s a single HTML file which contains CSS, JavaScript, and the content. The content is divided into a series of sections, or Tiddlers.

TiddlyWiki has been used by different people as a software framework to build specialisations including task management tool, web clipping tools, a collaborative note taking tool, etc.

My version, named as TiddlyWiki - Work Notebook (TW-WNB) is a tuning version of TiddlyWiki for managing your daily work. It allows you to add to-do tasks by priorities(now/next/future), attach tiddlers to activities (or projects), write meeting minutes and more.

I have created this TiddlyWiki version because no other version satisfies my personal requirements. For doing this I modified some existing plug-ins but I have also developed my own plug-ins in Javascript, html templates, CSS styles, etc.

The source code of this note taking application is in here.

The mouse is controlled by the user using the keyboard and the cat follows the mouse using a CRAM plan.

I used the example that comes with Morse but I have replaced the control script in Python for the cat by a CRAM plan. In addition, I added one pose sensor to the mouse robot and I used this sensor to know its position instead of the semantic cameras of the cat.

For create the CRAM plan I recycled some parts of the tutorials that you can find in ROS wiki. I used the turtlesim controller as base for my cat controller.

The source code is available in GitHub.

And it is really cool!!!

You can see all the pictures I did during the work here.

There is a playlist with all videos in my channel, and the CAD files of robot are stored here.

The delta-2 robot can be seen as a simplification of the delta-3 robot, and it is usually used in the packaging industry for pick products on a conveyor belt. You can see some models here.

Due to its mechanical configuration this robot can only move its end-effector on plane XZ, see figure belowt. And its TCP-0 is defined by (x,0,z).

The kinematics of the delta-2 robot can be solved using a geometric method. For doing this, we model the robot (see figure abowe) using four kinematics parameters: rf,lf, le, re. The parameter rf is the distance between the center of the fixed-frame to the position of the active joint, re is the distance between the center of the end-effector (E) and the position of the passive joint (F), and lf and le are the lengths of the links of a leg. And the link 1 and link 2 of a robot leg are connected in point G.

The algorithms for solving the Kinematics Problem of the delta-2 robot have been developed using Scilab.

Inverse kinematics

For knowing the joins (j1,j2) from the end-effector position (TCP-0) we must solve the inverse kinematics problem.

(le) as radius. And the second circle (red) has point F as center and the length link 1 (lf) as radius. Once you know position of G, the value of the joint is calculated as the angle defined by the axis X and the line that connect F with G, that’s the real position of the link 1.

This method is applied independently for each leg of the robot.

Direct kinematics

And we can calculated the end-effector position (TCP-0) from the joint values (j1,j2) solving the kinematics problem.

The end-effector position (E) is obtained from the intersection of the two circles (cyan) defined by the link 2 of each robot leg. The center of each circles is defined by G and the radius by the length of the link (le). And the point G is calculated by trigonometry using the value of the joint, the length of the link 1 (lf) and the position of F.

The delta-3 robot is a three degree of freedom parallel manipulator. It was designed by Clavel (1988) et al. at the Swiss Federal Institute of Technology. This manipulator robot has only translational degrees of freedom.

It is interesting to have a model of the robot for doing this study .

Analysis of the Robot

The delta-3 robot (DR-3) is composed by two parallel platforms named as End-Effector and Fixed-Framed; and three symmetric legs (see figure below).

The Fixed-Frame (FF) is usually attached to a fixed surface and the tool of the robot is mounted in the TCP-0 which is placed on the center of the End-Effector. The End-Effector (EE) could also be named as travel plate because it is the mobile base of the robot.

Scheme of delta-3 robot

Each leg is composed by two links and three joints (RUU); the actuated joint is rotational (R) and the two passive joints are universal (U). And their position in the robot is named as Fi, Gi and Ei (see previous figure), respectively; where the index i is the number of the leg (1, 2 or 3).

Spheres defined by the passive joints (placed in G and E) and Link 2, and circle defined by the actuated joint placed in F and Link1

F1, F2 and F3 are the positions in the Fixed-Frame of the actuated joints, J1, J2 and J3 respectively.

Kinematics

The configuration parameters of a robot are the parameters which define a specific model of a robot type. For a DELTA-3 robot the geometry of its mechanical structure is directly used as configuration parameters:

• Side length of end-effector (EE)
• Length of link 2, from knee(E) to ankle(C)
• Length of link 1, from hip(D) to knee(E)
• Side length of fixed-frame (FF)

The algorithms for solving the Kinematics Problem of the delta-3 robot was developed using Scilab.

Before building the model, it was designed using the Community Edition of QCAD. The model could be found here and the process to build it here.