jump to navigation

MiNI-HUBO Series: LabVIEW Driver for Dynamixel Motors July 9, 2010

Posted by emiliekopp in code, labview robot projects.
Tags: , , , , , ,
add a comment

Recall Mini-Hubo, the small, humanoid research platform developed by RoMeLa. I had mentioned his joints are actuated by Robotis Dynamixel motors, high-performance networked actuators built specifically for robots.

Karl, our resident humanoid expert, has graciously shared the LabVIEW drivers that allow you to communicate with these robot-specific motors, plug-and-play style. Check out the LabVIEW Robotics Code Exchange to automatically download the driver and install it into LabVIEW. For anyone using Dynamixel motors for their own robot designs, this will save you lots of driver development time.

Download Dynamixel Motor Driver

Don’t have LabVIEW? You can check it out for free here.

LabVIEW Robotics binding to Gostai’s Urbi? February 3, 2010

Posted by emiliekopp in industry robot spotlight.
Tags: , , , , , , ,
2 comments

I was checking the incoming links to my blog the other day and found the following:

http://vote.gostai.com/forums/37683-general

It’s a product suggestion forum for Gostai users. Someone must have read my post featuring the connectivity between MSRDS and LabVIEW Robotics and thought a similar example for LabVIEW and Gostai could be useful. He/she is petitioning Gostai developers to add LabVIEW connectivity to their “liburbi,” which currently interfaces Gostai’s scripting language, UrbiScript, to languages like C++, Java and Matlab. Why not add LabVIEW to the list? 🙂

I’m still trying to figure out why that might be useful…

Both LabVIEW and Urbi are viable platforms for programming robots. Both lend tools for parallel programming. Both are intended to be open and flexible programming platforms that allow to developers to integrate with the enormous amount of robotics tools out in the industry. Both have very similar mantras. Case in point: here’s how NI has stated its claim on the robotics industry:

The robotics industry needs a software development platform that is what Microsoft BASIC was to the PC industry… A challenge for many roboticists is finding a modular, reusable software development platform that caters to all of the necessary disciplines of robotics.

Here’s a similar take from Gostai on their website:

Like PCs in the early 80’s, today’s robots are still incompatible in term of software. There is yet no standard way to reuse one component from one robot to the other, which is needed to have a real software industry bootstraping. And most attempts have been failing to provide tools genuinely adapted to the complex need of robot programming.

Both of these statements support what Bill Gates had proposed in his technology outlook article in Scientific American.

Needless to say, we’re all on the same page. So where do NI and Gostai differ? From a  high-level, it looks like Gostai is targeting researchers and hobbyists while LabVIEW Robotics is targeting more industrial-grade robotics development. But what is it about Urbi that could be useful for LabVIEW developers and vice versa? Why would it be useful for these two languages to talk to each other? It seems as though they attempt to accomplish the same things.  Without much first-hand experience with Urbi, I’ve hypothesized a scenario:

Urbi has great examples for controlling robot hardware platforms, like the Sony Aibo, LEGO NXT, and Robotis Bioloid. Assuming you’re not designing your own custom hardware platform, these examples should get you up  and running quickly.

But, let’s say you are building your own hardware platform, where you are selecting the specific motors, sensors and physical model. You are not confined to the physical model of the commercial robot platforms like the NXT and iCreate. Urbi’s library of specific hardware connectivity may not be as extensive. On the other hand, LabVIEW offers hundreds of drivers for commercial actuators and sensors. Perhaps someone could develop algorithms in Urbi and then use LabVIEW to easily connect, communicate and control their hardware.

Just a thought. Anyone is free to chime in an offer additional thoughts or scenarios.

Without knowing much about how the two can help each other, I went ahead and voted on the idea and I encourage anyone else to do the same. I mean, why not? Like I said in regards to MSRDS, the more connectivity we have between development tools, the more sharing and reuse developers have with their code. The more the better is what I say.