Marco's profile - activity

Hi all!

I recently added an adxrs613 gyro to my setup and am trying to calibrate the odometry. Because my kinect is mounted upside down on my robot I expected that some small changed in the code of calibrate.py are needed for everything to function correctly. I expected that the change in calibrate from

scan_delta = 2*pi + normalize_angle(scan_end_angle - scan_start_angle)

to

scan_delta = 2*pi - normalize_angle(scan_end_angle - scan_start_angle)

and in align from

angle = self.scan_angle

to

angle = - self.scan_angle

would suffice to fix this?

However my problem is that, during the calibration run, I notice that especially at the lowest speed (first calibration rotation) the turtlebot rotates much too far (about 1.5x). I guess because the bot rotates way too far, it is not able to find the straight wall anymore and the next calibration run starts off at a wrong position. These higher speed calibration rotations do however seem to rotate approximately 360 degrees, but then of course also end up facing away from the wall and thus not finding it correctly. I checked if the data coming from odometry and imu is making sense by echoing when using keyboard_teleop and it does.

Any suggestions on what's going wrong and how to fix it?

As the Sparkfun ADXRS613 breakout gyro for the turtlebot is not available from sparkfun anymore, I was wondering if the Active-Robots Gyro Breakout Board MLX90609-E2 is an interchangeable alternative?

It seems to have the same sensitivities, rate and required voltages.. Only thing different I see is that the standard capacitor sets it to ~36Hz instead of ~361Hz for the adxrs613. Switching out the capacitor should fix this, is it useful though?

I am noticing that when controlling my 'turtlebot' from my workstation using keyboard_teleop, the movement is not fluid. When for example pressing left-arrow constantly on the workstation the robot rotates, stops shortly, starts rotating again etc.. Of course this influences my results slightly, so I would like to fix it.

My turtlebot-pc is under quite high CPU load, so that might be the problem. Can I increase fluent movements by altering teleop software somewhere?

I noticed that when I use the roomba remote to control the turtlebot it already moves more fluid, even when the IR-sensor goes out of range: the Icreate comes to a halt without shocks (something like no commands being sent to the motors?), and not with a shock like when using the keyboard_teleop.

Hi!

I've been experimenting with the turtlebot-pkg on a fitpc2 with icreate and kinect but am running into the limits of the cpu now. I noticed that the openni_camera nodelet combined with the throttler uses quite a lot of cpu power. My guess is that this is caused by the fact that the driver publishes data at 30hz, and only after the throttler i get the advantage of the lower framerate (i only need about 5hz). The combination of driver/throttler thus still uses quite some cpu power as it works with the full 30hz datastream.

Is it possible to lower the framerate in the driver itself, as the cpu-power it uses to publish pointclouds at 30hz is wasted..?

Hi everyone,

I'm working to get the data values of the xyz components out of the pointcloud2 in a bagfile made from kinect with openni_kinect. I was wondering however what the datarange for these values are, to be able to see if my results make any sense. Are these values in meters (so 3.4 for 3.4m) or different?

I am using the turtlebot stack to control my Irobot Create + Kinect, but currently do not have a gyro. However, I would like to calibrate the odometry from the Icreate encoders. The turtlebot calibrate routine however requires an imu present: I keep getting the error "Still waiting for imu" when trying to run the calibration routine.

Does anyone know a way to calibrate the Irobot Create odometry without needing the imu present? I've looked into the code of calibrate.py a bit and do not see an easy way of removing the imu dependency..

Hi everyone,

I am trying to get the xyz data from a pointcloud2 msg in bagfile created with kinect. So far I seem to be getting quite far, but at this point I'm a bit uncertain.

The Pointfield in the pointcloud2 shows that the data should consist of three Float32 (std_msgs::Float32) values for x,y & z. However the pointstep parameter shows 16 bytes are being used per datapoint. Are the first 12 bytes used for the x,y,z Float32 values and are the last 4 bytes overhead, or is this built up differently?

Result for information parameters:

width = 320 height = 240 row step = 5120 point step = 16

Fields[0] --> name: x offset: 0 datatype: 7 count: 1

Fields[1] --> name: y offset: 4 datatype: 7 count: 1

Fields[2] --> name: z offset: 8 datatype: 7 count: 1

Little code snippet:

typedef sensor_msgs::PointCloud2 PointCloud;
typedef PointCloud::Ptr PointCloudPtr;
typedef std_msgs::Float32 Float32;

//get the pointcloud loaded from view_it
PointCloud cloud_t;
PointCloudPtr cloud = view_it->instantiate<PointCloud> ();
cloud_t = *cloud;

//get pointer to first element of dataline 20 and typecast it to Float32
unsigned char *dataptr = &cloud_t.data[20];
entryptr = (Float32 *) dataptr;

//print the value of x (if its in first 4 bytes)
std::cout << "data x float is " << (*entryptr).data <<std::endl;