PDA

View Full Version : [Project] Beginnings of ROS on the HROS-1/Hello from University



Piper
06-30-2015, 02:00 PM
Hi all,

Sorry for not formally introducing ourselves earlier. I'm part of a university team with 5 of the HROS-1 robots. To give you a quick update of our progress, we worked through all of the available code, expanded the scope of node server to call commands and monitor progress on the web, implemented the face detection algorithm in openCV and wrote a Python wrapper to call the rme poses outside of running the program.

Since we seemed to have tapped out the capability of the software that currently exists (and we wanted to continue to do cool things) we've decided to start integrating the system with ROS for HROS-1. We've got Indigo installed on Desktop and RPi's (in the robots), and communication working between nodes on different machines. Currently, we're trying to use the Arbotix Pro Controller with the existing ROS library for it, seen here: http://wiki.ros.org/arbotix?distro=indigo

So a few problems that we've run into:
1. There's no documentation on the Arbotix Pro Robocontroller that's in the HROS-1. At least, we haven't found any yet. Is this custom made for these robots? If not, does anyone have experience/more details on it.

2. We are currently trying to run the controller with the existing code for the Arbotix Terminal (part of the ROS Arbotix Stack). This should allow us to view and assign servos detected by the board. Currently, we're working with the board outside of the robot, directly hooked up to the desktop running Linux/ROS and we're trying to hook one servo at a time so it assigns an ID to the servo. We're able to run a program that looks for the servos but it never identifies any. This program (http://wiki.ros.org/arbotix_python/Tutorials/Setting%20Servo%20IDs) is our example and we should be seeing a "1" when we run it with one of the servos but we just get "..." the entire time.

Does anyone have any experience with the robocontroller or ROS and have any ideas how to help us out. We think we'd be able to move pretty quickly to controlling the HROS-1 from a higher level if we could figure this out.

r3n33
06-30-2015, 02:38 PM
Hi all,

Sorry for not formally introducing ourselves earlier. I'm part of a university team with 5 of the HROS-1 robots. To give you a quick update of our progress, we worked through all of the available code, expanded the scope of node server to call commands and monitor progress on the web, implemented the face detection algorithm in openCV and wrote a Python wrapper to call the rme poses outside of running the program.


Hi Piper!

You all have been busy :) I'm curious if/what you've done with the OpenCV data, possibly keep the robot's head looking towards a detected face?

Good going on getting up speed with ROS. I wish I had some helpful information but I'm in a bit of a holding pattern for a little while. Anyway, can't wait to see what you guys come up with.

tician
06-30-2015, 08:24 PM
The arbotix library is completely incompatible with the arbotix-pro, and the installation instructions for 'arbotix_firmware' are still incredibly out of date. Everything for arbotix/arbotix-m has been moved to github. None of the code.google files should be used for the arbotix or arbotix-m as they are quite old and kept alive only for reference.

The first round of beta HR-OS1 have arbotix-pro that are essentially clones of the CM-730 with some changes to layout, and I'm thinking there were a couple small changes to the firmware regarding the LEDs. Hoping the second round of HR-OS1 get the newer revision of Arbotix-Pro with the reworked TTL and RS-485 buss connections that can safely coexist (like the CM-700, instead of mutually exclusive design of CM-730). The CM-730/Arbotix-Pro simply behave as a dynamixel device and pass-through with an on-board FT232RL USB2UART IC. The FT232RL connects to one UART, the CM-730/Arbotix-Pro processes any commands for itself (read/write), then passes it on to the primary dynamixel buss of the servos.

Unfortunately, the CM-730 firmware does not implement a pseudo-'sync_read'/'bulk_read' like the USB2AX and regular arbotix to get around the USB timeout issues of using multiple AX-compatible 'read' commands. It is probably something I will work on when I get an arbotix-pro, since taphi expects a lot of position/velocity/effort feedback from the servos and AX-series servos do not implement the actual 'sync_read' and 'bulk_read' commands of the MX-series and Dynamixel Pro servos.

jwatte
06-30-2015, 10:41 PM
None of the code.google files should be used for the arbotix or arbotix-m as they are quite old and kept alive only for reference.


Delete them all, check in a README.txt that points at GitHub...

DresnerRobotics
07-01-2015, 05:12 AM
Hi all,

Sorry for not formally introducing ourselves earlier. I'm part of a university team with 5 of the HROS-1 robots. To give you a quick update of our progress, we worked through all of the available code, expanded the scope of node server to call commands and monitor progress on the web, implemented the face detection algorithm in openCV and wrote a Python wrapper to call the rme poses outside of running the program.

