You can subscribe to this list here.
2002 
_{Jan}
(5) 
_{Feb}
(28) 
_{Mar}
(9) 
_{Apr}
(15) 
_{May}
(17) 
_{Jun}
(58) 
_{Jul}
(12) 
_{Aug}
(25) 
_{Sep}
(10) 
_{Oct}
(4) 
_{Nov}
(52) 
_{Dec}
(25) 

2003 
_{Jan}
(13) 
_{Feb}
(19) 
_{Mar}
(8) 
_{Apr}
(21) 
_{May}
(34) 
_{Jun}
(10) 
_{Jul}
(26) 
_{Aug}
(52) 
_{Sep}
(14) 
_{Oct}
(36) 
_{Nov}
(39) 
_{Dec}
(4) 
2004 
_{Jan}
(2) 
_{Feb}
(6) 
_{Mar}
(28) 
_{Apr}
(29) 
_{May}
(53) 
_{Jun}
(54) 
_{Jul}
(54) 
_{Aug}
(49) 
_{Sep}
(42) 
_{Oct}
(32) 
_{Nov}
(58) 
_{Dec}
(7) 
2005 
_{Jan}
(24) 
_{Feb}
(21) 
_{Mar}
(40) 
_{Apr}
(102) 
_{May}
(73) 
_{Jun}
(38) 
_{Jul}
(70) 
_{Aug}
(11) 
_{Sep}
(18) 
_{Oct}
(38) 
_{Nov}
(33) 
_{Dec}
(3) 
2006 
_{Jan}
(21) 
_{Feb}
(74) 
_{Mar}
(79) 
_{Apr}
(86) 
_{May}
(75) 
_{Jun}
(45) 
_{Jul}
(74) 
_{Aug}
(57) 
_{Sep}
(60) 
_{Oct}
(12) 
_{Nov}
(20) 
_{Dec}
(18) 
2007 
_{Jan}
(16) 
_{Feb}
(53) 
_{Mar}
(31) 
_{Apr}
(35) 
_{May}
(121) 
_{Jun}
(72) 
_{Jul}
(22) 
_{Aug}
(46) 
_{Sep}
(45) 
_{Oct}
(71) 
_{Nov}
(93) 
_{Dec}
(66) 
2008 
_{Jan}
(32) 
_{Feb}
(87) 
_{Mar}
(116) 
_{Apr}
(58) 
_{May}
(49) 
_{Jun}
(106) 
_{Jul}
(95) 
_{Aug}
(74) 
_{Sep}
(101) 
_{Oct}
(84) 
_{Nov}
(59) 
_{Dec}
(55) 
2009 
_{Jan}
(73) 
_{Feb}
(53) 
_{Mar}
(94) 
_{Apr}
(82) 
_{May}
(106) 
_{Jun}
(147) 
_{Jul}
(160) 
_{Aug}
(77) 
_{Sep}
(28) 
_{Oct}
(57) 
_{Nov}
(15) 
_{Dec}
(37) 
2010 
_{Jan}
(39) 
_{Feb}
(38) 
_{Mar}
(33) 
_{Apr}
(25) 
_{May}
(29) 
_{Jun}
(92) 
_{Jul}
(55) 
_{Aug}
(42) 
_{Sep}
(19) 
_{Oct}
(17) 
_{Nov}
(15) 
_{Dec}
(10) 
2011 
_{Jan}
(14) 
_{Feb}
(12) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(7) 
_{Jun}
(6) 
_{Jul}
(6) 
_{Aug}
(11) 
_{Sep}
(11) 
_{Oct}
(4) 
_{Nov}
(4) 
_{Dec}
(3) 
2012 
_{Jan}
(5) 
_{Feb}
(4) 
_{Mar}
(2) 
_{Apr}
(2) 
_{May}

_{Jun}
(1) 
_{Jul}
(8) 
_{Aug}
(1) 
_{Sep}
(1) 
_{Oct}

_{Nov}
(2) 
_{Dec}
(9) 
2013 
_{Jan}
(4) 
_{Feb}

_{Mar}
(1) 
_{Apr}
(21) 
_{May}
(43) 
_{Jun}
(16) 
_{Jul}

_{Aug}
(4) 
_{Sep}
(1) 
_{Oct}
(1) 
_{Nov}

_{Dec}

2014 
_{Jan}

_{Feb}
(6) 
_{Mar}
(3) 
_{Apr}

_{May}
(2) 
_{Jun}
(2) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(9) 
_{May}

_{Jun}
(21) 
_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2016 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}
(1) 
_{Jun}
(4) 
_{Jul}
(1) 
_{Aug}

_{Sep}
(1) 
_{Oct}
(2) 
_{Nov}
(8) 
_{Dec}
(7) 
2017 
_{Jan}
(4) 
_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2
(2) 
3
(2) 
4
(2) 
5
(3) 
6

7

8

9
(3) 
10
(3) 
11

12
(1) 
13
(3) 
14
(1) 
15

16
(7) 
17

18

19
(2) 
20

21

22

23

24
(1) 
25

26
(6) 
27

28

29
(4) 
30
(6) 
31
(3) 




From: Peter Soetens <peter.soetens@me...>  20040829 22:06:45

On Sunday 29 August 2004 12:35, Herman Bruyninckx wrote: > Here is the BROSI draft. > > Herman This is a very clear starting point. I would suggest to put the text in a more structured http://www.doxygen.org format like this : /** Coordinates of the directed line segment from one Point to another Point. No distinction is made between "free vectors" (not bound to any particular line), "line vectors" (bound to a particular line), or "point vectors" (bound to a particular point). */ struct Vector { float x; float y; float z; }; etc. When composite types arise, (e.g. AccelerationTwist ) browsing becomes easier, and an online version is always consultable. With 'autobrief' turned on, the first sentence (until first dot) is the short discription of the type. Also, a 'struct' is the most accepted name for a composition of types. Even if your language happens to call it 'class', from a specification point of view, it is unambiguous. Which brings me to 'float'. What's the precision of this number ? 32 or 64 or ... ? I would go for 'double' precision, thus 64 bits, as is most common in recent software. Is there a typo in the definition of a Point ? The z component seems to be missing. I'm not subscribed to most of the lists, so Herman, could you please duplicate on the 'closed' ones ? I'll subscribe to the playerstagedesign list if that's where the discussion will continue. with kind regards, Peter   Peter Soetens, Research Assistant http://www.orocos.org Katholieke Universiteit Leuven Division Production Engineering, tel. +32 16 322773 Machine Design and Automation fax. +32 16 322987 Celestijnenlaan 300B peter.soetens@... B3001 Leuven Belgium http://www.mech.kuleuven.ac.be/pma  
From: Herman Bruyninckx <Herman.Bruyninckx@me...>  20040829 10:37:34

