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
(text/plain)