KHR3-HV + Gumstix Overo / Fire

[limor]

We received from through ebay (China) a bunch of USB Mini-A
cables appropriate for use with OTG female interface found on Gumstix
daughter board. The first obvious thing to do is try to cut off as much
plastic as possible in order to minimize the size of the
non-foldable part of the small connector.

[amuthelet]

Hi,
Thanks to your extensive contributions guys, I decided to buy my KHR3 a Gumstix Overo ! It's now "fully" up and running with libkondo4 onboard..here are some topics I'm working on, just in case someone would be familiar:

- I wanted to have a small touch LCD screen onboard, so decided to go Gumstix Overo Fire + Palo35 board + LCD. The board is large indeed, so I will make some custom fix system outside of the kondo backpack. Should be ok, the biggest problem being the length of USB plugs that might interfere with arms motions..)

- x11vnc runs ok on the overo, so that I can also have remote graphical access / command from my iPhone/iPad. Cool ) Couldn't find yet a way to increase frame buffer size on overo side, so today I'm stucked on very low resolution. There is a scale parameter on x11vnc, but that's not really what I'm looking for. Did you try vnc with Summit board ? Can you "export" screen at "any" resolution ?

- I'm still fighting a bit to build an image including QT-embedded libs to be able to run a simple GUI code on the gumstix (couldn't find a simple way to opkg install the qt4 libs .. too bad), but I discovered yesterday a bitbake recipe qt4e-base-image that should do the job. It's building now, let's see what I can do with the resulting image.

- Creating new motions for KHR is really painful and unnatural. I'm new to robotics, but coming from 3D world my first feeling was: too bad I can't easily take advantage of a standard 3D character animation tool that would make life much easier (and movements more realistic !). Thanks to chrisvo's Python bindings of libkondo4, it is quite straightforward to start experimenting using Blender (http://www.blender.org). (For information I had to stick to Blender v2.49, as Blender v2.5 is based on Python 3.1 and I couldn't make libkondo4 bindings work on this level). Does anyone already experienced the programming of an interface between 3D animation packages and robot animation ?
In this context, being able to store a motion on the RCB4 through libkondo4 would be really interesting ;o)...otherway I will write an xml motion file to feed onboard real time servo command (or will run Blender on the 3D accelerated Gumstix..hmm :s).

- I read that gumstix should support 7.4V input. But before trying to plug my 2S Lipo on this little expensive stuff, I would love reading someone confirming this ) Did anyone tried this already ? In fact a fully charged 2S lipo is closer to 8.4V than 7.4V..

Cheers,
Arnaud.

[chrisvo]

Storing a motion on the RCB4 seems pretty straightforward, and I plan to add the functionality to libkondo4....

[chrisvo]

By the way, do you have any other suggestions for what I should change or add with libkondo4?

I am interested to see how the Blender modeling turns out. It really does help if we are able to create a custom character rigging in Blender that will automatically create the interpolated key frames. Blender also has a nice little Bullet-based physics simulation and some IK features which can be used to simulate and even in the future perhaps optimize the motions for stability, etc.

I already have an idea for how you can upload motion scripts to the robot, but I'm a little scared to try it right now because we're getting ready to let students use the robots in a class and I don't want to brick an RCB-4...

[amuthelet]

Hi,

About libkondo4 wish list: as of today I only did series of atomic tests with it, but it does all I need so far, except movement storage (I keep wondering why such a lib is not part of standard Kondo kit..without you I would really regret my purchase !). I may come back to you when I'm finished with all my overo confugration stuffs .. still fighting to build a overo "QT aware" image

