November | 2015 | Cognitive Dissonance

I finally got round to installing the force sensing resistors to the underside of the Bioloid’s feet. I am using the FSR 400 Short model, with male end connectors, which are small and flat and didn’t fit in the square female header pins which often come at the end of breadboard wires. I didn’t want to solder directly as I’ve damaged these sensors in the past, so I followed a suggestion on the Adafruit website and ended up using these PCB terminal blocks.

The force sensing element of the FSR fits nicely in the pre-existing cut-out on the underside of the Bioloid foot plate, and the pins are fed through a hole in the plate so they can be connected on the topside. However, in the standard Bioloid humanoid configuration, the foot plates are attached at an offset from the ankle angle brackets, which means there is not enough space between the footplate and the bracket to connect the pins. To fix this, I moved the footplates so that the ankle brackets sit along their centres. There is still some free space between the footplates when the Bioloid sits in its resting position, so hopefully the feet will not collide with each other after this change.

For completeness, I also made changes to the CAD model and also added FSR CAD models to the feet, although that is just a cosmetic addition to the model (on a related side-note, I also found a CAD model of the USB2AX which adds to the realism)! The robot’s URDF files and CAD models have been updated on GitHub.

Here are some pictures of the results:

Standard foot separation.

Symmetric foot separation.

CAD models of FSRs.

FSRs held on temporarily with sticky tape.

Close up.

Another close up.

PCB terminal blocks connecting the FSRs.

Wiring mess.

More wiring mess!

Zip ties used to tidy up the wiring as much as possible.

Another view of the foot.

And another view of the foot.

Everything but the battery wired up.

Front view.

The integration of the Bioloid with MoveIt! has reached an important milestone, with the real robot now being able to respond to MoveIt! planned trajectories! There’s still a lot to do to improve performance, but the basic framework is ready. In the next few paragraphs I will try to describe the MoveIt! configuration process up to now.

In a previous post I mentioned how the SRDF file was created as the fist step to configuring the robot to use MoveIt! The joint_state_publisher was already set up to publish the values of the joint states, which it read from my AX-12+ motor controller, so RViz was able to display the current state of the robot’s joints live when connected to the robot. Commands could also be sent to move the robot servo’s (such as those sent by the control GUI), but this was done using my own custom ROS services. The link to closing the loop between MoveIt! and the robot was to make MoveIt! able to command motor movement.

The joint controllers

Some background reading quickly led to the tutorial page on controller configuration. In trying to figure out how to first make my AX-12+motor controller provide the required FollowJointTrajectory action, I first looked at the wiki of the actionlib stack and used a C++ SimpleActionServer. However this would mean having to then implement the trajectory following, something which is already by the ROS joint_trajectory_controller package. So instead I looked into how I could get the robot to use this controller, which to lead to reading about ros_control and a very good tutorial from Gazebo. It took some time to understand how all these packages work together, and finally found that I had to implement the hardware_interface for my AX-12+ motor controller. The biggest challenge was figuring out how to configure the controller YAML files and actually get the controller_manager to spawn the controllers correctly.

I have used various roslaunch files and configuration files that set up and run the joint controllers, which I will upload shortly onto my GitHub page, along with updates to the C++ ROS AX-12+ motor controller.

The connections between the various ROS nodes and topics have now grown quite a bit in complexity, compared to the initial ROS interconnections, and now look something like this (captured using rqt_graph):