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:
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.
Sometimes resetting a device isn’t as easy as expected. After some research i figured out, that opening a serial connection with a special baud rate would to the job for our Arduino Micro (and similiar like Leonardo):
#!/usr/bin/env python import serial port='/dev/ttyACM0' #adjust this in case your device differs ser = serial.Serial() #open serial connection ser.port=port #setting the port accordingly #in case your usual baudrate isn't 9600 reset will not work, therefore we will open a resetable connection #thanks to mattvenn.net for suggesting to add this step! ser.baudrate=9600 ser.open(); ser.close() ser.baudrate=1200 # set the reset baudrate ser.open(); ser.close() #don't forget to sleep some reset time
Run the script as root. It might need required to change your port according to your serial controller status.
Today I’ve got the chance to get my hands on a Leap Motion. As it uses depth information to track hands on a short range from the device and as there is a ros driver package existing for it, I hoped to get a 3D PointCloud. It costs about 80€ and could have been a cheap replacement for the [amazon &title=Xtion&text=Asus Xtion].
Unfortunately its not possible (yet?) – here is a very nice post why.
But it is fun anyways to get both hands tracked:
The ros driver interfaces ros with only one hand – but we could do something like shown below to control the amosero:
Later it would be a nice way to control a robot arm – but for now we leave that nice little device as there is a lot of other stuff to be done.
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
but the relation chip for the Willow Garage (or now Clearpath Robotics) robot 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:
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:
Far from done, but right on the way – the aMoSeRo did his first 2D planning today. There are still a lot of adjustments needed for the mapping to work properly, but it’s already impressive to see ROS working.
first SPLAM – first navigation through a map
The node graph still grows and will need some changes when used with multiple robots, but organising goes on 🙂
After days with latex and struggling with all sensor data a mobile robot needs, today is the first day of ROS showing me a small map view. It’s anything but stable and I can’t claim understanding everything – but because I’ve hadn’t something to report for some time now here a small demonstration:
Topics Overview – amosero a distributed system still far from optimal
Because my IMU doesn’t do its work as it should, I’ve used a WiiMote Motion + and run it by a common ros driver and bluetooth.
Yeeeha 🙂
ROS is amazing. After installing the xbox drivers (xboxdrv) on linux, following some well written instructions and writing about 100 lines of own code – the aMoSeRo is now able to be controlled by an xbox controller.
Driving the robot around the house revealed the real power behind the two RB-35 (1:30). Not to fast to control but very strong driving over piles of books the motors seemed to be a good choice.
Some issues with the wheels – a lot of force beeing at work, especially along the positive and negative y-axis (see REP103 post) will be solved soon by some super glue 🙂
So demonstrating the robot in future will be a lot more easy and controllable – and a lot more fun!