Pin remap explanation

[correderadiego]

Hello, I have been reading your code and I saw that you remap de pins of the servos depending the walking mode. Could you explain in detail the idea behind the remaping process?

You could see this remaping in the OpenCat.h file

Thanks for your time ^_^

[borntoleave]

Use h for head, t for tail, r for shoulder roll joint, s for shoulder pitch joint, k for knee joint, F for front, H for hind, L for left, R for right, the order of joints is:

Index	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Joint	hPan	hTilt	tPan	N/A	rFL	rFR	rHR	rHL	sFL	sFR	sHR	sHL	kFL	kFR	kHR	kHL

I'm storing joint information of a single gait as:

Frame#	4	5	6	7	8	9	10	11	12	13	14	15
Frame1	rFL	rFR	rHR	rHL	sFL	sFR	sHR	sHL	kFL	kFR	kHR	kHL
Frame2	rFL	rFR	rHR	rHL	sFL	sFR	sHR	sHL	kFL	kFR	kHR	kHL
Frame3	rFL	rFR	rHR	rHL	sFL	sFR	sHR	sHL	kFL	kFR	kHR	kHL

...

Note: on Nybble there're no shoulder roll joints.

Use "<" as head direction, "-" as the legs' travel distance on left or right, think about four gaits:

Slow             Fast             Left             Right
  -               ---               ---               -
<               <                <                <
  -               ---                -               ---

In the current code in the Repo, I'm storing them as four different gaits. For example, "tr" is fast trotting, "trL" is fast trotting left. "wk" is fast walking, "wkR" is fast walking right.

But take a look at "Left" or "Right", it actually holds all the information needed for the four gaits. By remapping the columns, I can reproduce four gaits from one data set.

It's a more efficient way for storing gaits, saving 3/4 of the memory. Calculation cost is minor. I have it tested in my local branch, but needs more integration with the general workflow.

[correderadiego]

Thanks for your answer. I would like to clarify one aspect that I haven't understood. This is related to the dimension of the mapping. You are using 8 degree of freedom robot but in this explanation and in the remapping code your are using 15 dimensions.

Have you created a general code and you are limiting the size to process in any other part of the code?

I have other question related to the fast moving generation process. Couldn't you generate it decreasing the delay time between frames or even taking only the even frames? For example :

Slow movement : Frame 1 : 500 millis delay Frame 2 : 500 millis delay [....]

Fast movement :+1: Frame 1 : 200 millis delay Frame 2: 200 millis delay [...]

See you.

[borntoleave]

@correderadiego I'm trying to keep my codes compatible for all my current models, that's Nybble and three other animals with various configurations. Change of the actual compiled code is done through multiple #define and #ifdef. That's the reason that I'm keeping the 16 DoF parameters even if they are not all used on a 8 DoF model.

In principle you can add delay between frames (I experimented too). However that will slow down the loop and cause MPU6050 buffer to overflow. That will cause lag in adaptive balancing and the pace of gait. So instead of using delay, check my solution by using "#define SKIP". It will keep the loop going but reduce the refresh rate of frames.