Category Archives: Uncategorized

More soft robots

[Picture credits: Tommaso Ranzani]

One of the problems of soft robotics is that some tasks required a high a degree of precision. Knowing exactly where your end effector is crucial and being able to control the “stiffness” of the system is a plus when you need accuracy.

Today I stumbled upon a paper that has a novel approach to deal deal with this issues. It’s a bioinspired soft manipulator by Dr. Tommaso Ranzani (http://iopscience.iop.org/1748-3190/10/3/035008). The manipulator is consists of small segments of Silicone. Each segment has four chambers. Tree chambers are inflatable, and by controlling their air pressure, you can move the manipulator around. Pumping two at the same time move the manipulator toward the deflated one, pumping all tree, extends the manipulator. There is a 6 DOF sensor in each junction. By modeling the orientation of each junction and the length of the segments they can calculate the position of the tip.

So far nothing new. The genius is in the central chamber. This central chamber is filled with granular material (ex. coffee) and by controlling the pressure in this chamber they can controll the stiffness of the system.

It’s the same principle behind John Amend’s and Hod Lipson’s universal robotic gripper.

Waving flags

This animation tool can now control servos using socket.io and Johnny-Five and it’s actually quite fun!  But it is far from production ready. I created a repo for the project: https://github.com/Traverso/go-johnny-go and I have already added a bunch of issues https://github.com/Traverso/go-johnny-go/issues. Nothing major, mostly debris from a rushed prof-of-concept coding spree.

Go Johnny Go

Johnny-Five the original JavaScript Robotics programming framework has a new website http://johnny-five.io! The site looks great and does a god job showcasing the project’s maturity.

One of the many gems in this project is the Animation library. It allows you to control one or more servos by defining small timed sequences called segments. A segment is basically a timeline.
To control the timing of your keyframes you define cue-points. Your keyframes define the position of a target (servo) at a given time.
When you recall your sequence the library automagically controls your servos and perform the described animation taking care of timing, interpolation and even easing for you.

I want to add some animation sequences to Felix. Teach him a few tricks.
But describing the coordinated movements of a set of 8 servos as cue points and rotations is tedious.

Instead i start working on a simple animation editor. The idea is that you edit segments while your board is connected so you can drag and position your servos in real time. In that way you can test/play your segments until you get your moves right.

The tool will let you combine multiple segments into animations and export an animation as a js file that you can add to your own project.

The video below shows my first attempt at an UI using  PaperJS to implement the graphing and interaction.

Improved walk

Today i worked on a couple of things to improve Felix’s walk cycle.
I tweaked the servos offsets to get a more precise placement of the feet. I fixed Felix to the new stand and used a square ruler to get the alignment as god as possible.

Then base on the suggestion by one of the god people at http://letsmakerobots.com, Felix is now leaning to the opposite side of the leg being lifted for every step he takes.

Last but not least he got some socks to get better traction.

First Steps

Working with nodebots/johnny-five has being a remarkably positive experience. Because you can expose your objects to the REPL, it’s a breeze to test/exersize your code without having to upload it to the Arduino every time. The iteration cycle between changes is much, much quicker than regular Arduino sketches and the cognitive dissonance between what I do during the day and in my freetime is non existing.

After implementing the simple trig IK function to control the position of the feet, I implemented two move sequences: “lift & place” and “drag”.

“Lift and place”, lifts the foot from the current position and place it at the requested x value (when the position of the hip is 0). “Drag”, well drags the foot along the ground from the current position to the required x position.

To implement a creeping gait I divide a step into 4 available positions. From position one to five we have a drag and from position four to one when have a lift and place.

Step

In this gait there is always only one foot in the air. The recipe look like this (the green dot represent the foot):

CreepingGait

As you can see from the video, Felix has a heavy limp. I’ll be working on the servo offsets so the small differences between the initial leg positions dont add up.

Next I’ll start playing with some sort of dashboard with AngularJS and sockets.io.

Walking – gaits

Now that we can control the position of our feet and move them along a trajectory we can organise the leg movements into a walking gait.
To start with I’ll implement a static gait. In a static gait at any time during the walk cycle there will be at least tree legs in contact with the ground.  Contrast this with dynamics gaits like  trot or pace where two legs at a time are in contact with ground.

A static gait is defined by the order at which the legs are lifted during the walk cycle. In a crawling gait, for example, the legs are lifted in the following order:

gait

  1. front left leg
  2. back right leg
  3. back left leg
  4. front right leg

To implement a static gait we can split our step trajectory: one segment will be the flight phase (the complete arc trajectory) and the ground phase trajectory will be divided into tree segments.

The start of each segment will be represented by a key position. We can the use this key positions to describe our gaits in a compact data structure. A crawling gait can be then represented as:

int[][] gait = {
{1,4,2,3},
                        {2,1,3,4},
                        {3,2,4,1},
                        {4,3,1,2}
}

Each row represents a step. The four numbers in the row represent the key position for the corresponding leg, starting with the back left leg and moving in clockwise direction.
If we take for example the first row (first step in the cycle), the key positions for the four legs are:

back left leg: 1. key position
front left leg: 4. key position
front right leg: 2. key position
back right leg: 3. key position

With this setup we can generate a trajectory for each leg between it’s current key position and the key position in the next step in the cycle. Then we move each leg through the generated trajectory points until we reach the next step and a new trajectory is generated.

You can download the Processing sketch that illustrates this approach from my repository:  https://github.com/Traverso/Felix/tree/master/Processing/Gait.

In this sketch you will find two different types of static gaits and their corresponding “backwards” versions. Just set the variable “CURRENT_GAIT” to 0,1,2 or 3 to test the different walk cycles.

Welcome to Burning Servos

I love to make stuff and I’m constantly tinkering with multiple projects. Most of what I made and learn has been due to people openly sharing their insights and knowledge.

 

I have always though, “when I complete this project, I will document it and share it as well”. Problem is,  I’m constantly one step behind my own expectations, and I realised that I never be able to catch up.  

So I decided to setup this blog to document processes, experimentations and dead ends in electronics, programming and crafts.