Category Archives: Stuff

Using Chrony on CubieTruck

Don’t.

Unless you really know what are you doing.

To synchronize the clock and fix a minimal time shift I was detecting, I followed the idea of the TurtleBot2 to use chrony to fix that Chrony is a little daemon that connects to your linux clock or hwclock and detect shifts. For some reason this lead to total chaos on the amosero.
I suppose chrony hasn’t been build for multicore dynamically speeded processors like the A20, which is why the shifting has been erratic and up to 2 seconds per minute.

sudo apt-get remove chrony

Fixed all timing errors on the [amazon &title=CubieTruck&text=CubieTruck]. Also it’s a bit disturbing how little changes can inflict complex setups.

 

 

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

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!

 

Reset Arduino Micro via python serial

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.

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 🙂

aMoSeRo xbox controller support

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!

 

aMoSeRo at Technical University Bergakademie Freiberg Open Day

Today we’ve had the honor to inform young high school students about the education possibilities of the Technical University Bergakademie Freiberg at their Open Day. In four hours I’ve learned howto explain everything about the aMoSeRo in a few sentences. Sadly we weren’t able to drive around because everything was very crowded, but we could demonstrate the 3D PointClouds a bit. So everybody was able to see the mathematics in infomatics by example 🙂

The only chance to take some photos had been before the day started, but here are some impressions:

ROS Hydro/Indigo and sparkfun IMU LSM9DS0 9DOF

I’ve connected the LSM9DS0 9 degrees of Freedom Breakout Board made by sparkfun with an arduino micro like I’ve described in a previous post, wrote a little rosserial sensor_msgs::Imu publisher and visualized everything using the rqt plugin manager for further experimenting.

Here a screenshot while moving the setup:

ScreenshotIMURos

a screenshot while not touching:

ScreenshotIMURos2

As you see all data is still moving a lot. So the next step beside finding out what the units really mean, will be stabilizing by using a kalman filter like its provided in the robot_pose_ekf package.

By the way: the arduino is currently using around 25000 of its 28 672 bytes memory just providing the IMU data to ros. So the motorshield will require another micro or we switch it to something else like an wiimote.