PDA

View Full Version : Tekkotsu vs. ROS



RobotAtlas
07-31-2010, 12:03 PM
I think we have some people on this forum that have experience with both Tekkotsu and ROS.
It would be very interesting to hear thoughts and opinions on how they compare.

lnxfergy
07-31-2010, 02:49 PM
Our University lab had been using Tekkotsu for about 5 years (since it first came out), and I've been working with this group since spring of 2008. We were of course using AIBOs originally, and more recently had CMU Chiaras, and have now moved onto using mostly our iRobot Create + laptop setups. We've also very recently made the decision to move to ROS.

Tekkotsu has a specific goal: to get advanced algorithms into the hands of undergraduate students in a single semester robotics course -- at this, it excels. However, as a more general research tool, it's a bit cumbersome. I find it to be easier to integrate new hardware and external libraries into ROS. There's two main reasons for this. First, ROS uses a distributed system which allows you to quickly tie in new modules, Tekkotsu on the hand compiles a massive 200mb library file + 30mb executable, they've made great strides in recent years in bringing down the compile time, but it's still much slower to develop low-level code in Tekkotsu than in ROS. Second, everything in Tekkotsu has to be C++ (or their state machine language), whereas I can integrate Python, Java, Lisp, or Octave based code into ROS. This second item is especially important for us, as our students have widely varying backgrounds, and I'd rather they spend the time learning robotics than fighting with the oddities of C++.

The Tekkotsu system is also very heavy on vision. I've never seen a Tekkotsu-powered robot with a laser scanner, or even many with extra sensors besides a webcam. A majority of the documentation and code is targeted at their (cognitive science) Dual-Coding approach to vision (and algorithms that build a top of it, such as visual localization using particle filters) . This vision system is nice in that it allows students to quickly try things out in a visual system -- however, it's built on top of CMVision in such a way that everything depends on being able to easily segment the world (by color). You'll notice most Tekkotsu robots live in very unrealistic environments, paying attention only to brightly colored objects. You can program a robot to play tick-tack-toe in just a few lines of code -- but only if you can get a good segmentation of colors. ROS on the other hand, does not constrain itself to just vision based systems. They make big use of lidars and other sensory.

There's also a large number of research groups creating code targeted at ROS -- the Tekkotsu team is much smaller. Most of the other groups using Tekkotsu aren't actively developing new code for it, instead using just as a tool in their class.

