Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Static walk using Blender #2

Closed
rsantos88 opened this issue Oct 11, 2021 · 2 comments
Closed

Static walk using Blender #2

rsantos88 opened this issue Oct 11, 2021 · 2 comments
Assignees

Comments

@rsantos88
Copy link
Contributor

With the new update of this repo (c901af6), Teo models for Blender and the incorporation of the rigging in the legs, I've proposed to do some experiments with the possibility of performing a static walk cycle for Teo totally offline generated manually in Blender. This objective is probably not easy to carry out (although it was done in the past as @smcdiaz told me). There is no control loop over the torque sensors and no real-time kinematics calculation is performed according to different circumstances. However, these experiments can shed some light, trying to find out the possibilities of a gait with the mechanical limitations that we find in Teo's legs. It may also be helpful for the issue: 'Gait demo using iCub's walking controllers' (roboticslab-uc3m/teo-main#51).

After the tests carried out previously with a pedaling cycle in the air, generated in Blender and then executed in the robot (video), the next step has been to generate a squat, try to move the legs laterally to the right as much as joint limits allow it, keeping the feet parallel to the line off the ground and lift his right leg like a lame leg.

The first thing was to check in the Blender environment what would be the maximum height that the foot can reach above the air, assuming that Teo starts from the initial position leaning on the ground and we want the sole of the foot to remain parallel to the line of the ground (squat in the air).

The joint values obtained in Blender for this squad position are:
RightLeg [-1.3223 1.4719 -20.4931 43.4408 -22.9395 -0.3390]
LeftLeg   [0.7863 -1.0250 -20.5802 43.5117 -22.9142 1.9170]

In this case, the position of the front ankle (-22.9) is very close to its limit (-23,09).
According to the data obtained in Blender, this distance between the ground and the sole of the foot would be 4.71909 cm. 

distance

Therefore, in this example, the squat will do approximately half of the distance (2.39144 cm, point 1) to be able to later elevate the right foot on the surface of the ground (lame leg). But first, I move the legs sagittally to the right until we get close to their joint limit (ID 5 and ID 8), in order to shift the center of gravity towards the left foot as much as possible.

The joint values obtained in Blender for this squad positionwith side shift are:
RightLeg [7.0110 -8.4814 -10.9063 24.9255 -13.918 8.5155]
LeftLeg [9.2600 -10.9650 -8.6920 21.5232 -12.7059 10.9098]

Next, I elevate Teo's right leg to keep it in the air to its maximum height.
As a consequence of making a lateral movement of the legs in a sagittal direction, it results in:

  • it doesn't keep the right sole parallel to the ground, which produces a deviation where the tip of the foot is closer to the ground than the heel. 
  • slightly upward shift of the left foot.

In this case the tip of the right foot (point 3) is at 5.32574 cm on the Z axis and the left foot (point 2) at 2.98463 cm on the Z axis, so the theoretical maximum height of the foot in flight that it will reach in this example is 2.34111cm. You can see the trajectory here:

trajectory

Once it has been verified that the limits are not exceeded in any case, it's tested on the robot. I verified with @smcdiaz that even in this case, shifting its center of gravity as much as possible, the robot tends to fall backwards and to the right. @smcdiaz explained to me that it is not exactly necessary that the center of gravity falls exactly in the center of the left foot, it is enough that it falls inside it to achieve balance. Therefore, it has been necessary to make use of the trunk, tilting it forward 9 degrees and the sagittal left shoulder 11 degrees to balance it and finally move its center of gravity.

Much of the problem is the slack in the legs, producing a considerable deflection of this when supporting all the weight on it and having to be compensated with the left arm.

In this video, Teo is performing a lame leg in the air and then resting it on the ground:

20211008_144751_1_1080x1920.mp4

and here is performing a lame leg already resting on the ground:

20211008_145540_1_1080x1920.mp4

In both, Teo keeps his balance but with the problems already mentioned.
@smcdiaz told me about the possibility of including a plastic piece that allows the axial joint to slide (ID7 and ID6) but at the same time allows to block this slack produced in the ID5 and ID8 joints , using it as support.

@PeterBowman
Copy link
Member

In case it renders helpful (e.g. to compare joint limits), we host squat/balance apps in https://github.com/roboticslab-uc3m/gait-experiments. Context: roboticslab-uc3m/teo-main#33 (comment).

The slack problem is tracked at https://github.com/roboticslab-uc3m/teo-hardware-issues/issues/63.

@rsantos88
Copy link
Contributor Author

After analyzing several tests with the trajectory obtained from the "lame leg" in Blender, we've observed the different improvements that have been carried out in Teo's hardware to reduce the slack of the leg (https://github.com/roboticslab-uc3m/teo-hardware-issues/issues/63#issuecomment-1021486265). I leave attached here the resulting trajectory in case it is of interest in future tests, as well as the Blender project where the positions have been saved. I close this issue for the moment, unless we want to reopen to generate new test trajectories or develop a possible static walk with this procedure.

Blender project: teo-lame-leg.zip
Trajectory : lame-leg.csv

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants