Naming Conventions for Submitted Code [Archive]

Sienna

04-15-2008, 08:12 PM

I might as well start, everyone feel free to shoot holes in what I suggest.

http://forums.trossenrobotics.com/gallery/files/1/6/8/5/coordinate_1_182460_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=204&c=)http://forums.trossenrobotics.com/gallery/files/1/6/8/5/coordinate_1_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=204&c=)

While I know some robots are omni directional, I am going to first suggest that we assign every robot a "front", "left", and "top" side. Then we will need to define some "origin" point. I would suggest that this be the center of mass, geometric center, or some other point easily recognizable as the 'center'. This origin is where we will measure everything else from. For my example, I happened to choose the center of the body (so a geometric center for me), but I raised the coordinate system to the surface of the metal, because I was lazy and that was the easiest to draw.

So, then let me define the three axis that will make up our robot's space:
The X axis points toward the "front" side of the robot.
The Y axis points to the "left" side of the robot.
The Z axis points to the "top" side of the robot.

So, if I wanted the robot to move forward, I would command it to move in the direction of the green X arrow, or positive X.

Then, I need to define rotation. On the left of the image above, I drew three sets of axis. The colors of those axis correspond to the colors used to the right on the robot.

So therefore, I will define rotation as the following:
Rotation about the X axis is 0 at the Y axis, and increases as you rotate toward the Z axis.
Rotation about the Y axis is 0 at the Z axis, and increases as you rotate toward the X axis.
Rotation about the Z axis is 0 at the X axis, and increases as you rotate toward the Y axis.

LinuxGuy

04-15-2008, 08:25 PM

The X axis points toward the "front" side of the robot.
The Y axis points to the "left" side of the robot.
The Z axis points to the "top" side of the robot.
Ummm, you have the X and Y axis reversed. X is left to right and Y should be front to back. :veryhappy: This might affect the rest of your scheme.

8-Dale

Alex

04-15-2008, 08:30 PM

I'm beginning to think that it would be a good idea for all kinematic uploads to include:

a) a "robot-like" image (or multiple depending on complexity). This can be as simple as a stick figure design with circular arrows representing motion.

b) the algorithm (math behind the code, forgive me if this isn't the terminology, way out of my league:D)

c) a code example of the algorithm

Every time a member uploads something into this new system, they have the same interface that we're all used to here in the forums, so we can format descriptions any way we like:)

I'm thinking that by doing this, we can clear up a lot of confusion with naming conventions, especially newcomers to the community. X, Y, Z, Pitch, Yaw & Roll always confused the heck out of me unless I had a diagram right in front of me. Maybe that's just my non-math-skills side talkin though, haha

thoughts?

Also, as far as the code is concerned, what language best supports kinematic routines and is fairly easy to follow? Is C good for this? I know there are a crap ton of nice math methods in .NET, but it's all closed up so it doesn't really help people to understand what's going on behind the scenes.

Sienna

04-15-2008, 08:30 PM

Dale, get a second vote, and I will change it :tongue:

--

Measuring Offsets:

Now, with a coordinate system in place, we need to measure offsets to other pieces of the robot.

http://forums.trossenrobotics.com/gallery/files/1/6/8/5/coordinate_2_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=205&c=3)

I would propose a notation of the following:
<name> [ dX, dY, dZ, θX, θY, θZ ]
Where dX, dY, and dZ are delta's between the origin of the bot and the origin of the first segment of the next item in the chain (in the example above, its a leg).

Alex

04-15-2008, 08:36 PM

Ummm, you have the X and Y axis reversed. X is left to right and Y should be front to back.

My point exactly. In my experience with 3D rendering with developing the TRS, I found that Axis and Rotation is very much a matter of one's perspective. What is X to one person is Z to another. What is Yaw to one is Roll to another, and so on. By defining naming conventions I think it might just open up a whole can of worms that isn't really necessary.

Adrenalynn

04-15-2008, 08:44 PM

Dale's correct.

Hold the fingers of your right hand thusly:

Thumb points towards your face, index finger points straight up and down, middle finger points towards the left.

Your thumb is Z, your index finger is Y, your middle finger is X.

You may now rotate your hand and visualize how changes to one axis effects each axis.

In a zero translation of the Cartesian Coordinate System, Y is always up/down, X is always left/right - the horizon. X to the right is +, to the left is -. Y above X is always +, Y below X is always minus.

Sienna

04-15-2008, 08:44 PM

Yay! I made controversy! :cool:

Anyway, I am paused for the night, brain is shutting down.

Maybe put the whole naming convention thing to a vote?

I see two choices:

1) There are no naming conventions defined, and therefore everyone will use what they are comfortable with. In order to use any code off the database then, the downloader is going to have to scrub that entire project's codebase against the documentation, and then translate the downloaded package's naming scheme into his or her own.

2) There are naming conventions defined, and before you can upload a project, you have to translate your code into the naming convention space.

It will become a question of where do you want to put the work: At the front end on the submitter's shoulders, or on the tail end on the user's shoulders? Is it better to do a task once for the better of all, and risk angering contributors? Or is it better to allow people to contribute as much as they can, but then risk no one downloading anything because its too much work to integrate or use?

Adrenalynn

04-15-2008, 08:49 PM

Actually - I'm disagreeing with Dale too.

Z is depth, Y is Height, X is Horizon.

We could arbitrarily decide that Descartes sucks (and in many ways, I'd agree), but any 3D modeler, mathematician, etal that walks in will be very confused.

A quick search provided this first: http://www.cut-the-knot.org/Curriculum/Calculus/Coordinates.shtml

LinuxGuy

04-15-2008, 09:02 PM

Yay! I made controversy! :cool:

Anyway, I am paused for the night, brain is shutting down.

Maybe put the whole naming convention thing to a vote?
Ahh, Caitlyn,

Every math text I ever used shows the X axis to the left and right and the Y axis to the front and back (or top to bottom) of the page. :veryhappy:

1) There are no naming conventions defined, and therefore everyone will use what they are comfortable with. In order to use any code off the database then, the downloader is going to have to scrub that entire project's codebase against the documentation, and then translate the downloaded package's naming scheme into his or her own.
We need at least a few conventions or nobody will be able to discuss anything about the code or such for kinimatics uploads. We should at least agree on the orientation of the X, Y, and Z axis. :happy:

It will become a question of where do you want to put the work: At the front end on the submitter's shoulders, or on the tail end on the user's shoulders? Is it better to do a task once for the better of all, and risk angering contributors?
I believe the submitter should be responsible for abiding by some simple agreed upon references for submissions, such as orientation of the three axis. This also gives us a good (and required) reference for creating 3D models.

Or is it better to allow people to contribute as much as they can, but then risk no one downloading anything because its too much work to integrate or use?
Code not being used is code and storage space wasted. I think we want to see code used, not sit in a repository suffering bit rot. :veryhappy:

8-Dale

cmmguy

04-15-2008, 10:19 PM

Ok, I am all for conventions as long as it does not limit ingenuity or restrain development.

Here is the auto industries Car Body Coordinates - maybe this is a place to start.

http://www.cmmguys.com/misc/cmmguys/XYZ_car_coordinates.jpg

This works for dimensionals on the body itself. But I could see where the X axis could be reversed so that positive X motion would be forward.

Adrenalynn

04-15-2008, 11:14 PM

There is one very angry very ugly dead Frenchman out there...

If I drew this:

|
|
|
----------

How would everyone lable those axis if they were back in geometry? Careful, this goes on your permanent record... :P

What's another name for the "depth" of a pixel in a 3D scene? _-Buffer

If you want to describe the relationship of one object to another in space, you call it the _-Order where _ is _?

If I asked you to give me the elevation of a line sloping upwards on a piece of graph paper, what axis would you look at first? If I wanted the slope, you'd use "rise over run" - which axis is "rise" on? Which axis is the "run"?

If you want to remove the faces obscured by a near object from a far object, that's called _-Culling where _ is?

One final question:

If you were standing on the street corner and someone approached you and offered you one trillion dollars to give them the integer value of X and Y represented by the blue dot on the graph below, what would your answer be?

http://www.jlrdesigns.com/graphpaper.jpg

---------
After giving this some thought, I think we're worrying too much about X,Y,Z. Since we seem to be thinking about junking the Cartesian Coordinate System, I suggest we call them "Larry", "Moe", and "Curley" instead. Or maybe "Who", "What", and "I don't know"? This works out well, because we can rename "pitch", "yaw", and "roll" to ""Why", "Because", and "Today". If we need to talk about how long it takes something to get someplace, we could rename "t" to "Tomorrow". Heck, we can almost do string theory with just the old Abbot and Costello bit. ;)

Now we'll never having confusing vectors again! BWAHAHAHAHAHA!

metaform3d

04-16-2008, 02:59 AM

There is controversy about this issue even in the 3D graphics community, which has three conventional answers. None are wrong, but one has to pick a standard.

1) Left-handed. The left-handed system came about because early 3D graphics pioneers imagined that +X went right on their screens while +Y went up, which was pretty much how the screen-centric view dictated. Adding the third dimension they saw +Z as going into the screen where all the action was, while -Z went out of the screen going toward their faces into the real world where everything was boring. If you think about it this is left-handed, which makes math majors insane.

2) Z-up. The math majors, on the other hand, imagined the world by looking down on a sheet of graph paper lying on their desk. +X was still to the right, but +Y was away from them in the plane of the desk, while -Y was toward their crotch where everything was boring. Adding the third dimension they used the right-hand rule and made +Z rise out of the desk and hover in front of them, making Z be the direction of up.

3) Y-up. And yet the 3D graphics people are still the ones actually doing graphics, so Y is UP because the computer screen goes left and right, up and down in the real world. So in the world of CGI, although we have finally agreed that coordinate systems should be right-handed, we still think that Y should be the axis of up and down while Z is the axis of into the screen, out of the screen. So as you look into your computer screen right now, +X is right, +Y is up, and +Z is toward your nose.

My personal preference is Y-up, although I can deal with all the other systems. Ultimately it's just a relatively small transform, although it has to be applied at the right point and it can make simple computations a bit more difficult.

LinuxGuy

04-16-2008, 03:53 AM

Actually - I'm disagreeing with Dale too.

Z is depth, Y is Height, X is Horizon.
The Z definition problem! I think we are both right, which is why there has to be a consensus in how we define these. I think for purposes of IK (and I can't say for sure) it would work best with X and Y being in the plane horizontal to the robot and Z being elevation above or below it. I haven't really looked closely at any IK code, so I can't say how it is used with IK.

A quick search provided this first: http://www.cut-the-knot.org/Curriculum/Calculus/Coordinates.shtml
This only defines a 2D, not 3D space, so I don't really think it is applicable here. We have to map in 3D. :veryhappy:

8-Dale

LinuxGuy

04-16-2008, 03:56 AM

2) Z-up. The math majors, on the other hand, imagined the world by looking down on a sheet of graph paper lying on their desk. +X was still to the right, but +Y was away from them in the plane of the desk, while -Y was toward their crotch where everything was boring. Adding the third dimension they used the right-hand rule and made +Z rise out of the desk and hover in front of them, making Z be the direction of up.
I've always used this definition because it just makes sense to me in the real life environment. I think it makes more sense for robotics for the same reason.

8-Dale

JonHylands

04-16-2008, 08:11 AM

cmmguy

04-16-2008, 09:53 AM

In my industry(manufacturing) Z+ is always UP, X+ is to the right, and Y+ is away from you. I believe the origin of this(at least in my industry) is that the machines we use originally were only 2 axis and it was viewed as you look down on the table, which makes X+ to the right and Y away from you - like in geometry. So when the 3rd axis was added to the machines it was away from the table, becoming the new "UP".

Sienna

04-16-2008, 10:29 AM

I really have no personal preference one way or another. But I would like to get a consensus.

So far, I think the most votes have been for a "Z up" scheme, making the axis:
X positive toward the right
Y positive toward the front
Z positive toward the top

Can we proceed with this?
(if so, I will redo the graphics tonight)

Adrenalynn

04-16-2008, 10:31 AM

Can we rename the Axes to avoid confusion? I still like "Who","What", and "I don't know" for the Axes names. :cool:

I propose "I don't know" be "up and down", for obvious reasons that are obfuscated. I'm ambivalent about "who" and don't care about "what".

In the meantime, I'll correct almost thirty years of code to reflect that a Z-Buffer, Z-Culling, Z-Order should now be called "Y-Buffer", "Y-Culling", and "Y-Order" respectively.

And with that parting shot, I'll let it go.

Adrenalynn

04-16-2008, 10:43 AM

In SecondLife, for vehicles, the positive X-axis is forwards, the positive Z-axis is up, and the positive Y-axis is to the left. With my robots, I tend to use the more conventional terms, pitch, roll, and yaw. So MicroRaptor has a RightAnklePitch servo and a RightAnkleRoll servo.

- Jon

Pitch, Roll, and Yaw aren't planes. They are rotations of an object about a plane, translated or untranslated, commonly known as Axes. Under my proposed "AbCostellan Coordinate System" we'll be changing the nomanclature a tad bit, and they would then be known as "throws around the bases". Naturally.

Matt

04-16-2008, 11:24 AM

There are two discussions happening here so I'll ring in on them separately in two posts.
The first half of the discussion is the Format for posting algorithms:

Currently our thinking is to create a Kinematics & Algorithms forum where free for all discussion can happen and hopefully project threads will evolve to solve specific problems. The new downloads section will also have a Kinematics & Algorithms section for the more finished "released" stuff. We are continuing to research all the different forums tools out there for project hosting, tutorial hosting, etc etc. We don't want to jump the gun and buy the wrong thing yet, so we want to learn as we go making decisions as we see where the river goes. (Suggestions are always welcome in the suggestions forum)

Creating Sharable IK Functions @ TRC :)

Our intention was to have the math posted in code as black box / white box functions. This makes them the most usable to a community. The code could simply be posted up for copy and paste (or text file) or an actual program can be created to DL and run. Even if people are in other languages, conversion is easy enough to do etc. Pure math doesn't help programmers too much, functions do :)

If the authors have done their job right the input variables would be clearly defined as well as the output variables and the limitations. Documenting the math involved in the code comments is easy enough to do as well in case someone wants to dig in and alter things. The following are the things I can think of that are important to a good IK function.

General Description, what does it do, what is it made for?
IE: this is a function for calculating joint positions on an arm by the XYZ of the tip
IE: this function creates a trigate walk for a 3DOF HVV hexabot
It is important that we define kind of appendage the function is made for:
IE: 3DOF HVV (Horizontal Joint, Vertical Joint, Vertical Joint)
IE: 2DOF RV (Rotational Joint, Vertical Joint)
(Let's worry about which is Rotational vs horizontal vs Vertical later)

What kind of output?
There are 4 kinds of IK output that I can think of: (second half of the TRAL page (http://www.trossenrobotics.com/tutorials/TRS5.aspx) has visuals)
SASP: Single Appendage - Single Position (one dimension array)
MASP: Multiple Appendage - Single Position (two dimension array)
SAMP: Single Appendage - Multiple Positions (two dimension array)
MAMP: Multiple Appendage - Multiple Positions (three dimension array)

Define the input variables:
Obviously, like normal programing tell people what the input variables are asking for :)

Define the output variables:
See above :P

Define the limitations and error handling:
Most IK functions have limitations as to how far the joints can go until you break the way it was written and the algorithm breaks down. The authors should note this. IE: Joint1 limits = -90 to +90, Joint2 limits = -30 to +120 , etc.

A good IK function will not spit out insane numbers when a user has given inputs that are outside of it's limitations. There should be error catching inside and some kind of logical error output. We as a community could define this as a standard to, hell it could be as simple as returning "OBG" which means Out of Bound Genius...

What say the crowd? Am I missing anything?

--------------
I'd like to raise another side point, All this IK stuff is really hard to code against without some kind of rendering tool. In the past in .NET we used picture boxes and panels to hand render everything which was less than fun. I'd like to open a new thread to discuss ideas for a better solution, please ring in over there if you have thoughts in that area.

Adrenalynn

04-16-2008, 11:32 AM

I think that works out pretty well.

My own personal hopes are that people will contribute what they do best. It'd been cool if I published a piece of code, someone else suggested some optimizations to it, and still someone else slapped a pretty GUI around it.

I can invent some pretty spiffy algorithms, but the representation of my patience for GUI code is shown in the large negative integer set.

A system that invites that kind of shared contribution would be pretty spiffy, imho.

metaform3d

04-16-2008, 11:37 AM

In the meantime, I'll correct almost thirty years of code to reflect that a Z-Buffer, Z-Culling, Z-Order should now be called "Y-Buffer", "Y-Culling", and "Y-Order" respectively.
Beautifully illustrating the "Y-up" convention common in computer graphics. I only mention it because many 3D animation programs feature solvers for inverse kinematics. If you wanted to adapt one -- say from Blender (http://www.blender.org/) -- you'd have to map it to your chosen schema. The transformation is relatively straightforward, but it does add complexity to an already complex subject.

Adrenalynn

04-16-2008, 11:48 AM

AKA "Right Hand Rule" ?

Err - wait, I was supposed to be dropping it. Bad Adrenalynn ;)

Sienna

04-16-2008, 12:04 PM

A computer screen is a sheet of graph paper stood on its side. Thats why CG uses Y up.

I do tend to agree with the Z up people for robotics though, as we operate our robots on the floor, not on the wall. (usually...)

And Adrenalynn, what kind of programmer are you! If we rename them to anything, its Foo, Bar and Baz, you know that! :P

Adrenalynn

04-16-2008, 12:08 PM

Naw, I like the AbCostello Coordinate System better.

There's lots of robots that don't operate on the floor, btw... :P

Sienna

04-16-2008, 12:26 PM

Actually, I want to change my answer:

I would personally prefer to use a Z Down reference. Why? Because it doesn't make sense to me to say "my robot is -5 inches from the ground" (meaning 5 inches above).

I would propose then:
X positive to the left
Y positive to the front
Z positive to the bottom

Anyway, thats what I feel. Since there seems to be not a lot of desire to actually standardize, I might as well take my feelings offline. (hint, standardization isn't easy)

And Matt, I disagree about the code being easy to port. Any moderately complex program is going to be non trivial to port, especially if it makes use of proprietary libraries or language specific functions and concepts.

Matt

04-16-2008, 12:49 PM

I absolutely agree that we need a consensus on a naming conventions and X,Y,Z etc. So let's do just that :)

There are two things we have to define:
1) Our coordinates system
2) How it is applied

1) Our (proposed) coordinates system
I think from all the discussions so far we have safely boiled it down to 2 choices, Y-up or Z-up. Metaform3d laid out the choices nicely and I have to agree that I think Y-up makes the most sense since robotics rendering will be on vertical computer screens. When it comes to rotational values we are big fans of +180 and -180 labeled by the axis around which they rotate which dumps the whole nightmare of pitch, roll, yaw...

That would make our world defined as such:

227

And for Rotational
228
229
230

And combined:
231

2) How it is applied

A main point that we all need to remember is that there really is no absolute XYZ for a robot. Each part has it's own XYZ relative to the part it is attached to. You could consider the XYZ of your main deck the "robot XYZ" but we need to keep in mind that the XYZ of the second knee joint for example really has nothing to do with the XYZ of the robot. It is a very difficult concept to grasp at first for newbies, but it starts to make sense eventually. I like to think of it as sliding backwards down a curvy pipeshaft. You start at your main deck and then travel backwards to the XYZ of the first joint on an appendage (It's XYZ is relative to the center of the main deck) then you travel through the joint to the first rod attached to it, you may turn and twist a little as you move into it's orientation as it's attached to the joint. And so on and so on. All XYZ's are relative to the part it's attached to, but as you are sliding backwards down through the parts your perspective would never ever change. +Y is still "up" and Z is still "forward/backward". But if there was a little person sitting on the deck watching you your XYZ would change all over the place from their reference point. Yes, you know what other little physics area fits nicely with this don't you ;) The beauty of this system is that when you change the Position or orientation of one part, a hip joint for example, the entire rest of the leg swings with it and none of the P&O for those parts changes. It makes other things easy like creating a single leg for a hexapod and being able to just copy it six times plugging it into the body where you need it. The P&O doesn't need to be recalculated for each leg since they are all relative. (I apologize if this is redundant for the more experienced in the crowd. I wanted to lay it out for those new to this area.)

