robotology / cer Goto Github PK

Hi @barbalberto

I and @randaz81 spotted today a very strange interaction among motor interfaces for multi-joints control.

The following code used by the reaching controller

iposd[0]->setPositions(jointsIndexes[0].size(),jointsIndexes[0].getFirst(),&ref[0]);
iposd[1]->setPositions(jointsIndexes[1].size(),jointsIndexes[1].getFirst(),&ref[3]);
iposd[2]->setPositions(jointsIndexes[2].size(),jointsIndexes[2].getFirst(),&ref[4]);
iposd[3]->setPositions(jointsIndexes[3].size(),jointsIndexes[3].getFirst(),&ref[9]);

sends references to the following devices:

• 0 ➡️ torso_tripod
• 1 ➡️ torso (just the yaw)
• 2 ➡️ [left|right]_arm (only the first 5 joints)
• 3 ➡️ [left|right]_wrist_tripod

In this configuration all the joints but those of the wrist_tripod reach their set-points. Instead, the latter joints remain stuck to supposedly hard-coded values.

By contrast, if we rely on the modified snippet below, where basically we replace the multi-joints control with subsequent single-joint calls, everything works as expected:

iposd[0]->setPositions(jointsIndexes[0].size(),jointsIndexes[0].getFirst(),&ref[0]);
iposd[1]->setPositions(jointsIndexes[1].size(),jointsIndexes[1].getFirst(),&ref[3]);
for (size_t i=0; i<jointsIndexes[2].size(); i++)
    iposd[2]->setPosition(i,ref[4+i]);
iposd[3]->setPositions(jointsIndexes[3].size(),jointsIndexes[3].getFirst(),&ref[9]);

Create in the repo the robot structure that will allow using our components and utilities.

/cc @barbalberto @randaz81

To be verified. The control module is running with 100ms period.

With f2004e3 I've committed a small snippet with the idea of commencing a back-to-back comparison of our two kinematics libraries.

Anyway, I'd propose the following refinements for cer_kinematics_alt:

• The lib is fraught with tabs: it would be great to replace 1 tab with 4 spaces and make sure that any next editing will add up just spaces. (done via e5b275c)
• The namespace is currently cer::kinematics2 but for consistency I'd rather go for cer::kinematics_alt. (done via fb05a95)
• The private headers are exposed from within Solver.h, which is public instead. They should be hidden and not directly included in Solver.h. This way we could also get rid of the ambiguity between yarp::sig::Matrix (our main implementation of Algebra) and cer::kinematics2::Matrix. By the way, why don't we use yarp::sig::Matrix straightaway?
• This line causes a compilation error, whereas we should be able to reference somehow the desired frame correctly (maybe still relying on the namespace too).
• It is not clear which joints mapping is used by the LeftSideSolver::fkin() method.

position control is currently using an internal velocity control loop(?) whose gains are taken from the [POSITION_CONTROL] section and not from [VELOCITY_CONTROL] section.

About 7degs of error on the pitch joint are noticed when the tripod joint is elongated. Maybe PID gains are not tuned correctly? To be verified.

The shoulder's pitch constrained to +54 deg is very limiting in terms of reachable space.
Is it possible to take some actions in the future to widen this range?

cc @fiorisi @randaz81

A controlboardrwrapper which merges a tripod part with another generic part of the arm causes a segmentation fault.

Since wholeBodyDynamics is not available for the CER robot, currently there is no way to zero the output of the FT sensor.

A thorough test campaign must be carried out to verify the functionality of the WiFi in noisy environments, to then come up with possible solutions to improve the quality of the link.

For example, we should start off by better accommodating the internal antennas.

cc @maggia80 @randaz81 @fiorisi

As per the title, the physical tripod interface of the wrist doesn't allow any velocity control, whereas the position-direct mode is perfectly working.

We didn't experience any trouble with commanding the physical tripod of the torso in velocity, though.

cc @randaz81

We need to make the developers' life much easier and:

• Fix the IP of the machine controlling the LED screen once for good.
• Create xml script to launch the services required to display patterns on the LED screen.
• Create System images

cc @barbalberto @mbrunettini

Please @randaz81 assign the sub-tasks to whom you think might be responsible.

As of now we have one frame attached to the mechanical center of the Xtion.

For control purpose, we would need to:

1. Move the frame above called depth to the actual center of the depth sensor.
2. Introduce a further frame we can call depth_rgb to be attached to the center of the Xtion rgb sensor.

@fiorisi is going to deal with this request (not urgent) next week.

Note

Other frames already available are:

• left
• right
• cyclopic, attached to the middle of left and right
• gaze, attached to the middle of the screen

cc @randaz81 @barbalberto @vtikha

This message, generate by the arm boards, is flooding robotInterface output.

After the preliminary tests we ran to check the control of the tripod we can report on the following problems we need to address:

