Have a nice day!
I am going to demonstrate the complete thesis and the aMoSeRo on:
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!
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 🙂
It is only consequent to leave the virtual cookie box too:
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 🙂
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.
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 🙂
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
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:
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.
Now the robot has a light grey base_footprint, and a blue base_link.
For reasons of documentation and because I never did something like that before (fun) I have created a little video of the amosero driving around in the yard today. It is my longest video so far and I hope you enjoy it: