This page, updated every hour, aggregates blog entries by people who are writing about Fawkes.
Posted on November 16, 2010 at 5:22 PM by Tim Niemueller
On a related note Fawkes has been chosen by the Fedora Robotics SIG to play a major role in the Fedora Robotics Spin along with Player and Stage. The main idea of this spin is to have software on a LiveDVD providing a ready-to-use robotic simulation environment, with a demo application to introduce users step by step to the available software. Additionally as much robotics related software as possible, ranging from packages for hardware access (laser scanners, robotic arms) and robotic middleware frameworks, to full-blown simulation environments and libraries relevant for robotic applications like vision processing or task control will be added. The Robotics Spin has been proposed as a Fedora 15 Feature
For this LiveDVD Fawkes will be used in combination with Player and Stage to provide the environment for the demonstration application. In particular, the behavior engine based on Lua will be the tools used to guide the user to complete tasks of increasing complexity within the simulation environment. Among others like Player/Stage and the RoboCup 3D Soccer Server Fawkes will be one of the highlighted robot software packages.
Posted on August 17, 2010 at 6:05 AM by Tim Niemueller
Recently I have also been busy working on software for another robot software framework -- ROS. As part of my research stay with Dr. Siddharta Srinivasa from Intel Research Pittsburgh at the Carnegie Mellon University I have developed roslua, a ROS client library for Lua. This is only the first step in porting Fawkes' behavior engine to ROS. You can find the full announcement on the ROS website. So after "the discovery" I still can be kind of productive. More is cooking, stay tuned.
Posted on August 4, 2010 at 8:15 PM by Tim Niemueller
execl()the new program in the child, and have the parent call
wait()to check for state changes of children.
Now, in I'd guess likewise common is to start with a test program that incorporates sleep(). Fail! After an hour it turns out that the sleep() call will block the
SIGCHLDsignal (cf. sleep.c). But it does not unblock the signal afterwards. Since the
wait()call depends on
SIGCHLD, no event would be received
So either you need to unblock the signal after calling
sleep(), or better call
usleep()which does not suffer this problem (cf. usleep.c).
Posted on February 20, 2010 at 11:59 AM by Tim Niemueller
git config branch.topicbr.remote origin git config branch.topicbr.merge refs/heads/timn/topicbr.
It's that easy and now I have a place to look it up next time I need it...
Posted on February 6, 2010 at 9:18 AM by Tim Niemueller
Currently there is a talk about the Nao motion module. Besides that I'm setting up the OpenEmbedded tool chain, again.
Posted on September 7, 2009 at 12:03 AM by Tim Niemueller
The last time I developed for Maemo I had setup a 32bit virtual machine with Fedora to run the development environment. But this is clumsy at best. It consumes a lot of extra resources (especially RAM) and the virtual environment cannot do my native full resolution. This time I wanted to try the SDK for the new Maemo version and installed it natively on my x86_64 Fedora installation, which works just fine. Here are some notes that might be helpful if you want to do the same. The notes are for the Maemo 5 SDK, Beta 2.
You need the basic 32bit libraries to install the environment. I didn't run into anything that was missing, so I guess a basic 32bit environment is sufficient.
There is a very good installation manual for the SDK. First download the scratchbox and sdk installer scripts referenced in the manual. To install on x86_64, you need to make two changes. First you need to add the kernel parameter
vdso32=0by adding it to the lines beginning with "kernel" in /etc/grub.conf. For this to take effect you need to reboot (before you start the installation). Secondly you need to enable the "force" mode without enabling .deb installation. This is only possible by adding the script. For this add "__force=yes" around line 311 (where the s parameter is handled). The section should afterwards look like this:
s) __type=tgz __force=yes __scratchbox=$OPTARG ;;Now you are ready to install scratchbox. For this execute the scratchbox install script as root like this
sh maemo-scratchbox-install_5.0beta2.sh -s /opt/maemo-sdk-5b2/scratchbox -u timand follow the instructions on the screen. This will install the SDK to /opt/maemo-sdk-5b2/scratchbox and add the user tim to the allowed users. This must be your user name on the Fedora system. Then execute the SDK installer not as root, but as normal user and follow the instructions. There was nothing special I had to do, just do
sh maemo-sdk-install_5.0beta2.sh -s /opt/maemo-sdk-5b2/scratchboxNow Maemo is installed and after one slight installation and/or fix you are ready to go. The current version of Xephyr in Fedora is broken. It was only in version 1.6.3 where patches have been applied that fix segfaults when pressing keys. This version is available in the updates-testing repository. I did not experience any problems, your mileage may vary. To update the package do
yum --enablerepo=updates-testing update xorg-x11-server-Xephyrreplace update with install. I have actually updated all xorg-x11-server* packages. I'm not sure if this is necessary. Works fine for me so far.
You might want to read Thomas Thurman's tutorial series about developing for the N900.
You can install the Maemo 4 SDK similarly. In the scratchbox install script uncomment the "exit 1" line by prefixing it with a hash (#) to eliminate the i386 check. You need the same vdso32 parameter and the updated Xephyr. I recommend choosing different directories for the two SDKs, as they use different versions of scratchbox.
Posted on August 14, 2009 at 2:42 PM by Tim Niemueller
Currently Fawkes works on Linux and FreeBSD. If you want to run it on Linux I recommend using Fedora, as it provides all the required software packages out of the box. You can find a yum command to get 'em all on the FawkesOnFedora wiki page. The next milestone will be to add support for system-wide installation. That will allow us to provide package repositories for even simpler installation. Currently Fawkes is build and used in a self-contained tree, which is a very flexible and easy setup to start developing for the robot without special privileges (cf. DeveloperGettingStartedGuide)
At that point we can then use the software to build an easy to use simulation environment for example for the planned Fedora Robotics LiveCD, integrating Fawkes with the Player/Stage/Gazebo simulation environment and providing the Fawkes Lua scripting facility to make the robot operate in the simulation! It's still a way, but today we made a huge step towards this goal. Now is also the time to revive the Fedora Robotics SIG, which hasn't been active for the last couple of months due to people being busy with other stuff.
Posted on July 24, 2009 at 7:57 PM by Tim Niemueller
Lately Bjarne Stroustroup wrote an article about the decision to remove Concepts from C++0x. And from what I've read it seems we shouldn't be too sorry about the removal. There is still a lot of new stuff that one can get excited about and that should make our live easier. It'll be more likely C++1x now as he states.
However, I wonder when we will see enough coverage in the features and when all target platforms and systems have been upgraded so that you can actually use those features... We are still using Fedora Core 6 machines regularly (due to missing propietary driver updates). Also for the Nao currently GCC 4.2 is used, as is on FreeBSD 7.2. So we'll have some time...
Posted on July 18, 2009 at 1:51 AM by Tim Niemueller
I have put a lot of effort in the past months into our (AllemaniACs RoboCup Team) robot software framework called Fawkes. It provides the basic infrastructure and utilities required to write robotic software and applications. I happen to be the architect and main developer of Fawkes, with help of several fantastic people that have put code and ideas into the project. Fawkes is based on experiences we made with our former software framework RCSoft. It had shown it's age back in 2006 and basically was our "one to throw away". Currently I'm preparing all the infrastructure around the project (website, public source code repository etc.) for a public release as Open Source software - finally. This was always in my mind and for each line of code we copied from RCSoft I contacted the old authors if the files were missing a license header, now we have a fully GPL'ed package. Stay tuned, it's just a matter of days now.
There were two RoboCup events that I didn't blog about - but we've been there! First was the RoboCup German Open 2009 in Hannover. There we participated with our still-somewhat-new mid-size robots and with the Nao humanoid robots in the Standard Platform League (SPL). In the latter we participated as team ZaDeAt consisting of members from the University of Cape Town, South Africa, us at the RWTH Aachen University, Germany and from Technical University of Graz, Austria (there for ZaDeAt, ISO country codes). It was a pretty experimental event. Last year the Naos were merely able to keep standing and walk a little, this year we saw some real game play. Because a few software components were missing, we couldn't play up to the level we had imagined and dropped out already after the first round robin. But I could do some last evaluation of the behavior engine and agent program I wrote for my thesis, and of course the port of the software to the Nao robot. So personally this event returned what I needed. I also did a lot of refereeing, including the final which was won by the B-Humans from Bremen. For the mid-size league this was the first real field test. We couldn't do a lot of testing back at home, because we did not have a suitable environment. Getting enough space in the university is tough, so the best we could get was less than half the size of a robot soccer field. Then we had to buy a special "flame resistant" carpet (because the location happened to be the main entrance lobby). Unfortunately this one was so soft and thick that the friction was so high that the robots could barely move and the motors were overheating quickly when they moved. So in Hannover we were mostly busy doing live integration experiments and trying to get the robots running, somehow. But at least they could move on the tournament carpet. The lighting conditions were pretty bad in the exhibition hall were the games took place. Therefore many teams had problems with the vision (especially in the SPL), which included us. In one of the Nao games we literally sent one of the team members outside to check the weather. Depending on the state of clouds and sunshine we had to decide for a particular color calibration...
RoboCup 2009 in Graz was also fun, besides the cold I acquired on the very first day... We drove there by car in about 11h. After we arrived we found out that on Sunday nights all restaurants are already closed (in Graz) and that even with rain jacket you can get damn wet. We participated in the RoboCup@Home league and with the Naos again. Due to missing commitment and focus by the Nao team in the time around the Hannover event I pulled out of much of the Nao development work (although this has been a major part of my thesis) and concentrated on the @Home competition as part of the AllemaniACs team. We are kind of a tournament team, meaning that we tend to do much of the required work and final testing during the event. It's an awesome team with brilliant people and on those occasions we close ranks and work hard and get a lot of stuff done. RoboCup events are basically our development sprints. So in Graz we got to note the time we missed in Hannover (where we did not participate in the @Home league, because we did not have enough people for three leagues and it was the mid-size department's turn). But we anticipated this problem and decided to use this event to retire parts of the old RCSoft in favor of Fawkes. Thanks to the AllemaniACs for pushing Fawkes with this event. It helped a lot and showed what the software is able to achieve. The month before the event I spent my time writing communication plugins to share data between multiple instances (the @Home robots have two or three computers, while the robots up to now always had only one) and with the old software framework (we have too much software in the old framework to port it all at once). Additionally I wrote several plugins and additions for access to basic hardware, writing (Lua) scripts to make them accessible in the behavior engine, calibration tools and a lot of stuff that I discovered to be missing during the integration of all this. We also developed a pan-tilt unit to move the camera on the top of the robot literally in the two weeks before RoboCup. Masrur wrote a new leg tracker that detects and tracks humans via the laser range finder. Worked nicely, after a few days and nights of on-site hacking :-)
During the event it went pretty well. Of course we had our problems and discovered bugs that required fixing. But we had some interesting runs (find details on the AllemaniACs' page) and in the end became 6th out of 18 teams. We had a fair chance to get into the finals (last 5), but in the end three bugs (spreaded over both software systems) cascaded into failing the PartyBot test, leaving us with about 500 points (out of 2000 you can achieve in this test) missing. But I think we did it again and showed something truely new: two fully autonomous robots that communicate with each other to solve a task cooperatively in the home environment. There were several teams with a second robot, but none had two full-fledged robots interacting with each other in the arena. Closest come the Homer from Koblenz, where the main robot remotely controls a Roomba. The tests did not go absolutely smoothly, but the robots showed interaction and tried to do their job. Better next time... For Fedora Planet readers it might be interesting to note that both robots were running Fedora, one FC3 and the other FC6 and F-10. Yeah, I know these are very old versions, but we used FC6 due to some drivers not available for newer versions and FC3 is on the secondary robot, we screwed together (again) the week before the event, and I compiled the required packages etc. on-site. So there was just no time to upgrade.
On a related note I presented a poster for our paper about a "A Lua-based Behavior Engine for Controlling the Humanoid Robot Nao", which describes a environment to write small robot behavior entities called skills, which are modeled as hybrid state machines, can be hierarchically structured and are exposed as simple functions to the higher level control program (i.e. agent).
Besides all the exciting stuff I have also moved this very server the page is served from. It used to be a Pentium III rack server with Red Hat Linux 7.3 (pimped with some self-made update packages) provided generously by a company I worked with. Thanks guys! Now this runs CentOS 5.3 in a Xen virtual machine on another CentOS. And since I wrote my own stuff to manage the website early this decade it was quite a shock for this creepy code to go from an old PHP 4.1 to 5.2. I just fixed the application today to be able to blog again. For the Fawkes website I'm experimenting with Django and I like it. Maybe when I find some time I'm going to port my website as well. But first let's see if I manage to update this blog more often...
This picture shows all RoboCup@Home robot from this year's competition. All photos in this entry were taken by Masrur Doostdar of the AllemaniACs.