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||
|PC||Intel / AMD||Linux||
|Raspberry Pi||ARM11 family, ARMv6 instruction set||
Hard floating point support
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||
apt-get install libtbb-dev qt4-dev-tools libqt4-dev libqt4-core libqt4-gui
|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
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.
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
Here is my bananaPi
Here is my bananaPi :
More info : http://www.bananapi.org/p/product.html