• yarpmotorgui needs to be extended to expose fractional slider steps (see robotology/yarp#628).
• solver related bugs/improvements:
  • the state port streams out the pitch and the roll in radians instead of degrees (fixed via 641bb41).
  • account for the roto-translation matrix T0 (addressed via #6).
• tripodMotionControl related bugs/improvements:
  • handle a configurable T0 (via f500cc7).
  • compute proper speed on the fly for each joint so that the joints will attain the desired targets at the same time.
  • seg-fault caught when cleaning memory at shut-down (fixed via 3926033).
• FW related bugs/improvements:
  • we have to make sure that both the FW and the solver will use the same structure's bounds (done).
  • the FW gets somehow stuck when an angular limit is reached (fixed).
  • calibration of the torso (see robotology/icub-firmware#25 done).
  • when the low-level limit checker kicks in stopping the motion of the tripod, we agreed to make the desired set-points equal to the current encoders values (fixed via robotology/icub-firmware@d6ffe3a).

These are all minor bugs/improvements since we were happy to see the tripod moving correctly in most configurations.

/cc @ale-git @barbalberto @randaz81

Test CER usb cameras with the object recognition suite.

check all the settings (gain, intensity, saturation etc)
driver can be improved to allow on-the-fly change of resolution.

Apparently, the new FW we requested for the cameras to change the brightness values do not allow running in 640x480 mode, but only with higher resolutions. Obviously, this is very problematic in terms of band consumption, and we cannot go back to the previous FW version at the moment.

As temporary workaround, @barbalberto is customizing the device driver with the goal of cropping (to switch from 16:9 to 4:3) and then resizing down the image (to 640x480) at the robot side.

cc @randaz81 @vtikha

Not implemented yet.

Pressing the external fault button causes the 2FOC controlled joints to trigger an HW_FAULT (firmware issue)

@vtikha

The yarprobotinterface's handshake with the current rpLidar device (inside cer-base) fails. The other rpLidar works fine, so (I presume) the current device must be replaced.

aplay is able to play an audio file correctly only after launching Audacity (?)

Just a question / dicussion:

Shall CER repo depends on iCub's repo?
Right now there are some include files that throws in the dependency like:
#include <iCub/iKin/iKinFwd.h>

Anyway, aside from this, the robot will use the iCub devices like the embObj* so the dependency is quite strong right now.

There was an idea to move the icubmod on a separated repo, in that case shall we move also some other reusable library like iKin?

As of now we cannot control the head, mainly because of mechanical low level problems.
We should thus address this problem at the mechanical stage as much as possible.

This is a note for the design group.

cc @fiorisi @randaz81 @ale-git

We need to fix and check the sign of the pronosupination joints.
Soon afterwards we do need to verify teleop again.

cc @randaz81 @ale-git

cer\app\robots\CER01\cer.urdf is different from cer-sim\cer-gazebo\cer2\cer.urdf

Check ip addess/mac address/user name for the head board.
Create an image of the system.

if a joint does not complete the calibration, it is not possibile to use the joint anymore.

We need to put an effort in tuning the PID and checking that the implementation is correct.

cc @randaz81 @ale-git

It is not using rotorPosMin/rotorPosMax parameters as required by the specifications

@barbalberto

I had to revert back to STATIC because in SHARED mode tests do not compile against the cer_kineamtics library and, further, the library doesn't get installed correctly.

I need to develop the code by now, so I need the tests; later on we could investigate this issue.

/cc @drdanz

The dark semitransparent screen of the robot messes up images acquisition from the xtion rgb camera, making point cloud reconstruction almost impossible.

cc @robotology/cer-developers @vtikha

kinect/openNi device driver has to be completed too.

A new calibration type should be added to added.
This calibration type should enable (1) the joints of the cer mobile base without trying to reach home position.
Currently, calibration type 3 is used on the mobile base joints.

(1) = just exit from the 'not configured' phase

current pid gains are currently written inside the firmware and are not read from the configuration file

Looks like CER machines with Ubuntu have several stability issues.

@drdanz @pattacini @randaz81

We do experience frequent HW FAULT of the tripod joints while controlling the mechanism by means of the GUI.

cc @ale-git @randaz81

wheels are currently controlled in openloop mode.
In order to use a velocity control loop, high resolution encoders need to integrated in the mobile base motors.

check if the AP mode is correctly working

The driver controlling the equivalent tripod of the wrist does not work. It might be only a matter of configuration, given that the equivalent tripod of the torso does work correctly.

More details on this later.

cc @randaz81 @barbalberto @ale-git

A virtual mais board, broadcasting the 'raw' joint encoders (before the coupling) should be created.

eyes display could be controlled by a virtual motor control board.

@drdanz somehow I'm having problems compiling the brand new solver module. Apparently, the cer_kinematics related cmake variables are not resolved.

It might be due to a stupid oversight of mine, but I'm not able to fix it right now.
Could you have a look into this please?

Required to complete the teleoperation task

Arm pronosupination joint often triggers an overcurrent fault.
Overcurrent check is now currently disabled. Check the overcurrent detection algorithm.

We have experienced big problems while controlling reaching with a rate of 100 Hz (i.e. sample period Ts = 0.01 s). What happened was that the internal messages queue got increasing and, as result, the movements got delayed of significant amount of time.

By changing Ts = 0.1 s, we improved the situation, even though a rate of 10 Hz is way low...

cc @randaz81 @barbalberto @ale-git

destructor is never called. This causes robotInterface to close during the next launch (because the serial port driver is already busy)