Defining Kinematic Chains in Johnny-Five

[dtex]

Once #411 is wrapped up I want to start working on IK for end effector positioning. To that end I have a thoughts and am soliciting input

Notes

• I'm trying to keep this as simple as possible
• I want to augment existing J5 classes instead of adding new ones
• I'm only considering revolute joints
• Some people won't know what an Eigenvector is but it's relatively easy to measure one
• I honestly have no idea what I'm talking about so I'm tagging @rockbot in hope that she'll have time to take a look :-P

  Define a servo as a link

/**
 * Passing rotate and/or translate properties implies this servo 
 * is a link, but nothing actually happens until this link is 
 * included in a kinematic chain
 */
var servo = new five.Servo({

  pin: [pin],

  // Orient to axis of servo rotation. Default [1, 0, 0]
  rotate: [eigenvector],

  // Offset of the link from this servo to the next servo or end effector, Default [0, 0, 0] 
  translate: [three tuple] 

});

Define a servo array as a chain

/**
 * Add ability to pass an object or an array
 * Passing origin property implies this is a kinematic chain
 * [0, 0, 0] is a valid origin
 **/
var leg = new five.Servo.Array({

  // An array of servos (existing functionality)
  links: [coxa, femur, tibia],

  // Distance from system (robot) center or other arbitrary origin point
  origin: [ three tuple ] 

});

Example:

// Define our joints
var coxa = new five.Servo({
  pin: 9,
  rotate: [ 0, 0, 1 ], // Servo axis is parallel with z axis
  translate: [ 21, 5, 11 ] // x,y,z translation to next joint's center of rotation
});

var femur = new five.Servo({
  pin: 10,
  rotate: [ 1, 0, 0 ], // Servo axis is parallel with y axis. This is rotation from previous axis
  translate: [ 0, 63, 0 ] // x,y,z translation to next joint's center of rotation
});

var tibia = new five.Servo({
  pin: 11,
  // No rotate property means servo axis is parallel with previous servo axis
  translate: [ 0, 54, 0 ] // translation to end effector
});

// Define our chain
var leg = new five.Servo.Array({
  links: [coxa, femur, tibia],
  origin: [ 25, -32, 14 ] // First servo's center of rotation's distance from system origin
});

// Cue magical background maths
leg.position([29, -40, -22]); // Move end effector to a3D coordinate

In animations

ph.coxa = new five.Servo({pin:9, startAt: 45, rotate: [ 0, 0, 1 ], translate: [ 21, 5, 11 ] });
ph.femur = new five.Servo({pin:10, startAt: 180, rotate: [ 1, 0, 0 ], translate: [ 0, 63, 0 ] });
ph.tibia = new five.Servo({pin:11, startAt: 180,  translate: [ 0, 54, 0 ] });