Since we seemed to have tapped out the capability of the software that currently exists (and we wanted to continue to do cool things) we've decided to start integrating the system with ROS for HROS-1. We've got Indigo installed on Desktop and RPi's (in the robots), and communication working between nodes on different machines. Currently, we're trying to use the Arbotix Pro Controller with the existing ROS library for it, seen here: http://wiki.ros.org/arbotix?distro=indigo



As others said, that package is not compatible with the Arbotix-Pro. It's outdated and written for the Arbotix-M specifically. We do have a project in the works that will create a specialized firmware for the Arbotix-Pro and accompanying ROS package, but I cannot give you an eta on that currently.

The new Arbotix-PRO ROS firmware will not be compatible with the existing CM730-based firmware that is used in the Darwin-OP/HROS1-Framework.




So a few problems that we've run into:
1. There's no documentation on the Arbotix Pro Robocontroller that's in the HROS-1. At least, we haven't found any yet. Is this custom made for these robots? If not, does anyone have experience/more details on it.


It was custom made for this project, and is still in beta as well. This is the reason we do not yet sell the Arbotix-Pro by itself (along with waiting on our contract manufacturer to finish our latest batch). However, the reason the Wiki points to the CM730 documentation is because almost all of it is directly applicable. The Arbotix-Pro was built to be a drop-in clone replacement for the CM730, so please refer to the Darwin-OP documentation on the CM730 for more info: http://support.robotis.com/en/product/darwin-op/references/reference/hardware_specifications/electronics/sub_controller_(cm-730).htm

There is also software documentation that details the CM730 libraries within the framework.



2. We are currently trying to run the controller with the existing code for the Arbotix Terminal (part of the ROS Arbotix Stack). This should allow us to view and assign servos detected by the board. Currently, we're working with the board outside of the robot, directly hooked up to the desktop running Linux/ROS and we're trying to hook one servo at a time so it assigns an ID to the servo. We're able to run a program that looks for the servos but it never identifies any. This program (http://wiki.ros.org/arbotix_python/Tutorials/Setting%20Servo%20IDs) is our example and we should be seeing a "1" when we run it with one of the servos but we just get "..." the entire time.


Please use the provided dxl_monitor within the HROS1 Framework to assign servo IDs and make changes. To reiterate for others reading through this thread: The existing ROS Arbotix Stack is NOT compatible with the Arbotix-Pro. There will be a separate ROS Arbotix-PRO package and firmware to be released later this year. The architecture between the Arbotix-M and Arbotix-Pro is entirely different.



Does anyone have any experience with the robocontroller or ROS and have any ideas how to help us out. We think we'd be able to move pretty quickly to controlling the HROS-1 from a higher level if we could figure this out.


Unless you intend to design the entire control system and IK/walking gait from the ground up, I suggest you look into the ROS/Darwin-OP projects that are available online. These simply wrap the existing Darwin-OP Framework into a ROS package, which is the simplest way to integrate ROS to the HROS1. HumaRobotics recently posted a pretty good writeup on their integration of the Darwin-OP to ROS, which would serve as an excellent starting point. There are also a few other projects out there that do something similar.

http://www.generationrobots.com/en/content/83-carry-out-simulations-and-make-your-darwin-op-walk-with-gazebo-and-ros

Another research group: http://wiki.iri.upc.edu/index.php/Darwin_installation

http://wiki.iri.upc.edu/index.php/DarwinRobot

http://wiki.iri.upc.edu/index.php/IriDarwin

We have created a small hand-picked development group that is working on implementation of ROS on our Hexapods & Humanoid platforms, however the current focus is finishing the hexapod project before moving towards humanoids. The HR-OS1 will stay based around current framework and be integrated into ROS similar to how Huma has implemented this, while the HR-OS5 will use that as an intermediary step with the eventual goal of moving it entirely away from the Darwin-OP based framework and towards a pure-ROS implementation. I can make no guarantees on the release dates of these projects though, as this work is very time consuming.

Piper
07-02-2015, 03:05 PM
Hey all,
Thanks for the advice. Two questions now:
1.) If we're gong to write a wrapper for the existing HROS-1 Framework, do you have any suggestions of where to start working within it?
2.) If we do go ahead and do this, integrating as much into ROS as possible, do you think it will all be for naught when the new framework eventually comes out? Or will the new framework for ROS be able to fit in with whatever we've written by then. I guess that's kind of a case-by-case thing depending on our approach but I figured I'd see if you all have any thoughts.

DresnerRobotics
07-02-2015, 07:39 PM
Hey all,
Thanks for the advice. Two questions now:
1.) If we're gong to write a wrapper for the existing HROS-1 Framework, do you have any suggestions of where to start working within it?
2.) If we do go ahead and do this, integrating as much into ROS as possible, do you think it will all be for naught when the new framework eventually comes out? Or will the new framework for ROS be able to fit in with whatever we've written by then. I guess that's kind of a case-by-case thing depending on our approach but I figured I'd see if you all have any thoughts.

