Tag Archives: amosero

aMoSeRo source code online on Github

IMG_20140716_1817151-624x468I reactivated my old laptop and released the source code of the amosero robot. In case you want to build your own – do not hesitate to contact me to get a detailed construction info for free.

Have a nice day!

Colloquium

I am going to demonstrate the complete thesis and the aMoSeRo on:

Monday 20th, October 2014 – 10.00 am
URZ-3409 – Universitätsrechenzentrum
Bernhard-von-Cotta-Straße 1
09599 Freiberg

 Maps

aMoSeRo – mapping the reality

Today is the day of the first accurate aMoSeRo map. I tried several slamming algorithms e.g. the hector_mapping package, but data has been to bad. So after reviewing nearly all my code, fixing a lot of unit issues and publishing rates, today the first map has been created, which really is a map of the place I am living!

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

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:

aMoSeRo – first robot_pose_ekf and gmapping

This surely doesn’t look amazing from a external look – but this has been a day of hard work and was very important.

The robot_pose_ekf package is working! It is neither the setup I am going to use nor is it very stable – but it proves some points.

First I needed to write my own IMU driver for ros – 9 degrees of freedom (DOF) for 30€ and a bag of problems. This is a lot cheaper (around 100€) than the often used Razor IMU of sparkfun with existing ROS code, and exactly 3DOF better than the WiiMote (with Motion+ and also about 60-70€) I have been experimenting with. There is still a lot of work left for improving the stability, the calibration of the LSM9DS0 and there has been a lot more to find out about magnetic fields and strange units that needed to be converted in other ones than I would have ever expected – but so far the /imu_data topic serves some not totally wrong data – therefore normalisation minimizes  the issues with the 3-5 scales per axis I had to deal with.

Next I needed to increase my bad odometry sources – if not by quality at least with quantity – and added a GPS sensor as /vo topic.  The CubieTruck is a abstruse while handling some easy things like using one of the possible 8 UART connections…  for today I’ve not managed to get it running with UART but a external serial usb controller. Another area that needs heavy improvement…

Finally I had to deal with the REP105 issue that I have been describing in a previous post. The gmapping algorithm needed to get adjusted parameters, coming along with some serious confusion generated by inconsistent syncing over my 4 working devices (rosBrain with roscore and slamming, rosDev – my development machine, the aMoSeRo and the seafile backup server)…

…but after that all parts worked together for the first time, including a simulated aMoSeRo moving on screen while beeing hold in different angles in the real world.

Everything is still far from done – but right on the way – and we’ve already found out how wide the road is 🙂

Willow Garage, the PR2 and REP105

It is the second time I need to adjust my URDF Model for the sake of NOT following the REP (ROS Enhancement Proposal). This time it is about the relationship between base_link and a not REP mentioned base_footprint.

As REP105 says the ‘Relationship between Frames’ should be:

map –> odom –> base_link

but the relation chip for the Willow Garage (or now Clearpath Roboticsrobot PR2 is

map --> odom_combined --> base_footprint  -->   base_link

which is the exact demand of the robot_pose_ekf package.

So Willow Garage, Y U NO Stick to your own REP105 ?

(See more on Know Your Meme)

I suppose because of backwards compatibility, some code might get broken, but what about using some parameters, maybe with a (even hard coded) default fallback?

So for the aMoSeRo there is a decision to be made. Using base_link or base_footprint? Or both? Which frame is the one near to earth?

If decided to take both as a matter of compatibility to other packages and reordered my TF tree:

 

framesWithParentFootprint

 

Still questionable if the base_footprint should have wheels and tracks attached, but that is more a question of taste because they have no special task.

Screenshot - 04.07.2014_4

 

Now the robot has a light grey base_footprint, and a blue base_link.