Let's Make Robots!

MRL - 3D Point Cloud

Put the video up - now got to join the points into a mesh - turn the mesh into a continuous space polygon which will wrap all possible space to move in - and use LKOptical tracking to anchor it to the "real world" ... then we'd be slamm'n

Hi LMRians.  Just thought I might show you the latest software I'm working on in MRL .

Zoomed


HSV depth version

This is a new OpenNI Service in MRL - thanks to DancesWithRobots .  Currently, I'm getting it to do a high density point cloud visualization.  The results are displayed (realtime) in a Java3D view pane.  Here's my office floor & door.  I've several more features to work on (HSV color coding to depth, RGB image overlay, scaling, density control, sharing data with OpenCV, etc) before making a (the holy grail) SLAM service. Yay !  (good little elves habe been busy)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
It looks like you've done a lot of the work for me on my current project. If I can get Java up and running on my Beagleboard then MRL will do the heavy lifting for me when it comes to programming/integration. Is there direct access to the ARM GPIOs from MRL or is the hardware interface more specifically integrated?

MRL is service based, so it depends on what service your running.  If your ARM processor supports sockets and has a TCP/IP stack - the RemoteAdapter will run.  You can get a list of some of the services here - http://myrobotlab.org/services .

MRL & Java can speak directly to the hardware with a JNA or JNI bridge, however, I believe with an ARM GPIO it is even more simple - it appears it might be simple file access which would not require the bridge.

Golly, I just found out my newly arrived Rasberry Pi has a several GPIOs !  I'll be checking that out.  

Most likely it would mean creating a new Service whos function is controlling the pins, hopefully the one I create for the Rasberry Pi would work for the Beagle Board. 

The important thing is, MRL is service based, there can be general services like GPIOControl or possibly (if needed) BeagleBoard service.  

I hope you have better luck with your RaspPi than Merser did.  Or was it MarkusB...?  There are too many guys using too many SBCs these days! ;-)

Looks good...  
What state is it all in?  Have you booted it?  Logged in?  Is Java really already on it ?  I had to load a JVM on the Chumby's BusyBox OS manually. How do you currently interface with it via serial line, or network ssh ?

Its got 1 usb port - I take it your going to put a hub on it to get wifi & webcam ?

... working on a custom kernel and userspace ... I got no problem getting whatever needed on it ;)

I have both ssh and serial working on it ... and yes a powered usb 2.0 hub is needed to drive the webcam and wireless at the same time.

The only thing is that Java is not one of my strong points so I might have to bug you on that.

So you type in "java" and you get ... Usage: java [-options] class [args...] ?
I'm not familiar with the optimized ARM5 java - I wonder if its based on JamVM, not that it matters too much.

If it was me, I'd probably start in this order :

1. get the latest greatest - Here is my secret continuous integration server, churning away in a hidden recess of the salt mines - http://myrobotlab.dyndns.org:8080/  - lastest (bleeding edge) builds can be found here http://myrobotlab.dyndns.org:8080/job/myrobotlab/ws/myrobotlab/dist/ -  pick your poison - the just "download files as zip"

2. unzip it on the board - if you have room - the default package comes with python, which is pretty big (10 Megs) - dunno how much space you have. - If you want Python, but dont have the space for it you can run the Python remotely and have it control the bot.. lots of options

3. There's a myrobotlab.sh script - for ease of use, but catered to people who have gui's & swing...  You want it probably without the GUI, instead of this:

java -classpath "./libraries/jar/*" -Djava.library.path="./libraries/native/x86.32.linux:./libraries/native/x86.64.linux:./libraries/native/x86.32.mac" org.myrobotlab.service.Runtime -service gui GUIService jython Jython 

do this

java -classpath "./libraries/jar/*" -Djava.library.path="./libraries/native/x86.32.linux:./libraries/native/x86.64.linux:./libraries/native/x86.32.mac" org.myrobotlab.service.Runtime -service mylittlebot Runtime 

-service controls which services you want to bring up - each service requires a unique name "mylittlebot" in this case.  If that works, we'll move on to the RemoteAdapter service...

 

.. Jazzele and it looks like openJDK can use this hardware part to execute bytecode.

java -classpath "./libraries/jar/*" -Djava.library.path="./libraries/native/x86.32.linux:./libraries/native/x86.64.linux:./libraries/native/x86.32.mac" org.myrobotlab.service.Runtime -service mylittlebot Runtime 

The above will probably not work there is no x86.32 or 64 on arm :)

In order to support interactions between real hardware and Java a native library is used.  I'm trying to organize this by creating a repo which MRL can fetch the correct bridge.  The repo is checked into the code.google - here -> http://code.google.com/p/myrobotlab/source/browse/#svn%2Ftrunk%2Fmyrobotlab%2FthirdParty%2Frepo

MRL uses Ivy to fetch the appropriate bridge.  Ivy is like maven or you could say its like apt-get or yum....

At the moment I have these platform definitions - 

  • x86.32.linux
  • x86.64.linux
  • x86.32.windows
  • x86.64.windows
  • x86.32.mac
  • x86.64.mac <- coming
  • arm.32.linux

Your right -  on your board you probably want the start script to look like this 

java -classpath "./libraries/jar/*" -Djava.library.path="./libraries/native/arm.32.linux" org.myrobotlab.service.Runtime -service mylittlebot Runtime   

if it supports sockets you can start both the runtime & remote adapter in one call like this

ava -classpath "./libraries/jar/*" -Djava.library.path="./libraries/native/arm.32.linux" org.myrobotlab.service.Runtime -service mylittlebot Runtime  remote RemoteAdapter

by default it listens on port 6767 - it can talk UDP or TCP - the protocol spoken is MRL so another MRL instance could connect and understand it. 

... and get back to you if trouble happens.

So far I still need to peel blue stuff from  lots of little track connectors.

Ya... I broke out for a while..

I've gotten MRL to run on a Chumby - I think that was 533Mhz Arm with 64Megs - I've also run it on my Phone which has a bit more "oomphff" than the Chumby.

The way MRL is designed you can load just the services your interested in, so a webcam streamer & remote control I think would be well within the realm of possibilities.

What does "Linux Board" mean ?   "Rasberry Pi" ?  Also, if you can give me details on the hardware, e.g. is some Arduino clone in the mix, I can probably be of more use..   Almost every service in MRL can be headless (exception is the GUIService .. duh), also instances can connect and pool resources .. kindof like a peer to peer network.  When you say remote control, where is your control coming from?  Desktop, laptop, phone, all?