Yes, I started from it and I had to tweak it to cross-compile it. In 
particular, the check for libusb is not compatible with 
cross-compilation, as it absolutely want to get my 
/usr/include/libusb-1.0 in the compilation paths. Also, I noticed the 
depth image was not exported, so I had to add a bit of code to implement 
this part.

A big part of the cpu load is in the USB management in the kernel (35%), 
then the ros infrastructure (rosout, roscore, etc...) is using 3-5% , 
and top is reporting 45% user-time load.
For comparison "rostopic hz" was using around 7%.

Regarding optimisation, I would say the current code is definitely 
cpu-agnostic and I guess optimisation would require to use some of the 
feature of the CPU, but I have not much experience on optimising for the 
gumstix.

Cheers

On 11/18/10 18:25, Radu Bogdan Rusu wrote:
> Cedric,
>
> Awesome! Where do you think the CPU load is coming from? Can you 
> profile it? Let's see if there's ways of improving that, as clearly we 
> wont have too many CPU cycles left for processing if the driver alone 
> is eating up that much :)
>
> Are you using the ros-pkg-git kinect driver?
>
> Cheers,
> Radu.
>
>
> On 11/18/2010 07:48 AM, Cedric Pradalier wrote:
>>
>>
>> For information, we just managed to have the kinect working on a gumstix
>> overo (arm). Once the cross-compiling is done, there is no major
>> impediment.
>> We temporarily hacked the driver to publish only the depth image for
>> this test.
>>
>> In this setup, we publish about 9 fps (rostopic hz) and use around 65%
>> of the CPU.
>>
>> Next step: see if we can even control a robot with this information :)
>>
>> Cheers
>>

-- 
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp