I am officially the wiz at I-O for the Aperios Operating System.Â I’ve just completed most of the internal work to make various OPEN-R objects (our modules–Vision, Motion, Communication) talk to each other in exactly the way I want them to–which is good!Â The motion system now tells the Vision module (and our Brain) the current state of the motion system and the current joint values every frame. This is a basic building block for better and better behaviors.
I’m in here late on a Saturday, cursing the OPEN-R SDK and its inter-objectivity, and trying to make life for our team a lot simple: One object. One object to rule them all. It’s a risk in one way: things could run slower, compilation time could take longer, and I might not even be able to make it work. I’ve gotten one module into the one-module framework. Now it’s time for the second.
UPDATE::Brought in the Chlaos, our motion module. Boots up, and even stands up. AiboConnect works, but not for motions yet. Promising…
UPDATEx2::Motions are wickedly choppy. Bleak.
UPDATEx3::Motions work fine if I don’t initialize sensors/image. Time to work it out. —Works when initializing Sensors, now
UPDATEx4::Seems like a Memory Management issue. Turning off some of the initializing malloc’s–big image arrays–speed things up considerably.
Ported over AiboConnect into the new architecture. Instead of its own Aperios Object, it’s merely a c++ file within the vision module. Check here for a nifty camera shot from the dog’s nose. Update:: Motions work too. This is really cool: all the pieces are coming together.
Architecture is really a tough call now. I need to pick an overall design of Aperios Objects (modules) and keep it stable until the end of the year. I’m probably going to have one for vision (plus Python hooks), motion, and communication. And how to link various bits of code for each module? Common header files? Namespaces? Heck–I could do like UPenn and just have one Aperios object for everything.