Oh yes one great thing (maybe out of libkondo4 lib scope..) would be to be able to save HTH motions to an open ASCII file so that we can take advantage of existing motions from outside HTH.. (catch each pos sent to each servo at runtime and write it down ? or higher level, by writing down only key frames so that it's easier to edit it afterward ?).

I also tried to compile libkondo4 under Windows / Visual Studio 2008: there are some little issues such as variable declaration that are not at the beginning of a block, etc.. Not a big deal, I finally did compile but couldn't make it run properly, I'll try later (mm don't know when) and will tell you what were the problems. I had in mind to try Microsoft Robotics Suite, but don't know if the time investment is worth it. Do you have experience with Robotics Suite ?

About Blender: The good point for this package compared to Autodesk Maya / 3DSMax is of course openness, but also the integrated game engine that can be a good tool to design interactive user friendly interfaces for editing robot movement (Blender manipulators are good ... but not so user friendly for non specialists).

Real time physics could be fun for virtual previzualisation of movement, but I kind of doubt it is physically realistic enough to be used for anything else. And IK + physics might be a complex topic.. but let's see what we can do with all those interesting technologies ;o)

[chrisvo]

Oh yes one great thing (maybe out of libkondo4 lib scope..) would be to be able to save HTH motions to an open ASCII file so that we can take advantage of existing motions from outside HTH

Ah, yes, but it is already. Try opening the motion files in a text editor. They're just XML files! I would like to eventually have libkondo4 be able to read and upload these motions to the robot. Perhaps I will put that functionality in a separate C package.

Do you have experience with Robotics Suite?

I have always used Linux (with HTH4 being my only reason to keep a Windows VM) so unfortunately I do not have experience with it. I am open to try it out though...

Real time physics could be fun for virtual previzualisation of movement, but I kind of doubt it is physically realistic enough to be used for anything else. And IK + physics might be a complex topic.. but let's see what we can do with all those interesting technologies ;o)

I've simulated the humanoid robots before using ODE; even if it is not a particularly useful in terms of simulating how the real robot will move, it is quite useful for research and gaming. After all, real robots break...

[limor]

We received last Friday the new IGEP module. 3 day shipping with Fedex.




Comes with one antenna (gumstix overo comes with 2) and with the promised on-board USB powered USB OTG connector.


Here you can see it next to the gumstix overo inside the Summit daughter board.


And now next to the gumstix overo fire itself.




Unfortunately we were not able to connect the IGEP module to the Summit daughter board from Gumstix because some small ICs seem to be in the way. they can be connected facing one way or the other so need to check with IGEP which is the right way and if indeed there is a chip in the way that prevents them from attaching to each other.




Check out the following link where I've documented how we got the IGEP module to work happily in Windows 7.
http://robosavvy.com/forum/viewtopic.php?t=6731

[Voelker]

May be you could connect the IGEP on overo summit by de-soldering the mini-usb connector of the summit that acts as usb to serial. IGEP and Gumstix overo have the excact same positioning of the connector, but i don't know if its the same pin mapping.

[tinmarok]

Hello again,

Following some advices received on that forum a few months ago, i took a khr-3hv for my first steps in robotics. Thanks for everybody here

@ chrisvo : I was not able to use the kondo_read_analog in python unless i change the SWIG interface file with :

Code: Select all

%module pykondo
%{
#include "rcb4.h"
#include "ics.h"
%}

int kondo_read_analog(KondoRef ki, int *INOUT, UINT num);
%include "rcb4.h"
%include "ics.h"


End of the post moved here http://robosavvy.com/forum/viewtopic.php?p=29179#29179. Sorry to have messed main purpose of that topic

[amuthelet]

thanks chrisvo about the info concerning HTH motion files being ascii format...should have tried it

About my Blender tests, I opened a new thread here: http://robosavvy.com/forum/viewtopic.php?t=6755 describing them.
I have some perfo issues...you might have an idea ?
Cheers,
Arnaud.

[limor]

We've given up on trying to get IGEP to act as host while the OTG USB's Pin4 is ungrounded.

So we are going to use Gumstix for the time being

[limor]

[amuthelet]

@tinmarok:thanks for sharing your server code. Tried it on my gumstix, and it works perfectly to remote control my khr from my iPhone. It even makes me doubt about my onboard palo3"5 LCD + c/qt alternative. Web server + cgi sounds better in fact.
Cheers,
Arnaud.

[tinmarok]

hello,
@amuthelet : very pleased that the you use the server usefull, even if you doubt now what is the best compromise between webserver/native app.

The project has quite evolved since the first post, i'll open soon a proper topic, don't want to use that topic for another purpose of the first post

[limor]

In this post we show how to tweak the battery connectors.

1) A LiPo battery is fit it into the cavity of the KHR3HV. The LiPo used is a 11V 1300MAh from Sparkfun that will power the RCB4 and the servos but not the gumstix and USB peripherals.

2) The KHR3HV's controller RCB4 has a JST connector linked to a switch and then to a bigger connector that links to the original NiMh battery. We modified the last connector replacing the big JST with the female counterpart of the Sparkfun LiPo output connector. (There was also a choice to modify the LiPo's output connector but we figured we wont be using the NiMh any longer once the LiPo is there).

3) the robot's switch + 2 connectors are then put back in their place such that one side is linked to the RCB4 inside the back-pack, and the other connector is tucked inside the internal cavity where the LiPo now resides. The LiPo's input charging connector can be tucked into that internal cavity aswel. it can be extracted when the robot needs to be recharged or when the battery needs to be replaced.

4) A second smaller 7V LiPo is fit into the KHR3V backpack. It will power the Gumstix and USB peripherals only. This way the big LiPo can last longer powering the servos (we hope). Later we have to fit in also a voltage regulator between the 7.3 LiPo and the Gumstix because it doesn't tolerate such high voltage.

<table><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr></table>