Miguel Riem de Oliveira

@manuelgitgomes the [summary.pdf](https://github.com/manuelgitgomes/tams_pr2/blob/noetic-devel/tams_pr2_atom_calibration/calibration/summary.pdf) continues to appear wrong. Did you change and push? I would like to inspect it...

> I don't think that should happen. > When it is on 0º the black squares are on the left and and when the rotation is 180º the white squares...

> Sometimes the order of the detected points were reversed. Instead of starting at 0,0 it would start at the last one. With charuco you never have this problem. >...

> > the transformation that has parent head_plate_frame has twice the word "to be calibrated". > > This is because the azure frames are provided by the azure driver and...

> > Note that if you do not have a unique to be calibrated transformation per sensor you cannot expect the sensor to be positioned independently from other sensors. >...

> As talked with @miguelriemoliveira, here is a small example of the result of a calibration with a single collection: I @manuelgitgomes , I agree, it could be the problem...

>> I am really inclined in believing the problem is in the arm joints. > From what I've seen so far, that's definitely the biggest part of the remaining error....

> Therefore, much better results. Better, I agree. It went down to half, from 5 to 2.5 pixels on average. Later, I think we should try to improve it by...

One question: could it be that the joint biases are non-linear? For the shadow hand perhaps, since the actuations are based in strings, but for the arm joints I do...

Hi @manuelgitgomes , I see. We never thought about that one.