questions on ground touchdown

[hooram]

Hi guys, I'm really enjoying the fruits of your hard work. I've successfully run the openshc stack on my custom hexapod (video here: https://www.youtube.com/watch?v=gDRpkwpoU_c). It has 18 Dynamixel RX28 servos, and runs on a Jetson Nano.

I've been trying to wrap my head around the admittance controller feature of the openshc stack. Here is my understanding of what it does: it can either calculate the force at the tip from the servos' load feedback, or measure them directly through additional sensors. While walking, when a leg touches (i.e. tip force > threshold) the ground earlier or later than expected (as it would on a flat surface), it will hold the z position of that leg, so that 1) not one leg bears too much load and 2) to try to keep the body relatively level.

At first I tried playing around with the parameters for the admittance controller with use_joint_effort set to true, but it didn't seem to have any effect on the walking behaviour. I had a brief look at the code for how it's calculated, and it seems it's only initialized to zero vectors here

syropod_highlevel_controller/src/model.cpp

Line 182 in 26c0c71

tip_force_calculated_ = Eigen::Vector3d::Zero();

and it doesn't actually seem to be computed from the servo load values. Please point me in the right direction if I missed it.

The next thing I tried was to implement a simple "force" sensor using tactile push button switches attached to the feet. I attached them to an arduino that communicates with the host system through serial, and wrote a little ROS node that publishes the tip sensor data to the topic /tip_states. I tried publishing them at 100Hz and 1000Hz. Since it's just a push button switch, the published message looks like this with only the z component of the force being nonzero:

header:       
  seq: 542
  stamp: 
    secs: 1598803970
    nsecs: 978107929
  frame_id: ''
name: 
  - AR_
  - BR_
  - CR_
  - CL_
  - BL_
  - AL_
wrench: 
  - 
    force: 
      x: 0.0
      y: 0.0
      z: 0.0
    torque: 
      x: 0.0
      y: 0.0
      z: 0.0
  - 
    force: 
      x: 0.0
      y: 0.0
      z: 1.0
    torque: 
      x: 0.0
      y: 0.0
      z: 0.0
  - 
    force: 
      x: 0.0
      y: 0.0
      z: 0.0
    torque: 
      x: 0.0
      y: 0.0
      z: 0.0
  - 
    force: 
      x: 0.0
      y: 0.0
      z: 1.0
    torque: 
      x: 0.0
      y: 0.0
      z: 0.0
  - 
    force: 
      x: 0.0
      y: 0.0
      z: 0.0
    torque: 
      x: 0.0
      y: 0.0
      z: 0.0
  - 
    force: 
      x: 0.0
      y: 0.0
      z: 1.0
    torque: 
      x: 0.0
      y: 0.0
      z: 0.0
step_plane: []

• The values in the field name are chosen so that

  syropod_highlevel_controller/src/state_controller.cpp

  Line 1625 in 26c0c71

  std::string leg_name = tip_name.substr(0, tip_name.find("_"));

  will correctly recognize them.
• I wasn't sure how to construct the step_plane values, so I left them empty.
• the wrench.force.z is set to 1 if the tip switch is pressed and 0 when not.

In my understanding, this should be sufficient to get that part of the code rolling, but it still doesn't seem to be doing what I think it's supposed to be doing. For example, it does these little "jumps" when stepping onto obstacles about 5cm tall, like you can see around 0:12 on the video (https://youtu.be/gDRpkwpoU_c?t=12).

Any pointers would be appreciated.

Cheers!

[hooram]

Never mind the point about the lack tip force calculation code. I found it here.

syropod_highlevel_controller/src/model.cpp

Line 667 in 26c0c71

void Leg::calculateTipForce(void)

[navindak]

Glad you could sort it out. Thanks for sharing the video, it is awesome! :-) Does your hexapod have a name?

[hooram]

Thanks! Any suggestions for the name?

Actually my question still stands. I figured out that the ground touchdown detection only gets called within the handler for the /tip_states topic, so it seems that it only works with an external sensor. I've got one hooked up anyway, and I'm pretty sure that it's doing what it's supposed to be doing. But it still seems to be not doing what I think it's supposed to be doing. For example, if I set the damping and stiffness constant to a small value, say, 0.1, (to make it as "squishy" as possible) then when a foot touches down at a higher z, it should hold its z position there, without exerting more downward force, correct? Ultimately I'm trying to get it to behave somewhat like Zenta's MX Pheonix like in this video (https://www.youtube.com/watch?v=aH07qF_bhgA).

Perhaps the issue is that what I think it's supposed to do is not what it actually does.

[hooram]

Or more precisely, like in this video. https://www.youtube.com/watch?v=a9l0bHHm-yY