Summation: I think those functions that Tekkotsu implements are done quite well, and are well suited for their intended audience and goal set, but if you want to add more, it's a chore. We've recently been pushing more towards real-world environments -- and because of that, Tekkotsu really doesn't meet our needs as well as ROS. For instance, one of the things we've wanted to do is have our robot navigate the office here, from room to room. An attempt was made this spring semester to do that inside Tekkotsu -- we never really got it to work. I then spent about 2 weeks getting our robots over to ROS, and over the past week have gotten about 60% of our navigation working (I'm just wrapping up a bunch of smaller items before we hit our first milestone).

-Fergs

ejtttje
11-09-2010, 01:13 PM
Hi, I'm one of the main Tekkotsu developers, just stumbled across this thread... I think Inxfergy has a good summary, but I'll add a little.

I think ROS and Tekkotsu target different types of robots. ROS is very scalable on the high end, where they are targeting $100k robots like their PR2 with all kinds of sensors and distributed processing to back it up. That distributed processing defines the ROS architecture, whereas Tekkotsu is primarily designed to run on-board a single robot. Each system has some flexibility in this regard, Tekkotsu does have some network facilities and ROS can simply use the loopback to run everything on-board, but each pays a price: code complexity for distributing Tekkotsu vs. computational overhead/latency in ROS.

Tekkotsu's primary target of smaller systems is a key constraint: we must keep low overhead in order to retain good latency on low-end hardware. The benefit however is that we can more reliably control realtime systems like legged robots, and are easier to setup and manage in a lab or classroom environment (no external servers, no networking requirements, more code re-use and consistent source tree (i.e. multiple languages do have downsides when trying to work across modules))

I have the highest regard for the ROS ecosystem though, there's a lot of good research going on there and Tekkotsu could even serve as a ROS node if anyone were interested in such a project, but I think the choice is best made by looking at your robot constraints: if you are running a low-power/low-cost robot, particularly a real time system like a legged robot where network latency could be an issue, and/or using primarily visual sensing, then Tekkotsu is a good fit. If you have a healthy budget and are planning to build a large system (e.g. laser scanners, wheeled base, complex manipulators), then ROS is a more obvious choice.

Also, in recent news we are adding new visual features like SIFT (http://en.wikipedia.org/wiki/Scale-invariant_feature_transform) and ARTags (http://www.artag.net/) to reduce the reliance on color segmentation... color segmentation is great in terms of efficiency once you have it configured, but it does require engineering your environment to help the robot... (not that this is always a negative, e.g. users can very easily prototype new environments for a behavior just by laying down some colored paper or tape) However, SIFT should allow 'natural' object recognition, although at greater computational cost (and still some training), with ARTags being somewhere in-between these approaches.

Anyway back to the main topic, I think ROS and Tekkotsu have similar development philosophies and ideally I'd love to see better interoperability between our projects so it doesn't have to be an either/or decision :happy:

lnxfergy
11-09-2010, 02:09 PM
Tekkotsu's primary target of smaller systems is a key constraint: we must keep low overhead in order to retain good latency on low-end hardware.

I think you're overestimating the overhead of ROS. I can run the full navigation stack plus visual operations such as face recognition on a plain old little netbook, with plenty of cycles to spare. Sure, I'm probably not going to do 3D perception using a stereo pair on a netbook, but I can't do that in Tekkotsu either. Depending on what you're running, the memory footprint of ROS can be a whole lot smaller than Tekkotsu too.


(i.e. multiple languages do have downsides when trying to work across modules))Sure, as long as everyone wants to code everything in C++.....


... I think the choice is best made by looking at your robot constraints: if you are running a low-power/low-cost robot, particularly a real time system like a legged robot where network latency could be an issue, and/or using primarily visual sensing, then Tekkotsu is a good fit. If you have a healthy budget and are planning to build a large system (e.g. laser scanners, wheeled base, complex manipulators), then ROS is a more obvious choice.A major headache I found in Tekkotsu is extending it to new hardware -- the documentation on your internal aspects related to hardware abstraction are pretty undocumented -- and the massive recompile triggered by even small updates is a huge burden in creating new platforms. Actually, on that same idea, documentation all around is a major problem with Tekkotsu.

Tekkotsu is great for a single-semester undergraduate level course, on standardized hardware. But I feel that if you want to go beyond that, it's the wrong tool for the job.

-Fergs

ejtttje
11-09-2010, 04:24 PM
A major headache I found in Tekkotsu is extending it to new hardware -- the documentation on your internal aspects related to hardware abstraction are pretty undocumented -- and the massive recompile triggered by even small updates is a huge burden in creating new platforms. Actually, on that same idea, documentation all around is a major problem with Tekkotsu.

We may have improved the HAL documentation since you saw it last, see in particular this page (http://www.tekkotsu.org/porting.html). Device drivers are among the most independent components, they would not trigger broad recompilation. I suspect you must have been modifying the "Info" header files which define the number of joints/sensors/etc. and their names and ranges for each specific robot model... that gets included by everything, but should be a fairly static file, not subject to ongoing development. That's actually the only thing I can think of which would trigger large recompilation. Behaviors use a indirect registration mechanism (as do the drivers), and thus only require the behavior file itself to be recompiled. Was there something else?

I guess this raises another difference in design: I would agree that ROS is more focused on allowing users to recombine modules to run on arbitrary robot configurations, whereas I think Tekkotsu is more focused on providing a consistent/portable high-level interface for behavior development on explicitly defined robot configurations... of course, this forum seems pretty focused on designing new robots, so this would probably be a good place to get suggestions how to streamline our hardware definition process :wink:

RobotAtlas
11-09-2010, 05:35 PM
I think ROS and Tekkotsu target different types of robots. ROS is very scalable on the high end, where they are targeting $100k robots like their PR2 with all kinds of sensors and distributed processing to back it up.

I don't know about $100k. I was running ROS with Lego Mindstorms NXT. That's less than $300 new. They have support for a lot of robots, some of them very inexpensive http://www.ros.org/wiki/Robots


Tekkotsu's primary target of smaller systems is a key constraint: we must keep low overhead in order to retain good latency on low-end hardware.
The smaller the system, the harder (and more expensive) it is to make it completely autonomous.
Small robots can't have much processing power yet. That's where ROS's distributed nature comes very handy. The robot only collects sensor data and sends it out to a "ground station" which can have a lot of computational power to crunch all those algorithms.


I have the highest regard for the ROS ecosystem though, there's a lot of good research going on there and Tekkotsu could even serve as a ROS node if anyone were interested in such a project
There's a lot of momentum in ROS and I have not seen any in Tekkotsu. Please don't take it personally, but it feels to me like Tekkotsu is dying. Going the same way Orocos went with its support for ROS is probably a good way for Tekkotsu to (re)gain some momentum.


ideally I'd love to see better interoperability between our projects so it doesn't have to be an either/or decision
At this point, I think becoming a ROS stack is the only way Tekkotsu is going to survive in the long run.

I wonder if http://www.ros.org/wiki/tekkotsu would have a lot more visitors than http://www.tekkotsu.org/

ejtttje
11-09-2010, 10:57 PM
I agree with most of what you say... indeed I'm hoping to send my resume to Willow Garage when I get my degree :wink:

But on this point:

I don't know about $100k. I was running ROS with Lego Mindstorms NXT. That's less than $300 new. They have support for a lot of robots, some of them very inexpensive
By $100k robots I'm refering to platforms such as the PR2, HERB, STAIR, HRP2, etc. These are their driving motivation for the architecture. It's disingenuous to imply it runs on the $300 NXT... as far as I can tell, it doesn't. It runs on your ~$1000 desktop computer (e.g. Ubuntu) and remote-controls the NXT over a bluetooth (?) connection.

Tekkotsu is able to run—with vision processing—on the Aibo, a 600MHz processor with 64MB of RAM, although I admit we will soon outgrow continued for support for that as a useful on-board platform. But the point is you can do interesting things with cheap, low-power platforms, but once you rely on off-board resources the complexity and expense rise very quickly before you get a return on the investment. This is unavoidable requirement for the hard research problems that the robots I listed above are trying to solve, but its overkill for a lot of simpler problems. More importantly, it can prevent solving some problems... e.g. the NXT balancing bots (http://www.youtube.com/watch?v=V40ScvJeFxg) require fast dynamic control... I'm not sure you would be able to do with the latency of a remote connection in the way.

Of course, the NXT is kind of a poor example since I don't think Tekkotsu would be able to fit onboard it either... but the general point holds for the even smaller dedicated firmwares for NXT that are actually more powerful than a full PC running either ROS or Tekkotsu simply because they can just do the computation locally rather than spending the time waiting on IO.

RobotAtlas
11-10-2010, 12:59 AM
It's disingenuous to imply it runs on the $300 NXT... as far as I can tell, it doesn't. It runs on your ~$1000 desktop computer (e.g. Ubuntu) and remote-controls the NXT over a bluetooth (?) connection.

Yep, you are absolutely right. But I didn't imply that ROS runs on NXT. I said ROS runs _with_ NXT, not _on_ NXT.
It's $15 Athlon 64 3500+ desktop though :) Do you guys have garage sales?

Aibo is really cool. I love it. Too bad Sony canceled it in 2006. Chiara looks pretty cool too. But we can build similar robot for a fraction of $3,500.

I'm sorry if my previous post was not very positive. I don't have direct experience with Tekkotsu and I was only expressing my feelings about it. Mostly about it's popularity compared to ROS.
As one famous person used to say "I could be wrong. I often am. Let's examine the facts."

ejtttje
11-10-2010, 07:42 AM
But we can build similar robot for a fraction of $3,500
Well, the plans and software are all open-source. So yes, you are welcome to build it for less if you find the parts cheaper than we do, particularly if you don't track the time it takes for assembly. But keep in mind the point of offering it pre-assembled is for professors/researchers whose time is more valuable, and whose skill is not in mechanical assembly. If your time is less valuable or you just enjoy the work then you don't have to pay someone else to assemble it for you.

And regarding other hexapods, most that I've seen "for a fraction" of the cost also have a fraction of the capability... no significant onboard computing, no camera, no arm, non-smart servos... not interesting. We don't want to have to build these things ourselves, but no one else is currently addressing these needs as a kit that can be shared with other universities. We've actually got a fairly large user base in education (tho not research :sad:), but we're not very active in the hobbyist community, so I'm not surprised you don't see much about us here. For example, I just created this account yesterday :tongue: