Work on the ROS/Blender robotics control pipeline has culminated in the integration of the system with the tiny robotic Einstein head that had been living at Polytechnic University under the watchful eye of the OpenCog group. Back at Hanson Robotics, tiny Einstein was mercilessly ripped apart and his head attached to an absurdly long robot snake neck apparatus that mimics the configuration of the upcoming “Dmitroid” robot system. Once suitably mutated, tiny Einstein was able to make a few statements and even sing a couple of tunes.
Progress continues as we use Blender to control ROS based Dynamixels. Now the jaw moves and the eyeballs are in. Soon we should be able to demonstrate targeting of the eyes to various kinds of objects.
All the motors start talking to Blender through ROS. Some interesting shaky behavior and a few issues with inverse kinematics are revealed.
We continue to make progress on the robot arm rig, connecting a Blender IK powered bone rig to dynamixel motors controlled through ROS.
The blend file is available at the Hanson Robotics GitHub site here:
Oracle has demonstrated that implementing an API is effectively the same as copying code from a program. To me, as a non-lawyer programmer, this surprising court decision seems to mutate copyrights into a kind of Software-Patent-Lite(tm) without the benefit of examiners or a 15 year term limit. This seems like a chilling new tool for deep pockets companies like Oracle to go about tormenting people. Thinking more deeply, however, you begin to wonder if Oracle hasn’t inadvertently created some kind of Free Software Doomsday weapon.
After all, if simply implementing an API makes you code a “derivative work” then doesn’t that mean the terms of the GPL will apply on any code that implements the API of a GPL’d system? Even if you didn’t copy code you have implemented that API and according to Oracle that’s a derived work. If you ask me, its the most excitingly vauge and contagious information phenomena since the Open Data Base License.
Take a sneak peek into the sophisticated engineering processes underway here at the Hanson Robotics Lab in sunny Hong Kong.
Ean Schuessler I guess it’s a little predictable that the “reimagination” is mostly “have the city buy more art”. Does that change things or turn art into even more of a game where artists chase after these political “gate keepers”? Artists need to take the manifestation of their dreams into their own hands.
Ean Schuessler Ok, I’m kidding… sort of. I absolutely agree with you about “localizing” the artistic culture but I do want to reiterate the “bozo effect” that Steve Jobs talked about. As soon as the state starts throwing money around you will see a sudden manifestation of people presenting themselves as artists who are also masterful at manipulating the social spheres around the political infrastructure. These people will probably crowd out the actual “artists” who have long been slaving away in poverty and obscurity to create their dreams. Frankly, I’m a big fan of “commercial art” where the artist selects a market and crafts a product that is aligned with what they are wanting to produce. Some see this as selling out but I see it as an engineering problem. If, as an artist, you want to produce product X then its simply a matter of figuring out how to reach audience Y that wants it. There is a question of pandering to audiences but you don’t have to do that. Its up to the artist who they pander to, that’s part of the self-expression process. The state only has to get involved for artists whose work can’t be supported by its target audience. In my opinion this should be reserved for “cultural preservation” kinds of artists who practice forms with a strong history that are less in fashion and are more about preserving traditions of craft.
Heed me, oh working class. Corporate America will replace any job they can with a robot. It is so.
How do my Republican associates square “a plan to close the gap” with simultaneous record corporate profits, record unemployment and an adversarial stance against raising the minimum wage?
My friend James Spargo recently sent me this article on feature branches by Martin Fowler in which he criticizes the “feature branching” approach to software development. In essence, feature branching endorses an approach where changes to a computer program are made in an isolated container (the “branch”) until they reach a certain level of readiness. Mr. Fowler believes, instead, that these changes should be folded in quickly so that the there is communication among the other participants in the project.
Mr Fowler is a smart man but at Brainfood we feel like our lives became less complicated and more productive with the adoption of feature branching. Our process up until then had classically been all of us pushing into a single branch and rarely keeping many branches around. The excellent and experienced staff at Eucalyptus Systems dragged us into using feature branches and we’ve stuck with it. Having experienced both approaches I’ll briefly outline what I see as the benefits to using feature branches.
Life puts you through big changes
Though Mr. Fowler prefers to steer clear of branches he does advocate the sensible policy that each commit should be “ready for production”. It isn’t clear to me how this is achievable for non-trivial refactorings. There are plenty of occasions where the changes a piece of code needs are small and can be written quickly and committed but certainly not all situations are like this. The treachery of multi-core programming can easily put you in a position where you need to rethink the way a whole group of components interact and those components may have mature and widely deployed interfaces. At the same time, the show must go on and you may have work that needs to happen immediately while a large complicated refactoring is in process. In a situation like this its hard to see how a “one branch to rule them all” approach is going to get the job done.
Protecting yourself from yourself
Another corollary of the single “always ready” branch model is that change streams probably end up staying on your desktop until they are ready. Mr. Fowler even advocates that “every commit should be ready for production”. To me this adds up to people keeping substantial chunks of work in the working directory of their desktop until they have everything working. This is a recipe for either losing a bunch of work or screwing up a bunch of useful work because you took a wrong turn halfway through. Computers break and people sometimes write bad code after working a long time. With feature branching you can push and push your changes into your own isolated branch without bothering anyone else in the project. If you take a wrong turn you will also have a series of snapshots so that you can roll the tape back to the point where you took a wrong turn.
If you work on multiple computers (home, work, laptop, etc.) pushing to branches in the team repo is also a convenient way to hand your own work between environments. You can definitely get there with a peer to peer approach but sometimes dealing with a single well connected host is easier than the VPNs and SSH proxies that may be required to get all your machines talking to each other. Sometimes, because of policy, it may not be possible at all.
Another beneficial side effect of feature branching is that your work in progress is encoded as a convenient artifact that can be passed around to other members of the team for review. In Mr. Fowler’s approach, the team finds out about your changes because they are literally stumbling across them. A formal review process doesn’t seem possible because the commits are frequent, fragmentary and continuous.
With feature branches it is a common practice for one or multiple members of the team to review your branch before it is committed. Since the changes occur in a branch there is the convenience that the work will be cleaned up and thought through before someone else has to grok it. There is more of a chance that the changes could be ill-conceived and have a lot of work in them since they occur in isolation. It seems like the cure to that problem, however, is to have other team members take a peek at your branch before you get too far along.
At some level, each time we begin typing we are potentially taking the whole team on some flight of fancy springing deep from within our mind. With feature branching the rest of the team joins that jaunt with a greater degree of complicity. When the changes are rolling into the master branch all the time you can complain but you will need to be very vigilant or you could find yourself along for the ride.
My final criticism of the CI all-in one-branch approach is that people inevitably make mistakes. I’m not talking about typos but about big conceptual miscues. In the “along for the ride” model you may find that your stream of useful changes is interleaved with some tragically misguided work and you failed to notice it because you were so focused on the task at hand. Your other team member may even realize it and be trying to unroll the changes. Unfortunately, the work is now tangled into your work and you may even depend on parts of their stuff that worked well enough for you to remain oblivious to the problems they discovered.
Certainly there is a danger to people sitting on their work with the feature branch approach. You do not want someone to carve of their own little playground and go on wild sprees of modification while the rest the project leaves them steadily behind. If you are pushing branches back to a central point, however, and tracking progress with a ticket system (we use Redmine Backlogs) then you have great management tools to fight these problems. It seems to me that with the single branch model you have intrinsic problems that can’t be fought through management tools. For us, at least, that has made feature branching seem the better model.