Author Archives: paul

Resistance to Odometry is futile

It sure is. But a good odometry in a robotic context is an objective that is hard to achieve.  For a robot like the aMoSeRo only two main velocities are relevant: linear and angular speed. Both do not occur on the same time, but still – correctly determining any of them is essential as most higher algorithms like slamming and planning highly depend on it. For me in a out of time running thesis, this task can be the biggest still kinda opened challenge.

All other system parts like gmapping, robot_pose_ekf, tf_broadcasts, sensor code, drivers, dynamic_reconfigure (insert long list of other important things here) are up and well enough running. Most of the thesis is written, only evaluation (experiments) and conclusion (the big round up in the end) is still missing.

Therefore I am really looking forward to a time after my thesis – full of well deserved sleep and a university degree 🙂

Screenshot24.09.2014

LaTeX borders around hyperref links and references

As I am currently writing my thesis and stumbled around the problem of borders around any reference (or link) inside the generated .pdf document, I first came around with an solution like that:

usepackage{hyperref}
hypersetup{
  colorlinks=false,
  allbordercolors=white
}

Which worked by setting all borders of hyperref to the color of white and therefore on a white document to an invisible color.

But later on, especially when programmatically writing tree graphs with background colors, this solution didn’t work anymore.

Which is why I needed to change the way of usage to:

usepackage[hidelinks]{hyperref}

instead of the previous block. Now there is no disturbing border anymore and teXing got a little better 🙂

 

asd

thesis writing intermediate state

It has been really quiet in this blog recently. This is because I am currently writing my thesis in latex. Therefore I thought today is a good moment to tell you about some things i learned since the last post.

I have been putting lots of effort into the history of mobile robotics, have been researching some sources and achieved some knowledge about the recent development of Willow Garage, Boston Dynamics and some universities like the TU-Darmstadt.

hence I now distinguish between mobile robots, UGVs and AGVs, consider Willow Garage as possibly dead (even if it isn’t since the majority of employees moved in February) and feel deep respect of whats possible with legged robots shown by Boston Dynamics.

Time is running, it’s scary and spectacular at the same time regarding what is possible with mobile robots. My first 10k of words have been written and there is sill a lot more to be done until the 29th of September 2014.

TurtleBot Inventors Interview

Today I have found a very nice interview of Tully Foote and Melonee Wise on IEEE. I think it is a must read for everybody interested in low-cost mobile ROS robots.

Its amazing to read the thoughts they had while inventing the TurtleBot: Lower the entry barrier into ROS and keeping low cost for educational reasons. The same thing I try to achieve with my thesis and the aMoSeRo 🙂

Most of the time they speak right into my heart, the only thing I would disagree was this:

Melonee: I believe that the thing that robotics needs most is people who know how to program robots, and not as much people who focus on building robots. I’d like to see that shift in robotics competitions in general, where it’s more about what the robot is doing, as opposed to how it’s built. 

I’ve met a lot of engineers that are capable of building robots,but clearly underestimate the heavy lifting done by the computer science part – but also otherwise, some computer scientists do not have a single clue on how to move a real world motor by the power of code – someone needs to build a stable bridge between engineering and computing, and this is a person at least understanding both worlds or better mastering them, because as she also said:

Melonee: Because building robots is hard!

 

ROS – [rosout-1] process has died, exit code -11

Some days ago I started roscore and got faced with an error message like that:

process[rosout-1]: started with pid [16089]
[rosout-1] process has died [pid 16089, exit code -11, cmd /opt/ros/indigo/lib/rosout/rosout __name:=rosout __log:=/home/rosuser/.ros/log/9b3b3980-0b60-11e4-80f9-0015afdb2ab9/rosout-1.log].
log file: /home/rosuser/.ros/log/9b3b3980-0b60-11e4-80f9-0015afdb2ab9/rosout-1*.log

Okay, so roscore seemed to have crashed and created a log file according to the given path. But the logfile was empty *please imagine dramatic sound effects here*. But what do you do, if a programm (rosout?) crashes without log file and an error message like the above?

You insert your well done system wide backups like snapshots from zfs,btrfs, virtual machines, lvm or anything. If you forgot to do so… *fail sound here* you might need to manually check what changed since the last time it worked.

