Platforms


This is a matrix of platform information and their support.  One wonderful qualities of Java is its portability.  However, interfacing directly to hardware or using C/C++ libraries we need to build native JNI shims.
This matrix should help identify what is needed.

Computer  Processor   Operating System  MRLian MRL Repo IDs Description
PC Intel / AMD Windows   x86.32.windows
x86.64.windows
 
Mac Intel Mac   x86.64.mac  
PC Intel / AMD Linux   x86.32.linux
x86.64.linux
 
Raspberry Pi ARM11 family, ARMv6 instruction set Debian/Wheezy
Hard floating point support
  armv6.hfp.32.linux This will need to change as
arm the arm risc processor has a variety
of versions / instruction sets which are incompatible with each other.
Armv6 is the important part for the software as it is the instruction set version (this is set as a compiler flag)
Here is the best explanation in gory detail I have seen.
Odroid Arm Cortex A-8    
armv7.sfp.32.linux
 
Odroid U3  

Xubuntu 13.10
Linux odroid 3.8.13.16 #1 SMP PREEMPT Tue Feb 11 10:47:21 BRST 2014 armv7l armv7l armv7l GNU/Linux

apt-get install libtbb-dev qt4-dev-tools libqt4-dev libqt4-core libqt4-gui

Alessandruino  armv7.hfp.32.linux
albiet
 
Beagle Board Black Arm Cortex A-8     armv7.sfp.32.linux  
MK808 Arm Coretex A-9     armv7.sfp.32.linux  

Added hfp & sfp - hard floating point & soft floating point

References


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
DancesWithRobots's picture

Ok. . .for us shaved apes. . .

I've commited myself to an Arm device, mostly because of it's small size and simple voltage requirements.

The way I see it, the RasPi, in spite of its relatively poor performance is a no-brainer for robot projects because hacking is what it was made for.  I don't know much about the Beagle Bone Black, but I see it uses the same processor as my device of choice--the Odroid, which I've barely got working, but, DJUltis has been having some success with.

My point to all this--what does it say about the MRL roadmap?  Small powerful processors are just the sort of thing we need in todays sophisticated hobby robots, and I'm pleased to see that you hope to support them.  But I've seen MRL struggle with what my tiny brain percieves as simple things.  (Serial programming?)  What's it going to be like getting MRL to run across a set of processors that can barely agree on an instruction set?

I'm wrapping up end of semester projects right now, I've got a stack of capable hardware, and--dare I say it--my 3d printer might just ship within a few weeks.  (I know I said that a year ago.)  Where do you think MRL will be in a few months?  GroG is the guiding light, and DJUltis is the pioneer, (That is, the guy with the Odroid arrows in his back) that I can follow to get me to this dream I've been chasing for decades.

GroG's picture

EVOLUTION !!! :D

Yes - I agree with RasPis (otherwise I wouldn't be spending time trying to support them).  And if you think about it, the trend will only continue.  

The trend being, higher performance processors on smaller single board computers..

As to the complexity ?  90% of MRL is Java... the complexity comes from the 10% native code interfaces which directly interact with the computers hardware.  Whenever a services uses native code, it makes it 6 to 8 times more complex (building for 6 to 8 different platforms)....  

Im fact, this has been the thorn in the side or MRL .. specificially Serial & the RXTXLib project (some of the issue stems from the fact it is a dead project and it has this same order of complexity)

The code out there is evolving too.  There are now "pure Java" solutions for computer vision.  This (found by Alessandruino) - looks extremely promising - http://www.openimaj.org/ and it holds true to the, "write once run everywhere" Java mantra...  Other projects are becoming more mature, for example OpenNI doesn't seem "quite" as chaotic as when we got it to work :D

RACE BOLDLY AHEAD !!! - Arm processors seem like a logical step for MRL ... all pure Java code should work on them already..   When / If we have to deal with complexity, we have a repo system which will work as long as we consistently and correctly identify the unique system during runtime...

For example it appears we can get details on the instruction set from /proc/cpuinfo

Here is my RasPi

pi@raspberrypi ~ $ cat /proc/cpuinfo
Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7
 
Hardware        : BCM2708
Revision        : 0002
Serial          : 000000004b09b3b4
 
beetlejuice's picture

Here is my bananaPi

Here is my bananaPi :

bananapi@lemaker ~ $ cat /proc/cpuinfo
Processor    : ARMv7 Processor rev 4 (v7l)
processor    : 0
BogoMIPS    : 1431.55

processor    : 1
BogoMIPS    : 1436.46

Features    : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x0
CPU part    : 0xc07
CPU revision    : 4

Hardware    : sun7i
Revision    : 0000
Serial        : 03430b81525148488048568616516646

 

More info : http://www.bananapi.org/p/product.html