PDA

View Full Version : motion_4096, motion_dest, motion_src, what are these files for?



guoshihui
10-28-2015, 04:52 AM
I got one question about the files under the *Data/* folder.

We can open config.ini with text editor, and it sets the values related to the motion, which is also mentioned in the wiki of the rme. But the other three files, motion_4096, motion_dest, motion_src, they are binary files so far I can see. What these three files for in this case? And why we need to make them binary, instead of text?

Thx.

Shihui

guoshihui
10-28-2015, 04:54 AM
Ahh, stupid me, they are the pages for the motion data, right?

But why make it binary, not text? And how each of the file is responsible for?

tician
10-28-2015, 08:05 AM
It is binary because the darwin-op framework used binary for its motion player. The format is described in 'Framework/include/Action.h'. Would much prefer a yaml or xml motion file format with a uuid or hash for the identifier to permit easy mixing of motions from different repositories without naming conflicts. I had started some work on a replacement interpolating motion player using xml stored motions, but got distracted and never settled on an xml library to use.

sonel
10-29-2015, 03:16 AM
I had started some work on a replacement interpolating motion player using xml stored motions, but got distracted and never settled on an xml library to use.

Interesting, I got about 10 pages of formulae on one notebook trying to come up with an efficient interpolating algorithm using cubic splines to smooth the transition between pages. Haven't gone that far though, but I'm sure I'll get back to it soon.

Alex.

tician
10-29-2015, 02:34 PM
Interesting, I got about 10 pages of formulae on one notebook trying to come up with an efficient interpolating algorithm using cubic splines to smooth the transition between pages. Haven't gone that far though, but I'm sure I'll get back to it soon.

Alex.

I was simply going to do linear interpolation for the initial version since it tends to work well enough, but is easy enough to change the process used to generate the next interpolated position. Since sharing poses and sequences is such a pain with the binary formats from rme and RoboPlus, I was going to use the SHA256 hash of each as the identifier for the poses and sequences to prevent anything being overwritten or duplicated. The SHA256 is of only the object arrays in the pose and the transition types.

In these snippets from the header, I was still using the object_t from my now abandoned ZMQ system to pass servo and sensor data between multiple servo/sensor controllers and gait generators or motion players. The 'status' would always be a fixed value here since servo feedback is unnecessary for storing poses and would create an explosion of nearly identical poses with different SHA256 identifiers.


class egzemellePose
{
public:
struct header_t
{
char poseSHA[65]; // SHA256 of pose
char parentSHA[65]; // SHA256 of parent, if any
uint64_t timestamp; // timestamp of poseSHA last modify
uint16_t nObjects; // Number of devices in pose
string poseDesc; // Description of pose
};
/*
Reading:
Extract poseSHA from XML, then recompute SHA256() of pose objects.
If different, poseSHA -> parentSHA; temp -> poseSHA; update timestamp
If same, use poseSHA and parentSHA extracted from XML
Writing:
Recompute SHA256() of pose objects and compare to poseSHA
If different, poseSHA -> parentSHA; temp -> poseSHA; update timestamp
If same, no changes to pose; write as-is
*/

struct object_t // 16-byte
{
object_t(void) :
identity (0),
mode (ObjectMode::UNDEFINED),
status (ObjectStatus::INVALID_DATA),
position (0),
velocity (0),
effort (0) {};

uint16_t identity; // Device/Servo ID number
uint8_t mode; // Device/Servo operating mode
uint8_t status; // Device/Servo status

float position; // Actuator position (m or radian)
float velocity; // Actuator velocity (m/s or radian/s)
float effort; // Actuator effort (N-m or N)
};

struct
{
header_t header;
object_t *objects;
} pose;
};

class egzemelleSequence
{
public:
struct header_t
{
char seqSHA[65]; // SHA256 of sequence
char parentSHA[65]; // SHA256 of parent, if any
uint64_t timestamp; // timestamp of seqSHA last modify
uint16_t nObjects; // Number of poses in sequence
string seqDesc; // Description of sequence
};
/*
Reading:
Extract seqSHA from XML, then recompute SHA256() of seq objects.
If different, seqSHA -> parentSHA; temp -> seqSHA; update timestamp
If same, use seqSHA and parentSHA extracted from XML
Writing:
Recompute SHA256() of seq objects and compare to seqSHA
If different, seqSHA -> parentSHA; temp -> seqSHA; update timestamp
If same, no changes to sequence; write as-is
*/
struct object_t
{
object_t(void) :
transitionTime (0),
currPoseIndex (0),
nextPoseIndex (0),
stopPoseIndex (0),
currPoseSHA ({0}),
nextPoseSHA ({0}),
stopPoseSHA ({0}) {};
uint64_t transitionTime;
uint64_t currPoseIndex;
uint64_t nextPoseIndex;
uint64_t stopPoseIndex;
char currPoseSHA[65];
char nextPoseSHA[65];
char stopPoseSHA[65];
};
};

guoshihui
10-30-2015, 04:03 AM
Since sharing poses and sequences is such a pain with the binary formats from rme and RoboPlus, I was going to use the SHA256 hash of each as the identifier for the poses and sequences to prevent anything being overwritten or duplicated. The SHA256 is of only the object arrays in the pose and the transition types.

mmm....it looks that I am not the only one who complains about the binary thing