1) I believe the solutions I linked you wrap the entire Darwin-OP framework. If you're looking for more information on how the library is initialized and a basic teleoperation demo, check the ps3_demo or the node_server projects.
2) We intend on looking at the two solutions I had linked and seeing how they tied into the Darwin-OP framework, and likely using one or both as a starting point for the integration. We've only just now started work on this, so too early to give you many details.

My goal for the ROS_Humanoid project is to make an open, flexible ros package that can handle a number of configurations (OS1, OS5, Darwin, Bioloid).

There will be two phases:

1) Wrapping the existing HR-OS1/5 framework into a ROS package. This allows us to keep our existing work and add ROS packages on top of it. We might eventually break out the Darwin walking IK/gait out into it's own package within the project and implement a better control/motion package than the current Darwin "Action" module (which is not great) and replace it with something KDL or Moveit Based. This Phase 1 project will be based around the existing Arbotix-Pro CM730 firmware and HROS1/5 Framework. Those steps would be in preparation for phase 2:

2) Complete move away from the Darwin-OP based framework, and implementation of ZMP based walking gait. A 'pure' ROS implementation if you will. This will be where our project splits into two separate code bases for the OS1 and OS5. The OS1 will stay behind with whatever we come up with for it in Phase1, while the OS5 will branch away into the Phase 2 code project with ZMP, and take advantage of the new Arbotix-Pro ROS firmware and package. The OS1 doesn't have the physical hardware capable of a ZMP gait. so it will likely stay based on the Darwin-OP framework.

So within the context of Phase 1, I doubt any of your efforts would be for naught. Once we get a bit more off the ground with Phase 1 (over the next 30 days or so) we invite you to collaborate with us on the execution of it. Perhaps we can avoid reinventing too many wheels.

jdddog
07-02-2015, 08:34 PM
What worries me about the current HR-OS1 framework is that it is licensed with the GPL, which means that any software that links to it also has to be GPL.

The ROS community prefers liberal licenses (http://wiki.ros.org/DevelopersGuide#Licensing) so that individuals and companies are unrestricted in what they can do with the software.

If you made a ROS framework for the HR-OS1 and other robots, could you at least give the message files a non-copyleft license so that people are free to integrate their software with your robots without restriction?

DresnerRobotics
07-02-2015, 11:07 PM
What worries me about the current HR-OS1 framework is that it is licensed with the GPL, which means that any software that links to it also has to be GPL.

The ROS community prefers liberal licenses (http://wiki.ros.org/DevelopersGuide#Licensing) so that individuals and companies are unrestricted in what they can do with the software.

If you made a ROS framework for the HR-OS1 and other robots, could you at least give the message files a non-copyleft license so that people are free to integrate their software with your robots without restriction?

Unfortunately we don't have any control over the license of the HR-OS1 Framework. I asked ROBOTIS what the Darwin-OP framework was released under, they came back and said GPL was okay... then later revised that to LGPL. Since I had already released the code under GPL and they haven't ever placed an official public license on the code, I told them I intended to keep the original license it was released under (as none of my code uses what they wanted under the LGPL).

I don't think this is much of an issue, worst case the wrapper package around the OS1 framework would need to be GPL, but anything in addition to that can be whatever we choose. I likewise would prefer to keep things in line with BSD.

Piper
07-03-2015, 03:01 PM
Cool.
We have a group working on these robots over the summer, mostly with the intent of getting them sufficiently operational. We'll start classes up again at the beginning of September and at that point, we'll be trying to use the HROS-1 in some capacity for our school's engineering design projects. In some sense, we'd love to have at least some ROS functionality at that point and start to work on higher level things/real applications. Obviously, full ROS integration won't be done at that point and the ROS wrapper will still be a work in progress (on your guys' part). We will continue reading up this weekend on methods for writing wrapper and we'll try to keep you all posted on our progress. Let us know how you're doing to, and hopefully we can collaborate a little more fully when y'all have finished the Hexapod work in a few weeks. Good luck!

tician
07-03-2015, 03:13 PM
The only really useful part of the DARwIn-OP framework is the gait engine, which can be split off into its own isolated ros node using existing message types. E.g. take in Twist messages and output JointState messages to whatever node is actually pushing the JointState data to the dynamixel servos. The new CM-730/Arbotix-Pro node could subscribe to the JointState messages and easily publish the accelerometer+gyro values in Imu messages. It could also use the arbotix_msgs/Analog message (which should be BSD 3-clause) for exposing the Arbotix-Pro/CM-730 ADC values and/or the battery voltage. Would be nice if arbotix-pro firmware eventually does a pseudo-'sync_read'/'bulk_read' to publish feedback JointState messages, but not necessary for the DARwIn-OP gait engine (open loop except for some Imu 'balance' and fall detection).


Somewhat OT: I've been focusing mostly on YETIS (BSD 3-clause) for a while, but will probably shift back to getting TAPHI (BSD 3-clause) fully functional once the I2C of the target board is ironed out. I hope to eventually isolate the DARwIn-OP gait engine into a node for TAPHI, but it is not really a priority for me right now compared to the XML-stored motion player node and the stochastic gait seeker nodes. Most of TAPHI's code is still too crappy to dare share, but its messages are basically an 8-byte 'message header' (two each for 'node identity', 'msgCount', 'nObjects', and 'message checksum') then an array of 'objects' each with a 4-byte 'object header' (two for 'device/actuator/sensor identity', one for 'mode', and one for 'status') and a Vector3 (actuator: position, velocity, effort) (gps n-vector: x, y, z) (other: 12 or 24 bytes generic data). The Vector3 of the TAPHI message will probably be 32-bit single/float since ARM boards for controlling dynamixels are still 32-bit and it's less data to send, but might stick with 64-bit double/float for greater compatibility with ros.

Weebo
07-04-2015, 09:50 AM
1) . The OS1 doesn't have the physical hardware capable of a ZMP gait. so it will likely stay based on the Darwin-OP framework.