Anyhow, so by defining our "universal" coordinate system that's all we need. Just remember universal is not the same as absolute.

For the TR object model we created the basic parts for building the skeletal structure of your robot and gave them all pins and sockets for connecting together. It made it fairly easy to build any kind of robot you can imagine using just a few basic parts and the coordinate system proposed above.
You can download the super early alpha TROM Manual here (http://www.trossenrobotics.com/media/TROM_Manual.zip). Please read through it and see if you like how it's done. If we can all rally around a model like this then the IK functions can be written to match and essentially be forward compatible with the open standard object model when it comes out. (more on that later)

PS: I LOVE this thread! It feels like a huge breath of fresh air called PROGRESS :) Thanks Sienna!

Matt

04-16-2008, 12:56 PM

And Matt, I disagree about the code being easy to port. Any moderately complex program is going to be non trivial to port, especially if it makes use of proprietary libraries or language specific functions and concepts.

I meant porting exposed functions, not complex programs.

When the code is laid out as just the function in text a programmer can sometimes look at it and figure out what is happening even if it's a new language. A person fluent in two languages can easily translate a single function since it's just a matter of changing syntax.

I agree if the function is buried in a larger program and inside a bunch of project files it would be hard for someone who doesn't have the right software to get at it and convert it. That's why I think that if you have been nice enough to wrap a function up in a demo app then there should also be a side download of the raw function in a text file. Actually, that should be the main file, the program demo is secondary.

Adrenalynn

04-16-2008, 01:17 PM

http://forums.trossenrobotics.com/attachment.php?attachmentid=227&thumb=1&d=1208365672

I thought I was gonna drop it. Wait - did anyone other than me even try to believe that? ;)

I just had to comment with my patented HappyDance(tm)!

I think, Matt, that it's also easier to explain to newbies - the "Right Hand Rule" that I explained earlier (thumb, index finger, middle finger) allows immediate and tactile visualization of not only the resting position, but also translation. We're actually using "The Left Hand Rule" technically in this case. Middle finger is X+ in world-space, index finger is Y+, thumb is Z+. If you rotate (pitch) your left hand in this configuration such that your index finger is pointing at the wall, we find that Y+ is space and Z+ is height, whilst X+ remains constant towards the right. This translation gives us what some others here seem to have been asking for. So all they have to remember is to pitch their hand such that their index finger is pointing at the ceiling instead of pointing at the wall, and their translation becomes world-space. It's really easy to visualize (IMHO).

Definite HappyDance.

>> PS: I LOVE this thread! It feels like a huge breath of fresh air called PROGRESS :) Thanks Sienna!

I couldn't possibly agree more strongly, Matt. Yes, thanks Sienna and all involved. I argue passionately, but it's just my normal "Architect Instinct" of beating things down until all the parameters are explored and an informed decision gets made. Nothing personal at all!!!

Adrenalynn

04-16-2008, 01:20 PM

Matt

04-16-2008, 01:49 PM

>> That's why I think that if you have been nice enough to wrap a function up in a demo app then there should also be a side download of the raw function in a text file.

Which would eventually allow for libraries of common interfaces to be created, which leads to an API, which leads to SDK(s), which leads to an eventual common goal, right? :)

Damn right. :) I get giddy over the prospect of a object model standard with a million computer programmers working off of it. It would do the same thing for robotics that windows did for the computer. Help the technology explode and take off from the benefit of thousands of individuals and companies all plugging into a common system.

Adrenalynn

04-16-2008, 01:56 PM

>> into a common system

"Common non-proprietary/extensible system"

It annoys me that using RIOS or even Roborealm (which is an awesome "free" product, don't get me wrong!) would basically require me to have multiple computers on the 'bot for non-tethered operation, or at the very least, multiple windows apps fighting for resources on a machine with multiple com ports... If these were really extensible platforms (and Roborealm at least tries to do so to an extent whilst keeping the system closed by exposing a plugin interface), we'd be able to mesh both of those together and have shared/interchangable GDI resources

I can certainly see your vision of the future, Matt!

JonHylands

04-16-2008, 02:03 PM

Personally, I love the way RoboRealm works - I would much rather connect to something using a socket, because then it doesn't matter what language it is written in, and it doesn't matter what language my code is written in.

With multi-core CPUs more the norm now, running multiple applications on a robot PC is actually a good thing...

- Jon

Matt

04-16-2008, 02:16 PM

"Common non-proprietary/extensible system"

Yes, correct :)

LinuxGuy

04-16-2008, 05:08 PM

Naturally.
He's in the outfield.. :happy::happy:

8-Dale

LinuxGuy

04-16-2008, 05:11 PM

So far, I think the most votes have been for a "Z up" scheme, making the axis:
X positive toward the right
Y positive toward the front
Z positive toward the top
I think this is appropriate for robots, as well as any other vehicle. Is this going to muck us up for discussing existing code?

Can we proceed with this?
(if so, I will redo the graphics tonight)
Go for it as far, as I'm concerned. It seem reasonable to me.

8-Dale

Sienna

04-16-2008, 05:12 PM

Ok, where to begin.

First, not to sound (too) snide, I see a bunch of computer graphics people trying to make a computer monitor's worldspace the gold standard. I honestly believe this is the wrong way to go. The intent of robotics code is to drive robots, not fancy graphics. Fancy graphics are useful for troubleshooting yes, but they are by no means a real robot.

Admittedly I have only been working in industry for four years. (UGVs for the first 1.5, and UAVs the rest. At work I am what is called a "systems engineer". Basically, I am a jack of all trades, and have visibility and input into every portion of the system, hardware and software [and logistics and test and reliability and electrical and human factors and on and on.]) And I have never seen anyone try and map a computer screen to the real world. All the architectures I have seen, X and Y form the ground plane, no exceptions. This is particularly true in planning software (like mapping and obstacle avoidance). And honestly, I will probably fight real hard for an X-Y ground plane, as I want to keep the same coordinate space for planning algorithms as IK code. (At least for that "body" object, it should be defined in world space)

So, while I respect that the computer graphics industry uses Y up because they don't stop looking at monitors, I whole heartedly disagree about the appropriateness to robotics.
(Oh, and I don't think the entire industry agrees anyway... I ran UG at work, and the isometric view was Z up. I ran Rhino, and the perspective view was Z up. Honestly, I think Z being the "height" field on a computer monitor is only applicable to 2D views and overlapping, but I could be wrong.)

Second, I think we need to stick with a right handed coordinate system. This is MUCH more familiar to people then a left handed coordinate system that is being proposed. So, even if we did use a Y up system, I am going to insist that positive Z be toward the wall behind the monitor.

---

On other topics: I am aware of the whole chained origin thing, I just hadn't gotten to that yet because we can't even agree yet on a world coordinate system. And robots will have an "absolute" coordinate, as I said before that will be used by planning algorithms.

I am not so much of a fan of that object model at the moment Matt, it seems to lack expressiveness. When I did an interface between an autonomous planner and vehicle (the vehicle was responsible for telling the planner what it looked like), the language we defined was a lot more verbose. I am willing to help you define it, but I would like to see the object model definable to sufficient level of detail that I could actually use the same object model and draw a robot with our object model renderer, or use the same object model and do collision detecting.

At some point also, we need to get back into the discussion of how to define "horizontal", "vertical", and "rotational", because that is also lacking :P

LinuxGuy

04-16-2008, 05:43 PM

Currently our thinking is to create a Kinematics & Algorithms forum where free for all discussion can happen and hopefully project threads will evolve to solve specific problems.
Might I offer a bit more general name for the forum and propose "Algorithms, Code, and Robots, Oh my!" to allow for all sorts of different code and algorithms to be handled. It covers it all pretty well, I think, from A to Z (and FK/IK in between). :veryhappy::veryhappy: It also allows for navigation algorithms and code, sensor processing algorithms and code, image and vision processing, etc. All of these are very much necessary in robotics and should not be left out in the cold. :happy: The files area should be named similarly, of course. Even behavior based robotics fits in here, with the likes of Subsumption and many others.

Our intention was to have the math posted in code as black box / white box functions. This makes them the most usable to a community. The code could simply be posted up for copy and paste (or text file) or an actual program can be created to DL and run. Even if people are in other languages, conversion is easy enough to do etc. Pure math doesn't help programmers too much, functions do :)
Well documented and written code should spell out the math. Even though it can often hurt my head (literally), I want to understand what I am doing. Good programmers can turn a good algorithm itto good code, with documentation. Programming phase angle calculations in electronics in Pascal was a trip, and I enjoyed it (imaginary numbers and all). I had to really understand the equations to do the coding though and make it work. Hopefully people will not walk away with just some code to plug into or modify to what they need (and they will contribute back any modifications they make), but also understanding (which I want very much).

If the authors have done their job right the input variables would be clearly defined as well as the output variables and the limitations. Documenting the math involved in the code comments is easy enough to do as well in case someone wants to dig in and alter things. The following are the things I can think of that are important to a good IK function.
Definition of all input, output, and intermediate variables and constants is a must. I hate having to figure out what n, o, and p are - it takes the joy out picking new code apart, which I had to do for four long years (maintenance programming, and some upgrading that turned into rewritting more often than not).

In short, there can never be enough documentation because you never know who is going to be reading your code or what their native language is. Think of your code as an ongoing resume'.

I very much hope to gain understanding of areas I don't currently understand and want to work with, including kinematics. I also hope to contribute code of my own and maybe even help translate some algorithms into real usable code.

8-Dale

metaform3d

04-16-2008, 08:48 PM

I would say that Z-up is more appropriate for robotics for two reasons:

1) Graceful degradation. In the real world the two axes of movement that are orthogonal to gravity are logically similar, while the one in opposition to gravity is different. Robots tend to explore the 2D space while only rarely trying to climb stairs. This means that if you have an algorithm that does something in 2D, like path planning, you want to be able to use it even in the context of an overall 3D system. In most languages treating a 3-component vector as 2-components is trivial if all you want to do is ignore the third component. If you have to ignore the middle component, then it's not so easy. There's also something perverse about having to plot the floorplan of your house in X and Z.

2) Standards. In fact there is already a sub-field of robotics that has standardized on Z-up: CNC fabrication equipment. Anything that outputs G-code for a milling machine or laser cutter is using a Z-up system. Often, as above, the Z coordinate is not really used except to indicate if the tool is on or off.

That said, the transformations are not hard, and if there was a piece of code that assumed Y-up coordinates it would be easy to wrap it to see the world as Z-up. It's also possible to do 3D graphics in Z-up. 3D MAX is Z-up I believe, and even for Y-up systems it's a simple matter of inserting a transform.

I think the far more interesting problem is the one of language and infrastructure. For myself I would like to get code in C or C++ to run on a PC. I'm also not a big fan of third-party libraries, even if they are open-source. Tracking down interdependencies and getting incompatible APIs to work together sounds more like work than fun to me. (Probably because it IS my work!)

Matt

04-16-2008, 09:02 PM

>>>Anyway, thats what I feel. Since there seems to be not a lot of desire to actually standardize, I might as well take my feelings offline. (hint, standardization isn't easy)

Whoa! It hasn't even been 24 hours yet! Give it some time. LOL, she's more impatient than me! Alex, Jen, Dave, come look at this!! SEE I TOLD you that I'm not the worst after all :) (Just giving you crap Sienna (and myself actually), I hope that's OK) Actually I think this exploding thread shows that there is a huge desire to standardize. Just let people air their thinking and arguments for a few days. I think there have been plenty of people saying they are flexible.

>>>>All the architectures I have seen, X and Y form the ground plane, no exceptions. This is particularly true in planning software

Personally I don't care about which way Z and Y end up. They are just letters to me. Ironically our model was Z-up until this morning when I switched it prior to posting since it sounded like that's where the consensus was going. Now it sounds as if it's going Z-up. I can take it either way, so that's my input on that. I just wanted to get some graphics up and formalize the discussion a bit. We weren't trying to solidify anything yet.

There are lots of good points with many logical arguments for one over the other. In the end, what ever gets chosen, SOME of the people will have to switch. There is no way around that. Not one person will get it all their way.

>>> I am going to insist that positive Z be toward the wall behind the monitor.

Please don't insist. No one should be slamming fists down on anything. When you are discussing world space, yes, that makes sense. But when it comes to linking parts together a positive # going away from "you" sends the robot part further "into" the previous part which also is not intuitive. It would make sense that a positive # heads toward you or "out" away from the robot. Again, no matter what we choose there will be non-intuitive results here and there. There is no avoiding it.

To be honest, I can live with either way in the end. The only two things that I happen to think are the most "intuitive" that I hope stay are positive goes to the right and up.

There has been a good deal of talk about the world space and planning programs which is very different from the angle I was taking. I was/am focusing on the way robot structures are defined and haven't been concerned with the world outside the robot yet. It's good that both are being defended and discussed. One thing is clear though, what ever system we choose will need to be the same for both in order to keep our sanity.

>>>>I am not so much of a fan of that object model at the moment Matt, it seems to lack expressiveness.

That doesn't surprise me now knowing your experience. But the good news is that it lacks complexity on purpose currently. It's supposed to be bone dry simple because we were aiming it at the hobby crowd of CS developers getting into robotics. The model right now was mainly about creating a method for defining skeletal structure. 99% of robots at the hobby level don't need anything more than a model that defines their basic structure, appearance, and ways for storing the actuator, sensor, and controller info. Hobby arms, basic wheeled bots, basic walkers all get by on very little data to run around your basement. So I understand why anyone with real world experience in bots or simulation environments would blanch at seeing such a stripped down model.

Now, that being said, the model was consciously built to be rock solid for layering all the different things you mention on top of it. We sought to build a model that would be easy to serialize in and out of XML. What we freely admit we don't know is rendering and data storage for complex physics, that's why we didn't go near it except to create a laughably basic set of rendering shapes. We figured people would come along who knew that world and step in on those levels. Sounds like we were right :) I probably should have mentioned this up front. Sorry.

In the manual you also aren't seeing any info about sensors, motors, or controllers. It's just not documented yet. We have an architecture for most of that and it is designed to also be elegantly simple while extremely expandable without any one organization or entity dependent upon managing code. IE: non proprietary or resource heavy on any single organization. Our #1 philosophy during the whole design was "NO BOX".

I propose this, Sienna, Adrenalynn, robotguy can I get you to schedule some time to talk on the phone so I can go over what we have worked on so far here in depth? I'd like to have a chance to explain in full what we have learned here and what our ideas are. It will help to chat in person for some of this discussion, it's fairly hard to get it all in a thread. Anyone else who also thinks that they want to donate time and effort into where this is headed who also would like some one on one time with me please PM me and I would be glad to talk. I'll catch who I can on Thursday, Friday I'm on my way to Vegas so PBBBTBTBTB!! Next week is pretty open.

>>>>Might I offer a bit more general name for the forum and propose "Algorithms, Code, and Robots, Oh my!" to allow for all sorts of different code and algorithms to be handled. It covers it all pretty well, I think, from A to Z (and FK/IK in between).

We are actually on the same page on this. We intended it to be for all the examples you mentioned, broadening the name choice for the forum to reflect that is cool with us.

Thanks everyone for all their input on this and again to Sienna for being an instigator ;)

Alex

04-16-2008, 09:22 PM

holy crap! and you always yelled at me for going on too long, haha;)

Sienna

04-16-2008, 09:25 PM

I am not impatient!!!!! :tug :tug

I just expect everything to be resolved within 10 minutes of when I post something! Is that too much to ask! :rolleyes: :veryhappy:

(ok ok... so maybe I am a little impatient... :o)

(oh, and yes, please, give me crap... Its absolutely no fun unless its tit for tat!)

>>> Please don't insist. No one should be slamming fists down on anything.
D**m it, I seem to be doing it again. I tend to have that problem at work too...

As I implied earlier, I am young. So I have the young 'know it all' syndrome. And there are times when I can get very possessive of things, so let me apologize for that too! But whats really funny, is that outside of integration / engineering like things, I am mild as rainwater. Heck, most of the time, I can't even decide what I want to eat for dinner!

LinuxGuy

04-16-2008, 09:54 PM

Actually I think this exploding thread shows that there is a huge desire to standardize. Just let people air their thinking and arguments for a few days. I think there have been plenty of people saying they are flexible.
I agree that we need at least a few standards or we won't be abe to discuss or deal with this once it is going full speed. I think what Trossen is doing with this and wanting to do with this is great and much needed. I believe the Z up/down, Y forward/backward, and X right/left just makes more sense than any other 3D model for this stuff. Z up, Y forward, and X right all being positive. This is all with respect to the robot facing forward (and yes, I realize some robots don't have any real "front", like a certain Tri-Pod, and round hexapods/octapods), as I think it should be.:veryhappy::veryhappy:

There are lots of good points with many logical arguments for one over the other. In the end, what ever gets chosen, SOME of the people will have to switch. There is no way around that. Not one person will get it all their way.
Whilst I may not be entirely happy with the way it turns out, it will just be good to be able to communicate on a common ground as far as terminology and orientation goes. I just want the end result to be logical and make sense. Please let the orientation be centered on the robot.

I propose this, Sienna, Adrenalynn, robotguy can I get you to schedule some time to talk on the phone so I can go over what we have worked on so far here in depth? I'd like to have a chance to explain in full what we have learned here and what our ideas are. It will help to chat in person for some of this discussion, it's fairly hard to get it all in a thread.
I'm OK with that, and can easily flex around what everyone else wants time wise. I don't have a job or school to deal with and am home most of the time. Just tell me when you need me on the phone.

We are actually on the same page on this. We intended it to be for all the examples you mentioned, broadening the name choice for the forum to reflect that is cool with us.
I thought that would be the case. :veryhappy::veryhappy: I think it would be a fun title too. :veryhappy:

8-Dale

LinuxGuy

04-16-2008, 09:59 PM

Heck, most of the time, I can't even decide what I want to eat for dinner!
Pancakes with strawberries and whipped cream. That's what you should have for dinner! :veryhappy:

8-Dale

Adrenalynn

04-17-2008, 01:54 AM

>>>> Please don't insist. No one should be slamming fists down on anything.
>> D**m it, I seem to be doing it again. I tend to have that problem at work too...

No sweat here, Sienna - I understand, and Matt's a software hack too. Can't make the proverbial omelette without breaking a few legs - err - eggs, right?

If no one gets passionate about it then the final result will suffer, in my experience.

Adrenalynn

04-17-2008, 01:59 AM

He's in the outfield.. :happy::happy:

8-Dale

[actually - there wasn't a "Naturally"]

No - you throw it to who.
Naturally
Naturally.

So I pick up the ball and throw it to Naturally.
No you don't, you throw it to Who
Naturally
Naturally.

That's what I said!

No it isn't!

:)

Matt

04-21-2008, 01:46 PM

We are going to lock the few TRS related threads for a few minutes to do some organizing. (Starting up a new forum to house it all.) So bear with us for a moment while we kick up a little construction dust.

Matt

04-21-2008, 03:38 PM

First off, I wanted to thank everyone for chatting last week. I had fun meeting you all and I'm truly excited about this group that we are putting together.

As you all can see, we have just made a new forum dedicated to the TRS open source project. For now we will carry out the discussions in threads here and we will then evolve to implementing project management tools like subversion and what ever else we decide we need.

I'm going to try to break up the three original threads into multiple threads so that we can have 1 topic per thread. Currently there are far too many issues being discussed in the same threads and it's making people's heads hurt :P We aren't sure yet how "open" these forums will stay, I doubt letting anyone who wants to post in here once the ball gets rolling is a great idea, however we don't know what happy medium is best yet.

Let's start by pulling the discussion in this thread back to it's original intent, to agree upon a coordinate system and labels. Let's also just focus in on it being position and orientation stuff. Anything beyond that should get it's own thread.

I believe that we have a consensus that Z-up with + heading Up/Out/Right makes the most people happy. Is this so?

If that is the case then we need to move on to the pitch yaw roll stuff. Let's debate that out. I'll start with what we chose for the TRS and let everyone ring in from there. We liked to just call it the "[axis] rotation" to make life simple. We also used the +/- 180 system. (There probably also doesn't have to be a limit of 180. Plus or minus indicates direction and then you have your degrees.)

Z rotation = spinning in place (+ is spinning to the right, - is to the left)
Y rotation = cartwheels (+ is wheeling to the right, - is the the left)
X rotation = summersaults (+ is rolling forward, - is backflips)

LinuxGuy

04-21-2008, 04:03 PM

As you all can see, we have just made a new forum dedicated to the TRS open source project. For now we will carry out the discussions in threads here and we will then evolve to implementing project management tools like subversion and what ever else we decide we need.
It is a great idea! Now we know where to go to find all the different threads this project will no doubt spawn.

I'm going to try to break up the three original threads into multiple threads so that we can have 1 topic per thread. Currently there are far too many issues being discussed in the same threads and it's making people's heads hurt :P
Now I know why my head was starting to hurt! It is difficult to impossible for me to track stuff sometimes when there is so much going on.

We aren't sure yet how "open" these forums will stay, I doubt letting anyone who wants to post in here once the ball gets rolling is a great idea, however we don't know what happy medium is best yet.
At minimum, everyone should be able to read, and there should be at least one topic where anyone can post. Otherwise, it should probably be group only for posting/uploading attachments/ starting new threads, for awhile at least. We need at least one topic where interested parties can make suggestions, request to join, etc. We will no doubt find others we would like to have join us as time goes on. I just tried to get one young fellow to consider coming over here the other night, but he does not apparently appreciate the value of working together for a common goal. :sad:

I believe that we have a consensus that Z-up with + heading Up/Out/Right makes the most people happy. Is this so?
It seems reasonable and logical to me.

If that is the case then we need to move on to the pitch yaw roll stuff. Let's debate that out. I'll start with what we chose for the TRS and let everyone ring in from there. We liked to just call it the "[axis] rotation" to make life simple. We also used the +/- 180 system. (There probably also doesn't have to be a limit of 180. Plus or minus indicates direction and then you have your degrees.)

Z rotation = spinning in place (+ is spinning to the right, - is to the left)
Y rotation = cartwheels (+ is wheeling to the right, - is the the left)
X rotation = summersaults (+ is rolling forward, - is backflips)
Each plane can be rotated by each of two axis..

The X plane can be rotated by the Y or Z axis (two directions)
The Y plane can be rotated by the X or Z axis (two directions)
The Z plane can be rotated by the X or Y axis (two directions)

So, each plane has two axis of rotation in each of two directions.

This might make my head hurt, trying to figure out how to define these in terms of a 3D space, although this is how Alibre Design handles it. I just usually ignore the axis and planes for the purposes of what I do in 3D CAD, but probably shouldn't do that.

8-Dale

metaform3d

04-21-2008, 04:14 PM

Something that might also be useful is deciding on the memory layout of matrices. There are two ways to do it -- some of the tradeoffs described here (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=236964) and here (http://steve.hollasch.net/cgindex/math/matrix/column-vec.html). Sorry for more 3D graphics stuff, but matrix math is essential in FK and IK computation, and constantly "swizzling" matrices can be an unnecessarily slowdown.

Adrenalynn

04-21-2008, 04:16 PM

Run, don't walk, and create a new thread for it Metaform [in the new TRS forum]! Excellent point.

Matt

04-22-2008, 12:38 PM

Z rotation = spinning in place (+ is spinning to the right, - is to the left)
Y rotation = cartwheels (+ is wheeling to the right, - is the the left)
X rotation = summersaults (+ is rolling forward, - is backflips)

Not much response to this. Do people like it?

Sienna

04-22-2008, 12:58 PM

I still have to point out the 0 to 360 notion used in mapping for the Z axis.

And I haven't really responded yet cause I haven't studied metaform's links. (linear algebra always hurt my head :()

Matt

04-22-2008, 01:43 PM

I still have to point out the 0 to 360 notion used in mapping for the Z axis.

And that is fine. I was mentioning earlier that people could go over 180 if they want to. It's just that when dealing inside the model there isn't much point in it. the +/- indicate direction and then you can use what ever degrees you like. It should work fine for both ways.

And I haven't really responded yet cause I haven't studied metaform's links. (linear algebra always hurt my head :()

I told you that you weren't the only impatient one around here :)

Alex

04-23-2008, 08:47 AM

I haven't replied yet, because I can go either way and am happy with whatever the community agrees upon. This sort of stuff always hurt my brain (hehe, yeah, I stole your quote:D) too, so as long as we all agree on something, I'm cool with it;)

metaform3d

04-23-2008, 01:39 PM

I believe that we have a consensus that Z-up with + heading Up/Out/Right makes the most people happy. Is this so?If I understand you correctly you are saying that for a person standing on the ground, forward is +X, right is +Y, and up is +Z. This is a left handed coordinate system, which I would not recommend. If you want +X to be forward then +Y has to be to the left.

Z rotation = spinning in place (+ is spinning to the right, - is to the left)
Y rotation = cartwheels (+ is wheeling to the right, - is the the left)
X rotation = summersaults (+ is rolling forward, - is backflips)The rule I like to use here is one that preserves the right-handed relations between the axes. Specifically the cross-product relations:

X x Y = Z
Y x Z = X
Z x X = Y

For rotations we want the positive rotation around the third axis to be the one that brings the first axis towards the second. Another way to think about it is that positive rotation is the direction you have to turn a right-handed screw to make it move along its axis in the positive direction. So:

+Z rotation = spinning to the left (removing a screw from the top of your desk)
+X rotation = cartwheel to the right (driving a screw into the front of your desk)
+Y rotation = somersault forward (driving a screw into the right side of your desk)

Matt

04-23-2008, 02:25 PM

If I understand you correctly you are saying that for a person standing on the ground, forward is +X, right is +Y, and up is +Z. This is a left handed coordinate system, which I would not recommend. If you want +X to be forward then +Y has to be to the left.

Actually, you have Y and X flipped.

This much I think the group has agreed on whole heartedly
+Y heads strait out
+X is the horizon heading right
+Z is the stripper pole heading up :)

I see a point you've made about sticking to either all left handed or right handed rotation. I was going with keeping + in all the same directions. (go right, cartwheel right / go forward, tumble forward / go up, spin right)

So left handed would make rotation:
Z rotation = spinning in place (+ is spinning to the right, - is to the left)
Y rotation = cartwheels (+ is wheeling to the left, - is the the right) <--- ick
X rotation = summersaults (+ is rolling forward, - is backflips)

And conversly right handed would make rotation:
Z rotation = spinning in place (+ is spinning to the left, - is to the right) <--- ick
Y rotation = cartwheels (+ is wheeling to the right, - is the the left)
X rotation = summersaults (+ is backflips, - is rolling forward) <--- ick

for reference: the matt hybrid :P
Z rotation = spinning in place (+ is spinning to the right, - is to the left)
Y rotation = cartwheels (+ is wheeling to the right, - is the the left)
X rotation = summersaults (+ is rolling forward, - is backflips)

Personally, left handed is far more intuitive to me, but right handed may be more popular

http://www.xvrml.net/tutorial/images/rightHandRule2.png

So I put this to the community: Do we want to stick with the left or right hand rotation rule or do we like the hybrid? We will go with the majority vote, if need be I'll post a poll.

LinuxGuy

04-23-2008, 02:25 PM

metaform3d

04-23-2008, 02:46 PM

This much I think the group has agreed on whole heartedly
+Y heads strait out
+X is the horizon heading right
+Z is the stripper pole heading upSorry, I thought that's what we had decided on but I got confused. By "out" you mean forwards.

So I put this to the community: Do we want to stick with the left or right hand rotation rule or do we like the hybrid? We will go with the majority vote, if need be I'll post a poll.So let me make the case more clearly. The point is for rotations to be invariant under transformations. For example if you take an arm that's normally mounted on the top of a robot and mount it on the side, you can adapt the code by just transforming the coordinate system so that +Z is to the right, +X is forward and +Y is up. The rotations are still all the same. If you mix right and left handed rotations you'll need to insert a -1 someplace and it's often really hard to figure out where.

If people are really wedded to +Z rotation taking you to the right then I suppose using a consistent left-handed system could work. I suspect there are cases where you'd have a -1 in your equations, but it might be for more complex problems than transformations.

As a tie-breaker you could look at what OGRE does. I'd lay odds that it uses right-handed rotations.

Sienna

04-23-2008, 06:21 PM

personally, I was trying to keep a right handed system too, as I think that is a little more prevalent then left.

metaform3d

04-23-2008, 08:04 PM

I've thought of a better example: servos. Let's call a servo that has the primary axis aligned with +Z a "z-positive servo", like the one sitting on its base on your desk there. Imagine connecting three of them in series: z-positive connected to x-positive, connected to y-positive. You now have a rig that will orient the end-effector at any angle, so you just have to write the code to do it. If you use a consistent handedness then the code for all the servos is the same -- for any axis X, Y or Z, you send the same signal for the same angle. If you mix handedness you'll have to invert servo signals depending on which axis they control.

As for the choice of right or left-handed, I think that the left turn for right-handed Z rotation is actually what people would expect. If you forget about Z and look down on the robot coordinate system, it looks just like normal graph paper: +X to the right and +Y up. You'll recall from high-school geometry that angles are defined to increase going counter-clockwise. If you go back to 3D space this is a left turn for positive rotation on Z.

(Sorry to be pedantic about this. I've been doing matrix math all day at work.)

LinuxGuy

04-23-2008, 08:39 PM

I've thought of a better example: servos. Let's call a servo that has the primary axis aligned with +Z a "z-positive servo", like the one sitting on its base on your desk there. Imagine connecting three of them in series: z-positive connected to x-positive, connected to y-positive.
You're going to have to describe the orientation of the servos better and assign which axis is length, width, and height of the servo. You'll also have to define whether length, width, or height is in play and what the "normal" orientation of a servo should be considered as being. I don't think it can be done, because there is no normal and accepted orientation for a servo. :happy:

Regardless of how you orient servos, there are going to be cases where things are going to be flipped. You just have to make adjustments for that and go on. I call this process normalizing (different from centering) servos. I do this by applying a +1 or -1 multiplier to the angle I want to move a servo to, after I know how the servo orientations work out. This will not likely be the same for any two projects.

After I have the directions of the servos and have the normalizing multipliers set, I can give all servos the same angular commands, according to my world model, and they will do the right things. :veryhappy: I can orient for any X,Y,Z world model. :veryhappy: I prefer +Z = Up, +X = Right, +Y = Forward. I've been using this scheme for quite awhile in my robot software, and it works wonderfully. :happy::happy:

Sorry, but I don't think your argument holds up.

8-Dale

Matt

04-23-2008, 09:33 PM

Okay, I'm sold. Right handed it is. We have our position and orientation coordinate system decided upon. I'll have Jen make up some new graphics in the next day or two and post them.

Dale, you're right, servos are often flipped and that needs to be accounted for, but I think Meta wasn't making that point particular point with his example. I understood what he was getting at.

In the case of hobby servos our model stores the 0, 90, and 180 degree positions. In the case of phidgets controllers their values go from 0 to 1000 which translate into a range of PWM signals for a servo controller. So you might find something like the following:
0 = 224
90 = 505
180 = 732

Direction is never a problem at the SCL level because an algorithm library returns what the new angle will be and you pass that to the TROM. The SCL then sees the new angle and does a simple calculation to figure out what to send to the controller.

Let's say the new joint angle is 110 degrees.

(732 - 505) = 227
227 / 90 = 2.522
2.522 * (110 - 90) = 50.444
50.444 + 505 = 555.444
send 555.444 to the phidgets controller and the servo moves to 110 degrees.

It's very simple math, but my point is that the SCL doesn't care about or think about "direction" when executing movements. The direction is inherantly stored inside the TROM variables by nature. Directions that joints need to move in and all that kind of stuff is the realm of algorithm libraries and planning tools. (Where yes, you may need to be flipping degrees around to format the equations properly) Those tools will have read through the TROM ahead of time when the requests were made and done their calculations based off what the 0/90/180 positions would be as determined by the coordinate system we just decided on. In essence, the algorithm library and any other planning tool are completely blind to what was used to build the robot. And that's the tear inspiring beauty of the architecture :)

Anyhow, this is fairly off topic, if people want to dig into this let's start a new thread. For the moment, drinks all around, we have our first community established standard :) Now, get you butts over to the protocol thread and let's nail that one!