Here is the BROSII draft. Herman  K.U.Leuven, Mechanical Engineering, Robotics Research Group <http://people.mech.kuleuven.ac.be/~bruyninc>; Tel: +32 16 322480 =================================================================== BROSII  Basic Robotics Standards, Level 2 Interconnected robotics objects, with metainformation. Herman Bruyninckx, 28 AUG 2004 This document is released in the public domain. The presented standards can be used without any restriction, except that the names "BROS" and "Basic Robotics Standards" can only be used to refer to the material in this and related documents, and in later versions thereof. Introduction  Many objects in robotics consists of a collection of primitives from BROSI, with metainformation that identifies the object, and that explains how to interpret the numerical data. For example, their coordinates are expressed with respect to a particular frame, and they are the coordinates of a particular object; or they have multiple possible mathematical representations, and the meta information says which one is used. This level of the standard also uses metainformation to encode the identity of objects, by means of a "string". Metainformation must be interpreted before the numerical information in the object can be used; the interpretation of the numerical information can depend on the content of the metainformation. Metainformation fits well in "filebased" data exchange (e.g., XML), but it also allows "realtime" exchange provided that the metainformation is first exchanged and interpreted in "nonrealtime" mode, and then the numerical data is exchanged and interpreted, possibly in "streaming mode" (i.e., without interpretation and in continuous mode without a setup cost for each exchange) in order to improve latency and/or bandwidth. Most objects in this level of the standard are "composite": they consist of the interconnection of multiple lower or samelevel objects. The interconnection is encoded via the ObjectPortConnector pattern: each object has a number of Ports, and Ports of the same type can be connected; all the information about the connection is stored in a Connector object, and not in one of the connected objects. (Which would lead to duplicated or nonsymmetric storage of the information about the interconnection.) To Be Discussed: The number and content of the objects to be included in this level of the standard. In other words, everyhting :) Definitions  RigidBody: attributes: id: string properties: list of Ports:  Pose of the Port: defines where on the body the connection can be made  type of the Port: Mass: to attach inertia information. Shape: to attach geometrical form information. Feature: to indicate a geometric feature on the RigidBody. RigidBody: to connect to another RigidBody with a rigid connection. Sensor: to connect a sensor. MechanicalConstraint: to attach a motion constraint, such as a joint. Device: to connect to the Device the RigidBody belongs to. state: X: Pose of the body dX: Twist of the body ddX: AccelerationTwist of the body F: wrench on the body MechanicalConstraint: Connector connecting two compatible Ports attributes: id: string dim: 1, 2, 3, 4, 5 type: revolute, prismatic, helical, stiffness, damping, inertia, compliance, inversedamping, mobility, ground, ... constitutive relationship: F(states of connected RigidBodies)=0. e.g., stiffness matrix or function, damping matrix or function. properties: state: q: "position" in the constraint (has "dim" parameters) dq: velocity of constraint parameters ddq: acceleration of constraint parameters f: force in the constraint list of the Ports (of type RigidBody) the constraint is connected to. FeatureConstraint: Connector connecting two Features; the interconnection is not physical, but represents a desired relative "motion" of Features on two or more RigidBodies. attributes: id: string dim: 1, 2, 3, 4, 5 type: distance, orientation, relative desired motion, ... list of ports (of type Feature) constitutive relationship: F(features on connected objects)=0. properties: state: q: "position" in the constraint (has "dim" parameters) dq: velocity of constraint parameters ddq: acceleration of constraint parameters f: "force" in the constraint list of the Ports (of type RigidBody) the constraint is connected to. JointPositions: attributes: id: string dim: number of joints type of each joint: revolute, prismatic, helical, gimbal, spherical, ... properties: q: vector of floats, representing the positions of all joints The order as well as the number of values in the vector depends on the kinematic chain definitions. Problem: how to represent multidimensional joints such as gimbals or spherical joints? Similar definitions for JointVelocities, JointAccelerations, JointForces. Device: connection of bodies and joints. attributes: id: string type: string. Indicates the family to which this device belongs; e.g., 6RSerial, DifferentiallyDriven, etc. properties: list of RigidBodies and Connectors. The order in the list is relevant, and has to be standardized in some way... root: pointer to the RigidBody or Connector which is to be considered as root of the Device's kinematic chain. Can be "NIL". list of tools: list of Features on the Device's RigidBodies that belong to the exported interface of the Device; i.e., tasks for the Device can make use of these Features. World: attributes: id: string properties: list of Devices. The order is not relevant. 
From: Herman Bruyninckx <Herman.Bruyninckx@me...>  20040829 10:36:15

Here is the BROSI draft. Herman  K.U.Leuven, Mechanical Engineering, Robotics Research Group <http://people.mech.kuleuven.ac.be/~bruyninc>; Tel: +32 16 322480 ================================================================= BROSI  Basic Robotics Standards, Level 1 Primitive data structures (numerical representations) for motion (position, velocity, acceleration), force, and derived quantities. Herman Bruyninckx, 29 AUG 2004 This document is released in the public domain. The presented standards can be used without any restriction, except that the names "BROS" and "Basic Robotics Standards" can only be used to refer to the material in this and related documents, and in later versions thereof. Introduction  This document is part of a multilevel standardisation effort launched by several Free Software and Open Source robotics projects. This first level of the standard is limited to the definition of numerical representations of common primitive concepts in robotics. "Primitive" means: consisting of only the basic numerical types "float" and "int". These representations are completely free of any special interpretation in whatever robotics application domain. All defined objects live in the threedimensional Euclidean space. To Be Discussed: If twodimensional ("planar") objects are needed, the suffix "2D" could be added to the data structure names; for example, "RotMatrix2D". All physical units are in SI (Systeme International d'Unites, International System of Units, <http://physics.nist.gov/cuu/Units/>;). More in particular: distances in meter, angles in radians, forces in Newton, time in seconds. When encoded in a programming language, the "argument namess" given in each object can become the fields in a data structure in the language. For example, if T is a HomTrans matrix, then T.Rxx is the topleft element of T. Mathematical representations  Point: x: float y: float Coordinates of a point in the 3D Euclidean space. Vector: x: float y: float z: float Coordinates of the directed line segment from one Point to another Point. No distinction is made between "free vectors" (not bound to any particular line), "line vectors" (bound to a particular line), or "point vectors" (bound to a particular point). UnitVector: x: float with range [1,1] y: float with range [1,1] z: float with range [1,1] vector whose coordinates must satisfy the constraint X^2 + y^2 + z^2 = 1. RotationAngle: float, with unlimited range. OrientationAngle: float, with range [pi,+pi] HeadingAngle: float, with range [pi/2,+pi/2] To Be Discussed: there are no basic numerical types that impose the ranges of the two abovementioned objects. Is this a reason not to include them in this level of the standards? RotMatrix: Rxx: float Rxy: float Rxz: float Ryx: float Ryy: float Ryz: float Rzx: float Rzx: float Rzz: float nine floats representing the 3 x 3 matrix with the direction cosines of the unit vectors of one orthogonal, righthanded reference frame with respect to another orthogonal, righthanded reference frame:  Rxx Ryx Rzx  RotMatrix =  Rxy Ryy Rzy   Rxz Ryz Rzz  All rows and colums are orthogonal UnitVectors. RotX: a: float RotMatrix representing a rotation about the X axis over an angle a:  1 0 0  RotX(a) =  0 ca sa   0 sa ca  RotY: a: float RotMatrix representing a rotation about the Y axis over an angle a:  ca 0 sa  RotY(a) =  0 1 0   sa 0 ca  RotX: a: float RotMatrix representing a rotation about the Z axis over an angle a:  ca sa 0  RotZ(a) =  sa ca 0   0 0 1  EulerMovingXYZ: a: float b: float c: float Sequence of three rotations about moving frame axes. (Alternative name: "EulerXYZ", because most literature defines Euler angles around moving axis.) The magnitudes of angles are limited, but the three angles do not have the same limits. The angle "a" belongs to the rotation around the first named axis, "b" to the second named axis, and "c" to the last named axis; for example, in EulerMovingXYZ(a,b,c), the rotation around "X" is over the angle "a", the rotation about "Y" is over the angle "b", and the rotation about "Z" is over the angle "c". There are twelve possible combinations of Euler angles: EulerMovingXYZ(a,b,c) = RotZ(c) RotY(b) RotX(a), and similarly for EulerMovingXZY, EulerMovingXYX, EulerMovingXZX, EulerMovingYXZ, EulerMovingYZX, EulerMovingYXY, EulerMovingYZY, EulerMovingZXY, EulerMovingZYX, EulerMovingZXZ, EulerMovingZYZ EulerFixedXYZ: r: float p: float y: float Sequence of three rotations about fixed frame axes: (Alternative name: RPY_XYZ ("rollpitchyaw").) EulerFixedXYZ(a,b,c) = RotX(a) RotY(b) RotZ(c), and similarly for EulerFixedXZY, EulerFixedXYX, EulerFixedXZX, EulerFixedYXZ, EulerFixedYZX, EulerFixedYXY, EulerFixedYZY, EulerFixedZXY, EulerFixedZYX, EulerFixedZXZ, EulerFixedZYZ. Quaternion: V: Vector s: float Ordered couple of a Vector (representing the axis around which to rotate), and a scalar (representing the magnitude of a rotation). s is not the angle of rotation itself, but the cosine of the half of that angle; the Vector is not the direction (unit vector) of the rotation axis itself, but this direction unit vector multiplied by the sine of the half of that angle. The major reason for the existence of Quaternions is that they do not have algebraic singularities, which all Euler angles do have. The coordinates of a Quaternion satisfy the following constraints: Vx^2 + Vy^2 + Vz^2 + s^2 = 1. HomTrans: Rxx: float Rxy: float Rxz: float Ryx: float Ryy: float Ryz: float Rzx: float Rzx: float Rzz: float Px: float Py: float Pz: float Twelve floats representing an homogeneous transformation matrix, i.e., 4 x 4 matrix of floats containing a RotMatrix and a Point in the following form:  Rxx Ryx Rzx Px   Rxy Ryy Rzy Py  HomTrans =  Rxz Ryz Rzz Pz   0 0 0 1  Velocity: Vector representing the velocity of a Point Vx: float Vy: float Vz: float Acceleration: Vector representing the acceleration of a Point Vx: float Vy: float Vz: float AngularVelocity: Vector representing the angular velocity of a rigid body Ax: float Ay: float Az: float AngularAcceleration: Vector representing the angular acceleration of a rigid body Ox: float Oy: float Oz: float Force: Vector representing a linear force Fx: float Fy: float Fz: float Moment: Vector representing a force moment Mx: float My: float Mz: float Twist: ordered couple (V,W) of two Vectors: V: Velocity W: AngularVelocity V is the velocity vector of the "velocity reference point", which is the origin of the frame in which the coordinates are expressed. W is an angular velocity vector. (Note: using a velocity reference point that is not the origin requires extra information to be given, i.c. the Position of that velocity reference point.) Wrench: ordered couple (F,M) of two Vectors: F: Vector (F: Fx Fy Fz) M: Vector (M: Mx My Mz) F is a linear force vector. M is the moment vector at the "moment reference point", which is the origin of the frame in which the coordinates are expressed. AccelerationTwist: ordered couple (A,O) of two Vectors: A: Acceleration O: AngularAcceleration V is the velocity vector of the "velocity reference point", which is the origin of the frame in which the coordinates are expressed. W is an angular velocity vector. To Be Discussed: the following two objects (TwistTrans and WrenchTrans) are easily constructed from a HomTrans, and less frequently used in data exchanges. So, they could be removed from the standard. TwistTrans: Rxx: float Rxy: float Rxz: float Ryx: float Ryy: float Ryz: float Rzx: float Rzx: float Rzz: float RPxx: float RPxy: float RPxz: float RPyx: float RPyy: float RPyz: float RPzx: float RPzy: float RPzz: float 18 floats, representing the 6 x 6 matrix of floats that transforms a Twist from one frame to another frame. It is constructed with minimal operations from the HomTrans (R,p) between both frames:  R R p^  TwistTrans =    0 R  with  0 pz py  p^ =  pz 0 px   py px 0  WrenchTrans: similar to TwistTrans, but now the 6 x 6 matrix of floats that transforms a Wrench from one frame to another frame. It is constructed with minimal operations from the HomTrans between both frames.  R 0  WrenchTrans =    R p^ R  To Be Discussed: The following paragraphs just list a set of objects to be standardized, together with a list of commonly used representations. We should discuss what alternative representations to standardize, what names are given to the objects, and, possibly, whether separate names should be given to the same objects with different representations. My suggestion is to use different names, because this is the only way to avoid online interpretation of the data. Line:  (Point, Direction)  (Point, Point)  (Plane, Plane) (intersection)  (Screw) (ordered couple of free vector and line vector, with two constraints between both) Suggestion: LinePD, LinePoPo, LinePlPl, LineS. LineSegment:  (Point, Direction, Length)  (Point, Point) Suggestion: LineSegmentPDL, LineSegmentPoPo Orientation:  RotAxis(line,angle): rotation around the (directed!) "line" through the origin of the current frame, over a given "angle"  RotMatrix  set of the 24 Euler angle sets  Quaternion Suggestion: OrientationA, OrientationM, OrientationE, OrientationQ. Frame:  HomTrans  (Point, Orientation)  (Point, RotMatrix)  (Point, Quaternion)  (Point, one of the 24 Euler angle sets) Suggestion: FrameT, FramePO, FramePM, FramePQ, FramePE. Pose, Displacement, Offset: synonyms for Frame, so with same represenation and similar naming. 
From: Herman Bruyninckx <Herman.Bruyninckx@me...>  20040829 10:34:19

