Hey all! I'm one of the maintainers of IHMCRealtime, so if you have any questions then fire away. Kind of an odd submission for HN but maybe one or two people out there might be interested in this.
The motivation for this library isn't really clarified in the README because it's a little out of scope, but if you aren't familiar with us we're the robotics research arm of the Florida Institute for Human and Machine Cognition[1]. We specialize in force-control based walking algorithms, which require near-hard real-time computation during dynamic balancing (for example, when only one leg is on the ground during walking). We've been using this library in "production" for around a year to control Atlas for the DARPA Robotics Challenge (we came in 1st during the Virtual Challenge and came in 2nd place to SCHAFT/Google at the Trials in Miami last December). Out of the 8 Atlas teams, we were one of only two teams to use our own control software instead of the provided Boston Dynamics libraries, and out of those two we were the only team to use our control software for every task instead of a subset. So we feel pretty confident about the real-time capabilities of the library.
Java is a bit of an oddity in the robotics community, but we've been using it for over 10 years in our lab. One of the huge benefits is how easy it is to learn for people without a CS background, like Mech.E PhD's who've only ever programmed in MATLAB; strong IDE selections, readability, reasonable type checking, etc. are all huge gains for us. Lots of people who work for us are temporary hires (visiting researchers, interns, etc.) so being able to climb the learning curve in a week or two is a huge plus. We previously used Sun's real-time Java implementation, but it stalled out at the 1.5 language spec. We investigated commercial off-the-shelf solutions like WebSphere, Perc, JamaicaVM/Jamaica Builder, but all of them suffered pretty severely on tight-loop numeric computation. So we decided to bolt bare-minimum real-time on to OpenJDK.
We just submitted a paper to the JTRES[2] conference describing how we achieve real-time control using OpenJDK in more detail, let me know if you're interested in reading it and I can try to get you a copy.
Can your CPU affinity wrappers be used with plain old java threads? Or does it only work with your realtime threads? I briefly inspected Affinity.java and it looks like it just takes the OS's thread ID so this may be fairly straightforward. Have you tried this?
The threadID used in the affinity wrapper maps to the address of a C++ object, so unfortunately no.
To be more clear, it operates directly on pthreads under the hood, so if you had some way of grabbing the pthread information from a Java thread (this would obviously only work on Linux) you could maybe finagle it, but we haven't been interested in doing that. Our thread API is very similar to the Java Thread API, though, so it shouldn't be too tough to find a way to do what you want.
EDIT: I may have been wrong about this, Jesper (the main author) says it should work out of the box, I think he's chiming in himself.
Setting the thread affinity of the current thread should be possible using the Affinity.setAffinity(int... cpuID) call. Underneath, it calls sched_settaffinity(0, sizeof(set), &set); I'm not sure if this set the affinity of the whole process or just the thread. I suspect it is the calling thread. Let us know if you happen to find that out.
Parsing the CPU layout of the machine you're running does not depend on any realtimethread code, and should work on any modern linux system.
Very interesting project. I'm one of those rare people on HN who actually did a graduate degree in the area of bipedal locomotion so I'm well aware of IHMC and the research coming out of this lab. Great work!
9 comments
[ 3.1 ms ] story [ 32.2 ms ] threadThe motivation for this library isn't really clarified in the README because it's a little out of scope, but if you aren't familiar with us we're the robotics research arm of the Florida Institute for Human and Machine Cognition[1]. We specialize in force-control based walking algorithms, which require near-hard real-time computation during dynamic balancing (for example, when only one leg is on the ground during walking). We've been using this library in "production" for around a year to control Atlas for the DARPA Robotics Challenge (we came in 1st during the Virtual Challenge and came in 2nd place to SCHAFT/Google at the Trials in Miami last December). Out of the 8 Atlas teams, we were one of only two teams to use our own control software instead of the provided Boston Dynamics libraries, and out of those two we were the only team to use our control software for every task instead of a subset. So we feel pretty confident about the real-time capabilities of the library.
Java is a bit of an oddity in the robotics community, but we've been using it for over 10 years in our lab. One of the huge benefits is how easy it is to learn for people without a CS background, like Mech.E PhD's who've only ever programmed in MATLAB; strong IDE selections, readability, reasonable type checking, etc. are all huge gains for us. Lots of people who work for us are temporary hires (visiting researchers, interns, etc.) so being able to climb the learning curve in a week or two is a huge plus. We previously used Sun's real-time Java implementation, but it stalled out at the 1.5 language spec. We investigated commercial off-the-shelf solutions like WebSphere, Perc, JamaicaVM/Jamaica Builder, but all of them suffered pretty severely on tight-loop numeric computation. So we decided to bolt bare-minimum real-time on to OpenJDK.
We just submitted a paper to the JTRES[2] conference describing how we achieve real-time control using OpenJDK in more detail, let me know if you're interested in reading it and I can try to get you a copy.
[1]: http://robots.ihmc.us
[2]: http://jtres2014.compute.dtu.dk/index.html
A clear link to documentation on the bitbucket page would be helpful.
To be more clear, it operates directly on pthreads under the hood, so if you had some way of grabbing the pthread information from a Java thread (this would obviously only work on Linux) you could maybe finagle it, but we haven't been interested in doing that. Our thread API is very similar to the Java Thread API, though, so it shouldn't be too tough to find a way to do what you want.
EDIT: I may have been wrong about this, Jesper (the main author) says it should work out of the box, I think he's chiming in himself.
Setting the thread affinity of the current thread should be possible using the Affinity.setAffinity(int... cpuID) call. Underneath, it calls sched_settaffinity(0, sizeof(set), &set); I'm not sure if this set the affinity of the whole process or just the thread. I suspect it is the calling thread. Let us know if you happen to find that out.
Parsing the CPU layout of the machine you're running does not depend on any realtimethread code, and should work on any modern linux system.