ph.leg = new five.Servo.Array({ links: [ ph.coxa, ph.femur, ph.tibia ], origin: [ 25, -32, 14 ] );

var legAnimation = new five.Animation([ph.leg]);

var step = {
  duration: 500,
  cuePoints: [0, 0.5, 1.0],
  keyFrames: [
    [ [ null, null, null ], { position: [ null, 32, null ] , easing: "outCirc" }, { position: [ 20, -32, null ] , easing: "inCirc" } ]
  ]
};

legAnimation.enqueue(step);

[rockbot]

Hi!!

Let's discuss this in more detail :-)

What's your goal? Also, I have a library I'm working on that might help with this from a mathematical standpoint, but not necessarily from a j5 standpoint.

I also wonder if this sort of thing wouldn't be better as more of a plugin to j5 than an internal module? My general reasoning for that is this goes beyond "jquery for robots" and moves into features that most people don't need/want.

Absolutely happy to discuss - want to make sure I understand your use case fully.

[dtex]

Hi @rockbot!

Re the goal: I've been working on an animation class that uses static scripting to set servo angles at cue points on a timeline. It handles all the tweening and positioning of servos. Finding the angles for each leg and joint at each cue point is tedious. It would be easier to simply set a coordinate for the end effector. One benefit is that we wouldn't need as many cue points. It would also give the user the ability to change the position of the end effector on the fly. A user could change a robot's gait, ride height, chassis angle, etc. They could make it walk in any direction, walk while turning, etc. With static scripting this is not possible.

I think it should be part of Johnny-Five because more people are beginning to build more complex things with nodebots. Being able to leverage IK without having a minors in mathematics would be very empowering and if the surface API is small, inviting and available than more people will take advantage of it. If my animation class belongs in J5 (full disclosure, that's TBD) then this definitely belongs as well.

To that end, I want to provide a super-easy way for J5 users to define a kinematic system/chain on their own robot then call chain.position( x, y, z ) and have J5 handle everything else (the calls to do the actual math, get the desired angles on the joints, and set the position of the servos). The API surface area should be as simple as possible and not require anything more than a basic understanding of the 3D coordinate system.

Since we are limiting to servos, that chain definition can just be a vector that describes the servo axis and a 3D translation for each link (as described in the example above). Chains can simply be servo arrays.

I know about Vektor of course, and I wouldn't be taking this on if Vektor wasn't available. I'm trying to bridge the gap between J5 and Vektor which would become a J5 dependency.

There was a recent Twitter thread that revolved around whether programmers need to be good at math. It seemed silly to me to think that math wasn't an integral part of what we do, but the truth is people come at JS from many varied life experiences and do many different things with it. I witnessed at nodeconf this year just how many good programmers struggle with basic trig (@ the shaders workshop). It's not that they're not capable of course, I think it's just a case of "use-it-or-lose-it". I know I'm having to re-learn linear algebra because I haven't done anything with it since my final exam.

I don't want others to not try building really cool things just because the math is hard.

[dtex]

Oh, and thanks for taking a look. I appreciate your time and input very much.

[rockbot]

I don't want others to not try building really cool things just because math is hard.

I agree with you wholeheartedly here; if there's one thing I hope people take away from my talks, it's exactly that.

The math bit isn't my concern; it's the relevance to j5 that is.

Allow me to use an analogy: adding animations and forward/inverse kinematics to johnny-five is like adding sliders and carousels to jquery. Yes, they're related. Yes, more and more people are building awesome stuff (and more complex stuff, at that), and they should have easy access to tools that make it easier for them to do it.

However, I don't think the complex stuff belongs in the base state of the library.

For new users, the additional complexity will be overwhelming and (frankly) unnecessary. For advanced users, it makes sense to be able to say "okay folks, let's go to the next level!" ...and then get the extra plugins one needs.

I think this work should be done. Once I have access to a computer and a terminal (I'm on vacation right now :-P), I'll happily put up what I have so far on my kinematix library (a wrapper layer to vektor that does almost exactly what you're talking about, @dtex). I'm just not sold on the notion that it should be part of j5 core.

Thoughts?

[rwaldron]

@rockbot this is a really compelling argument; more than just here, I'd like to use as a base framework for all new feature discussions.

[rwaldron]

@dtex @rockbot I propose a kinematics-centric plugin for Johnny-Five component classes, based on Vektor. I nominate you both to work on it together.

[dtex]

This makes sense and I'm really looking forward to seeing @rockbot's kinematix work (I'll be user #1 for sure). Are there any examples of Johnny-Five plugins/modules or would this be the first?

I'll start looking at making the Animation class as separate plugin/module as well. I may back-burner it a bit because I want to make sure it can play nice with kinematix.

[dtex]

I've slept on this and have a counter argument. Please don't read this as a passionate, standing my ground kinda thing. I'm a big fan of keeping things simple, I'm just trying to think it through.

There are ~30 class files in lib. I've used only a few of them. The rest are a mystery. Piezo? I'm clueless. Gyro? Witchcraft! But not knowing how to use those classes doesn't detract from my ability to use and enjoy servo, motor, led, etc. When I'm ready to try out gyro.js I'll go to the docs/wiki. The same would be true for kinematics and animation. We don't have to muck up the existing classes, and when users are ready they will have these tools at the ready.

@rockbot, when asked what constitutes a "real robot" I've heard/sensed/picked up (possibly imagined) that you feel a "real robot" is something that can have awareness of it's environment and make decisions based on that awareness. I feel the same way. My hexapod is a remote control toy and I want it to be a "real robot". I can't do that without these tools.

Considering the jQuery comparison, I agree that much of the high level functionality has been done as plug-ins and only fundamental things are kept in core, but one of those core things is animation. All of those sliders and carousels depend on jQuery's core animation functionality. Since we are dealing with real world things, being able to manipulate and interact with those things in 3D space is critical, therefore we need kinematics in J5's core functionality.

People using Johnny-Five are not elementary and middle school kids (with a few exceptions I'm sure). They're programmers and each and everyone of them is smart, capable and knows something that the rest of us don't. Let's give them the tools they need to make their robot dreams come true.

So, there you have it. My totally dispassionate counter argument :-P

[rwaldron]

Quick note: I don't want to separate the animation stuff.

I'll write more later

[dtex]

Side note: #411 handles tweens of tuples which can be passed to an IK plug-in

[dtex]

I've built a separate module which interfaces with Johnny-Five and gives a framework for defining IK solvers and managing robot state.

It's at https://github.com/dtex/tharp

I propose closing this issue for now and see later if we want to merge in Tharp.Chain and Tharp.Robot as classes in J5.