And so I did. For several days.

I soon figured out, that this error applied to all rosccp related ROS-programms – but left all rospy parts alive, which finally put my on track that there has been an kernel update of my ubuntu 14.04, which I unfortunately installed in a moment of weak decisions.
So reverting that would have been been an option, further my lib-boost version seemed to have changed – since ROS is very sensible to that, this might have been the problem. Therefore I tried everything by manually reverting updates, reinstalling packages, recompile everything from source, searching system logs and soon really considered to reset my system by installing good old 13.04 with ROS hydro…

But wait! Sometimes you strike lucky and time solves all issues. Today I’ve just upgraded my ROS from their repos and tadaaa – everything works again.

But why do I write this into an post? Because its easy to avoid situations like that and I want to share my hard learned lessons with you the easy way:

  1. Get your ROS version straight – Do you really need the latest ROS on the latest kernel?
    The answer for your system is probably no. I am currently running stable ROS Hydro and ‘unstable’ ROS Indigo on Ubuntu 14.04 on latest kernel. It works – but it would have been way easier to stick on Hydro all the way.
  2. avoid apt-get dist-upgrade on critical ROS machines
  3. use backups and / or virtual machines
  4. rospy didn’t cause any problems so far – in case performance isn’t the most important thing, think about using python
  5. avoid to put all your catkin_ws code into one git repository  if its running on multiple architectures (x86,x64, arm6,arm7) – alone the openni2_driver took nearly all my sanity during learning that lesson….

That is enough for today, but after this list, I really think about tracking all hard learned lessons in more public and better organised location – ROS best practices? We’ll see.

 

 

aMoSeRo – leaving the virtual cookie box

It is only consequent to leave the virtual cookie box too:

aMoSeRo – leaving the cookie box

Finding a low cost case isn’t as easy as expected – even with some common dimensions around 200mm*200mm*50mm the only inexpensive thing I found, was an star wars cookie box made out of thin plate.

So to change that I went to a DIY-Store today (or Baumarkt in german) and bought a 2 meters aluminium mopboard, some metal glue, acrylic glass and went to the basement:

But after cleaning the gluey mess off the table with spiritus, taking a well deserved shower and waiting 24 hours for the glue to get its full power the result is something able to be shown:

It’s a bit bigger than before but provides the basic functions in only 40 mm height. So we’ve got a real mobile plattform (base_footprint) for all upcoming modules (i.g. mesh networks, robot arms, flying drones or sensors like Geiger-Müller counters).

We’ve reached half time! Lets see whats still possible 🙂

aMoSeRo at Dresdner Berufsorientierungstage

For multiple reasons the TU Bergakademie Freiberg took part in the Dresdner Berufsorientierungstage at the day of mathematics on the 15th of July 2014.

I had the honor to take part on demonstrate the aMoSeRo to hundrets of children. Next to it we showed some two dancing NAOs and the LeapMotion – all to explain the need of mathematics and informatics for future applications.

Some impressions:

show apt-get history in Ubuntu / Debian

Sometimes you need some information about your apt-get install / upgrade / remove history. (for example if you destroyed your ROS-Install on your laptop).

By adding a little code snippet to your .bashrc you achieve a very useful tool.

function apt-history(){
      case "$1" in
        install)
              cat /var/log/dpkg.log | grep 'install '
              ;;
        upgrade|remove)
              cat /var/log/dpkg.log | grep $1
              ;;
        rollback)
              cat /var/log/dpkg.log | grep upgrade | 
                  grep "$2" -A10000000 | 
                  grep "$3" -B10000000 | 
                  awk '{print $4"="$5}'
              ;;
        *)
              cat /var/log/dpkg.log
              ;;
      esac
}

Now running

apt-history install
[...]
2014-07-14 19:08:13 install ros-indigo-desktop-full:i386 <none> 1.1.3-0trusty-20140711-1919-+0000

brings you all install entries with timestamp and version information.  Note: instead of install ‘upgrade‘ and ‘remove‘ works too. ‘rollback‘ brings you version information you’ll might need for what I now call downgrade.