How should I go about tuning the impedance controller parameters? Say, if i got the magnitude of tip_forces to be between 0 and 100 by adjusting force_gain, what would be a good combination of the rest of the parameters?

[navindak]

The team will get back to you with a detailed answer in the next few days. We are preparing for a field deployment these days and everybody is pretty busy with that at the moment. Apologies for the delay.

[navindak]

As for names, we have found naming robots at times can be as hard as building them! A few of the legged robots we have are:
Zee
Weaver
Bullet
MAX
Magneto
Gizmo
Whizmo
Zero
Bruce

[fctalbot]

Hi @hooram,

I believe the answer to your question is to set a parameter within your hexapod config (i.e. the main config used to set up the kinematic model etc.)

You will want to set rough_terrain_mode to true and play around with the touchdown_threshold and liftoff_threshold.
Considering your contact switches output 0.0 or 1.0 to the tip_states topic I believe the default touchdown/liftoff thresholds of 0.9 and 0.1 will work.

Unfortunately the admittance control system (using joint efforts) and "rough terrain mode" (using tip force sensors) are separate and adjusting params for one does not affect the other. Also the "rough terrain mode" feature is not fully documented and is quite an untested feature here at the lab so you will have to use it with that caveat.

You can dive into the use of the operation of rough terrain mode here:
https://github.com/csiro-robotics/syropod_highlevel_controller/blob/master/src/walk_controller.cpp#L1065

Good luck and let us know if you manage to get it working.

Fletch

[fctalbot]

Also just on filling out the tip_states topic. Fine to leave the step plane empty - that field was implemented for external sensing of steps for stair climbing. For the name field you will want to use "AR", "BR" etc without underscores

[hooram]

Awesome, thanks for the info. I just got back from holidays and tested it out with those options you mentioned. I think for my setup, stiffness ~ 15, damping ratio ~ 1, force gain ~ 0.5, and mass ~ 3 seem to do the trick.

Without doing setserial /dev/u2d2 low_latency, I'm getting around 4Hz for the topic /syropod/{AR|BR..}_{coxa|femur|tibia}_joint/state. With it, I'm getting around 30Hz, but somehow it seems to cause instability in the communication with the U2D2, and cause it to sporadically lose communication with it. When I switch the servos off and back on, then it functions normally, again. Do you have any ideas in this regard?

I also tested out the rough terrain mode. It goes through the startup sequence fine, but after walking around for a minute or so, it would throw the error std::out_of_range and poop out. I was trying to debug it to see where it came from, but I haven't really worked with c++ at all, so I only got as far as identifying that it happens in the loop method of StateController.

[benjamin-tam]

Hi @hooram,

Were you able to sort out some of your issues? For the communication issues with the u2d2, we don't have experience using it with our robots (we have used USB2Dynamixel or independent RS485 chips for comms). Are you currently using the python dynamixel drivers? We are currently in the process of releasing our dynamixel_interface which uses the newer Dynamixel SDK which provides greater functionality including bulk read/write to greatly increase the rate.

[hooram]

Yes, I was able to sort it out.

The servos I got are used ones, and some of the values in the EEPROM control table on those servos were not the same. For example, some servos had return delay time set to 500 ms (I guess the previous owner needed it like this for some reason), and they didn't all have the same compliance margin, etc. Once I changed those values in the registers to the same value across all servos, the problem went away. I didn't see any mention of this documented anywhere, so if someone runs into the same problem, I hope this can help.

On a side note, what's your experience with the MX servos' thermal performance? I've got the super old RX28s, and they heat up like crazy. The femur joints would overheat after two three minutes of the bot just standing still. I ended up drilling holes in the casing and installing small fans, and now they all stay below 50 degrees.

Any news on the rough terrain mode?

[benjamin-tam]

Good find, we should add your dynamixel issue and fix into troubleshooting for others.

We haven't had any major thermal related problems with the MX64 and 106s, even when running for extended periods of time in the sun. The errors we get often are overload if the legs get stuck. From your video it doesn't look like your robot weighs a lot, but maybe it is at the top end of the torque available to keep it standing.

@fctalbot should know more about the rough terrain mode.

[23pierre10]

Hi all,
Just like @hooram I am trying to implement rough terrain mode with external sensors, so far I added a gazebo model of this sensor and wrote a node that publishes information to /tip_state topic. However just like @hooram I am getting this error
"terminate called after throwing an instance of 'std::out_of_range'
what(): map::at"
I thought it was coming from the step_plane part being empty but it does'nt look like so.
It would be great to make some progress on that subject as it could be a super cool feature.
I am hoping that it's not too late to keep searching about that...
Cheers,
Pierre

[hooram]

Would also love to know if there's any update on this!