Some weeks ago, I posted to this mailinglist to suggest the beginning of a common data representation standardisation. This post is a followup, summarizing what has happened since then, and listing some concrete work in progress. First of all, I decided to go forward with the effort, because I received a lot of positive feedback. So, the first drafts resulting from this effort are posted in followup mails. The Player project has kindly offered to host the detailed discussion on their mailinglist: <http://sourceforge.net/mailarchive/forum.php?forum=playerstagedesign>; reachable via <playerstagedesign@...>. Please, use only that mailinglist for feedback and suggestions, such that we have a single archive of all arguments and suggestions. The standards will be public domain, or another open form; what exactly has not been agreed on. My current drafts contain the following statement: " This document is released in the public domain. The presented standards can be used without any restriction, except that the names "BROS" and "Basic Robotics Standards" can only be used to refer to the material in this and related documents, and in later versions thereof. " Maybe the first sentence is already enough. Because I guess we would need some sort of trademark protection in order for the second sentence to be valid...? There is more or less (with much more "more" than "less") unanimity about the need for multiple levels in the standardisation: the strategy is to start with smallscale standards that all projects agree on and about material that all projects are using, while higher levels of the standards are less universal. In analogy to the similar (and successful) approach in linear algebra (the BLAS  Basic Linear Algebra Subprograms <http://www.netlib.org/blas/>;), I coined the term BROS  Basis Robotics Standards. The levels I will report on in two followup mails are: BROSI: Primitive data structures (numerical representations) for motion (position, velocity, acceleration), force, and derived quantities. BROSII: Interconnected robotics objects, with metainformation. (Higher BROS levels will standardize network transparant middleware, and method calls. The levels I and II are only about exchange of data.) My suggestion is to focus on BROSI, and the BROSI draft proposal is worked out in detail, at this moment. I also made a BROSII draft, with less level of detail, but in order to make clear what kind of things are not part of BROSI. Both drafts are to be considered as _proposals_ only, so be critical, but always in a _constructive_ way: if you do not like something, don't just rant about it but explain how to do it better. I hope we can go forward with this effort in the same constructive way that we have experienced the last two weeks. Finally, I invite a representative of each of the projects involved to coauthor a paper about this initiative for ICRA'05. I will go forward with this paper as soon as there are at least three projects that want to do this. Best regards, Herman Bruyninckx  K.U.Leuven, Mechanical Engineering, Robotics Research Group <http://people.mech.kuleuven.ac.be/~bruyninc>; Tel: +32 16 322480 