Tag Archives: MoveIt!

List of ideas

As I have many ideas floating about on what to work on next, I made a list to see try and see which ones are worth prioritising:

GUI updates
- Graph for visualising sensor data
- Improved motion editing
Static balancing
Implement MoveIt! trajectory following via GUI
Walking routines
Advanced movement: Trajectories generate from MoveIt!, combined with active balancing as the robot moves

This is just an initial list, which I hope to expand on in the future.

My immediate plans right now are to continue tidying up some GUI graphical details, implement a simple sensor data plotter (I know rqt_plot does a fairly good job of this already, but I’d like to have sensor data integrated in my GUI) and get back to trajectory generation tests using MoveIt!

Further integration with MoveIt!

Leave a reply

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):

Useful links

I have put together a list of links, mostly from the ROS answers site, which were very helpful in getting the controllers to finally work:

Control GUI updates

Leave a reply

Progress is going well with my Qt control GUI. The main updates are:

New button to cut torque on all motors.
New motor value editor, used for writing to the servo control table addresses. The address of choice can be selected, and a value can be set to an individual servo or to all servos at once, using the broadcast ID (254). Also included are three custom functions which write position/speed or torque using more intuitive values: radians, rad/sec or % torque respectively.
New position dials for directly controlling the position of each motor.
In order to control and receive feedback from the motors, all these GUI functions interface with the ROS publish/subscribe mechanism or ROS services, which my custom usb2ax_controller ROS package is providing in its own separate ROS node.
I have been playing around with Qt style sheets to customise the GUI’s main elements such as background, buttons etc.. This was fairly time consuming but overall I think it improves the overall look and feel rather than just having standard grey boxes! I have also used QDockWidget to make various parts of the GUI easy to hide/show, pop out or dock and resize. This seems much more flexible than putting all widgets on one form, or using multiple standard windows or even tabbed windows.

Disconnected

Connected

Motor value editor

Motor position dials

Now the foundations are laid, it’s time to delve deeper into MoveIt!

Robot control GUI first steps

Leave a reply

I have switched focus to software at the moment, and am writing a basic user interface that will let me interact with the servo controller and the ROS packages, specifically the MoveIt! Move Group Interface/C++ API.

The interface is written in Qt using the Qt Creator IDE. As this is very ROS focused, I am building the GUI as a ROS package using catkin_make, which was tricky to set up inside Qt Creator, but worked in the end!

Currently the GUI can start a ROS node and receive current and goal position/velocity for each servo. It also enables the creation of a list of joint poses from the current robot’s state, and the ability to add them to a second list, which will act as a queue for moving through sequences of poses later on. The lists can be manipulated and also saved/loaded to CSV text files. A group of slider widgets shows the robot’s current joint positions, with added markers to show ‘target’ positions.

A number of buttons are yet not implemented, but the idea is to make this a quick and easy interface to a number of motion plans using the MoveIt! API, as I found it cumbersome trying to test with just a simple test C++ file. Hopefully this is the first step to a GUI with many features to come!

All source code is available on GitHub if you want to have a look.

Robot VR model updates

Leave a reply

The robot model has got a small update to make it better resemble its real counterpart rather than the default Bioloid humanoid.

I have also had some success testing the Move Group Interface/C++ API with the robot, as well as managed to start a Qt widgets project using ROS’s CMake build system. This is in its very early stages right now, but will form the basis for further tests and advanced motions with the MoveIt! package.

Robot Revival

1 Reply

The Bioloid story

Many moons ago, I purchased my first humanoid robot, an 18-servo Bioloid Comprehensive Kit. At the time, humanoid robotics for hobbyists was at its early stages, and I chose the Bioloid after much deliberation and comparison with its then main competitors, the Hitec Robonova and Kondo KHR-2HV. I went for the Bioloid mainly because of the generous parts list, which doesn’t limit the design to just a humanoid robot, as well as the powerful AX-12+ Dynamixel servos. These have a number of advantages over the more traditional simple servos, such as multiple feedback options (position, temperature, load voltage, input voltage), powerful torque, upgradeable firmware, internal PID control, continuous rotation option, a comms bus that enables the servos to be daisy-chained … and the list goes on!

After building some of the standard variants trying out the demos, attempting a custom walker, and playing around with Embedded C on its CM-5 controller board, I never got around to actually doing the kit any real justice. I have finally decided to explore the potential of this impressive robot, and make all that money worthwhile!

An old creation

Another view

ASIMO!

This post begins one of hopefully many, in which I will detail my progress with the Bioloid robot.

Initial hardware ideas

The general plan for hardware is to extend the base platform with various components, avoiding the need for custom electronic boards as far as possible, as I want my main focus to be on software.
The Bioloid’s servos are powered and controlled by the CM-5 controller, which has an AVR ATMega128 at its core. I have played around with downloading custom Embedded C to the CM-5, but in terms of what I have in mind, it is much more convenient to be able to control the servos directly from a PC. The standard solution is the USB2Dynamixel, however much of this chunky adaptor is taken up by an unnecessary serial port, so I went for a functionally identical alternative, a USB2AX by a company called Xevelabs. The PC/laptop control will hopefully be replaced by a Raspberry Pi 2 Model B (on back order!) for a more mobile solution. I have not thought about mobile power yet!

Despite the impressive servos, the stock Bioloid offers little in terms of sensors. A provided AX-S1 sensor module has IR sensors/receiver, a microphone and a buzzer, all built in to a single package, which resembles on of the servos, and acts as the Bioloid’s head. Although updated controllers by Robotis have emerged over the years, the original CM-5 had no way of directly integrating sensors to it, and was limited to the AX-S1.

Since a bunch of servos without any real-world feedback does not really make a robot, I am going to add a number of sensors to the base robot. The current plan is to use a MinIMU-9 v3 for tilt/orientation sensing, and a number of Interlink FSR 400 Short force sensing resistors on the feet. Very conveniently, the undersides of the Bioloid’s feet have indents in their four corners which perfectly match the shape of the FSRs! A Pololu A-Star 32U4 Mini SV (essentially an Arduino board) will perform the data collection and pass it over to the PC via serial-to-USB.

That is as far as my current considerations go in terms of hardware. At some point I will look into vision, which may be as simple as a normal webcam. I originally thought that an Xbox Kinect would be ruled out because of size, but apparently it can be done!

Initial software ideas

I plan on using ROS (Robot Operating System) as the main development platform, with code in C++. As well as playing around with ROS in the past, its popularity in a large number of robotics projects and large number of libraries makes it a very development platform. Also, I recently discovered the MoveIt! package, which would be great to try out for the Bioloid’s walking gait.

For simplicity, the A-Star will be programmed using the Arduino IDE. I was pleasantly surprised that I wouldn’t have to write any serial comms code to get the sensor data into the ROS environment, as a serial library for the Arduino already exists. ROS is already looking like a good choice!

The A-Star will initially just serve ROS messages to the PC. It may potentially perform other functions if it has the processing power to spare, but for now there is no need. A ROS service running on the PC will be needed to interface with the Dynamixel servos, instructing the servos to move, reading their feedback and publishing the robot’s joint states to various other ROS nodes.

My next post will focus on the new sensor hardware. Until then, please let me know your thoughts and suggestions, all feedback is welcome!