I'm just curious about what kind of hardware it's missing to be able to implement the ZMP?

tician
07-04-2015, 11:06 AM
I'm just curious about what kind of hardware it's missing to be able to implement the ZMP?
Real-time ZMP gaits tend to require lots of processing power for dynamics analysis, lots of sensor feedback to confirm joint positions and body movement, and lots of really nice actuators to keep the robot quickly reacting to changes. While I really love AX-12, they do not implement 'sync_read'/'bulk_read' instructions like the MX and Dynamixel-Pro (so have to use many individual 'read' packets to get joint feedback) and they do not have the strength, speed, or precision to provide great control of a fast and heavy humanoid. Slower and more human-like gaits using ZMP calculations might be achievable, but the 'energy intensive', 'always bent knees', 'always rapidly jogging in place' type gaits like the DARwIn-OP's are not really realistic goals for real-time ZMP control with an RPi2 and AX-12. The DARwIn-OP gait is a mostly open-loop coupled oscillator system that was designed/tuned using ZMP simulations, but has never really made much sense to me anyway. Ever seen a toddler walk or attempt to run?

jwatte
07-04-2015, 02:55 PM
I don't think you necessarily need to real-time simulate to achieve a stable dynamic gait a la ZMP. (I undestand that ZMP is a specific way of getting there, but I'm more interested in the top-level goal that it claims to achieve than the specifics of that implementation approach.)

I think, if you have higher-level intents in your control code, like "right foot more to the right" or whatever, then a balance sensor in the head, and a delta onto a static walk cycle derived from that, may achieve a fairly realistic and smooth walking gait. It's not even clear that you need to base your walk on IK to achieve this, but I think that would probably help. The main challenge then will be tuning the controller that deltas the gait walking engine.

(Also, if you look at the Kondo KHR-3HV, it has a more natural-looking gait than the Robotis bots, and I'm pretty sure that's just static, not even sensor adjusted.)

The other peeve I have with these lower-end robots is that they don't have heading in the ankle assembly, so they have to turn slowly by slipping the feet diagonally. I think this is terrible! I recently added a heading servo to the ankles of the Darwin Mini, but haven't figure out how to most easily describe this change to the RoboPlus 2 software. And I'm going too much off topic here, so I'll stop now :-)

vehemens
07-04-2015, 05:16 PM
If you search for ROS on github, you can find a number of packages. In addition to the ones already mentioned such as HumaRobotics (https://github.com/HumaRobotics), there's NimbRo (https://github.com/NimbRo/nimbro-op-ros) and ROBOTIS-OP (https://github.com/ROBOTIS-OP).

Piper
07-07-2015, 02:43 PM
The ROBOTIS-OP looks like the most promising one to us. We took a look around this repository, in particular the robotis_op_ros_control and figured out how ROS can interact with the motors directly, with action pages and with the pre-existing DARWIN commands (walk, stand, enable, etc.).

What do you guys think? Is there anything that needs to be revised besides the joint configurations and a model of the HROS-1 (URDF)? Did Trossen already develop a URDF file for the robot?

Thanks a ton. Let me know what you all thin. Excited to run this soon.