iCubLisboa01 head torso problem

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

iCubLisboa01 head torso problem

Giovanni Saponaro-2
Dear iCub hackers,

A few days ago, we had to press the emergency fault button of our
robot during operation, so it "fell" towards the front. Since then, we
have experienced malfunctioning, especially with the head and torso
(CAN0). We use iCubInterface and the latest yarp and iCub software.
The firmware hasn't been updated in a few months.

Here's a temporal sequence of our tests and observations. Sorry if
it's a bit lengthy:

1. initially, canLoader could not connect to CAN0 but it could connect
to the other networks.

2. we tried swapping the wires of CAN0/headtorso with CAN5/lefthand
(reflecting the change in icub.ini) and the problem persisted, i.e.
head was still not starting. Therefore, we suspect the issue to be at
the "robot boards side" of CAN lines -- not on the pc104 side. We then
reverted to the normal setup of CAN0/headtorso, CAN5/lefthand.

3. in the meantime, we also started having trouble booting the pc104
USB pen drive, but Ubuntu's "boot-repair" tool seems to have fixed it:
we can boot it again.

4. next, after a fresh start of pc104 and motors, canLoader could not
connect to *any* CAN network.

5. another fresh reboot, without having touched the hardware and
wires, and now canLoader can connect to all networks again, including
CAN0.
At this point we launched iCubInterface -- logs attached. In the first
try, iCubInterface crashed almost immediately after starting
(segmentation fault). In the second one (log zipped because it was
very large), iCubInterface did start correctly, some body parts were
working and calibrated (e.g. hands), but head & torso still did not
work. In the log you can see loads of messages similar to this one:

 cfw2can [0] Received message but no threads waiting for it. (id:
0x3f, Class:0 MsgData[0]:7)

Any suggestion?

Thanks in advance and happy new year!
-Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers

131230_iCubLisboa01_segfault.txt (5K) Download Attachment
131230_iCubLisboa01_someMotorsWorking.txt.zip (993K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Stefano Saliceti
Ciao Giovanni,
Just a quick question. You mentioned that CanLoader can connect to CAN0 no problem.
Can you send us a screenshot of the CanLoader? My suspect is that some wire in the back of the robot got strained in the "accident".
Indeed the boards that control the waist / torso motors are located in the lower back part of the robot (right under the "underwear") therefore I'd suggest a visual inspection of the board stack and see if any of those behaves different than the others (blinking wise).

Another suspect cable to pay close attention to is the absolute encoder in the "belly button" of the robot. The cable that connects it to its board tends to be in the way when you bend over the robot and chances are that it got cut / damage with the accident.

Let us know if you find anything

Happy new Year

Stefano


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Giovanni Saponaro
Sent: 30 December 2013 19:55
To: RobotCub Mailinglist; [hidden email]
Cc: Ricardo Nunes; Lorenzo Jamone
Subject: [Icub-support] iCubLisboa01 head torso problem

Dear iCub hackers,

A few days ago, we had to press the emergency fault button of our robot during operation, so it "fell" towards the front. Since then, we have experienced malfunctioning, especially with the head and torso (CAN0). We use iCubInterface and the latest yarp and iCub software.
The firmware hasn't been updated in a few months.

Here's a temporal sequence of our tests and observations. Sorry if it's a bit lengthy:

1. initially, canLoader could not connect to CAN0 but it could connect to the other networks.

2. we tried swapping the wires of CAN0/headtorso with CAN5/lefthand (reflecting the change in icub.ini) and the problem persisted, i.e.
head was still not starting. Therefore, we suspect the issue to be at the "robot boards side" of CAN lines -- not on the pc104 side. We then reverted to the normal setup of CAN0/headtorso, CAN5/lefthand.

3. in the meantime, we also started having trouble booting the pc104 USB pen drive, but Ubuntu's "boot-repair" tool seems to have fixed it:
we can boot it again.

4. next, after a fresh start of pc104 and motors, canLoader could not connect to *any* CAN network.

5. another fresh reboot, without having touched the hardware and wires, and now canLoader can connect to all networks again, including CAN0.
At this point we launched iCubInterface -- logs attached. In the first try, iCubInterface crashed almost immediately after starting (segmentation fault). In the second one (log zipped because it was very large), iCubInterface did start correctly, some body parts were working and calibrated (e.g. hands), but head & torso still did not work. In the log you can see loads of messages similar to this one:

 cfw2can [0] Received message but no threads waiting for it. (id:
0x3f, Class:0 MsgData[0]:7)

Any suggestion?

Thanks in advance and happy new year!
-Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Giovanni Saponaro-2
On 31 December 2013 07:54, Stefano Saliceti <[hidden email]> wrote:
> Just a quick question. You mentioned that CanLoader can connect to CAN0 no problem.
> Can you send us a screenshot of the CanLoader? My suspect is that some wire in the back of the robot got strained in the "accident".

Sure. Attached.

> Indeed the boards that control the waist / torso motors are located in the lower back part of the robot (right under the "underwear") therefore I'd suggest a visual inspection of the board stack and see if any of those behaves different than the others (blinking wise).
>
> Another suspect cable to pay close attention to is the absolute encoder in the "belly button" of the robot. The cable that connects it to its board tends to be in the way when you bend over the robot and chances are that it got cut / damage with the accident.
>
> Let us know if you find anything
>
> Happy new Year

Happy new year, talk to you later about the other issues! Cheers,
-Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers

131231_iCubLisboa01_CAN0.png (55K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Giovanni Saponaro-2
In reply to this post by Stefano Saliceti
On 31 December 2013 07:54, Stefano Saliceti <[hidden email]> wrote:

Hi all,

A few updates from us:

> Can you send us a screenshot of the CanLoader? My suspect is that some wire in the back of the robot got strained in the "accident".
> Indeed the boards that control the waist / torso motors are located in the lower back part of the robot (right under the "underwear") therefore I'd suggest a visual inspection of the board stack and see if any of those behaves different than the others (blinking wise).
>

1) We removed the "underwear", and we noticed that a wire connected to
the left capacitor had burned. Not sure if this problem is related and
if it occurred recently or a long time ago. Anyway, we replaced the
wire (see capacitors.jpg). Afterwards, we made a video of the lights
of the board in question compared to the lights of the other boards,
here it is:

http://youtu.be/bhALGVQhq68

> Another suspect cable to pay close attention to is the absolute encoder in the "belly button" of the robot. The cable that connects it to its board tends to be in the way when you bend over the robot and chances are that it got cut / damage with the accident.
>

2) Looking at the "belly button" absolute encoder cable, it seems like
its protecting rubber suffered a small dent (see
belly_button_enc.jpg).

3) Other tests that we ran today:

* iCubInterface (log attached) still prints lots of lines like this one:
  cfw2can [0] Received message but no threads waiting for it. (id:
0x3f, Class:0 MsgData[0]:7)
Usually, the torso motors are *not* started.

* canLoader can usually connect to all the networks - in particular
CAN0 appears like in the screenshot that I sent in the previous email.

* robotMotorGui cannot open any robot part, due to "yarpdev:
***ERROR*** driver <remote_controlboard> was found but could not open"
errors.

* if we try to start the FireWire camera driver on the freshly
rebooted pc104, icubmoddev gives this error:
ERROR: no active cameras
LINE: 209
DragonflyDeviceDriver2: can't open camera

* in one occasion, we started iCubInterface and after a few seconds
the head started shaking at neck level, with a vibration of small
amplitude but high frequency -- we stopped the interface, then we
visually inspected the head looking for backlashes, and the head seems
OK (no backlash).

Thanks for any hint,
Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers

140106_iCubLisboa01.txt.zip (203K) Download Attachment
capacitors.jpg (273K) Download Attachment
belly_button_enc.jpg (1M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Marco Randazzo
Dear Giovanni, I looked at your log and the canloader screenshot you sent.
The error described by "cfw2can [0] Received message but no threads waiting for it. (id: 0x3f, Class:0 MsgData[0]:7)" is extremely strange, because there should be no communication between board 0x03 and board 0x0F.
Actually no board should have id 0x0F, it is a reserved address for broadcast messages and it is never used in our system. Instead, looking at your screenshot I noticed a board with id 15 (second line), that could be responsible for your malfunctioning.  (did you changed the original board address to 15 accidentaly?!)
 
Anyway, I suggest the following test:
1- Start from a fresh boot of the motor control boards: if you already launched iCubinterface, turn off the motor boards and then turn them on again. Wait for 5 seconds to complete the boot sequence of the boards firmware.
2- Open the canLoader,
3- change the can ID of board 15 to 14 by clicking on the number 15 and editing the number (a window will appear to ask you if you are really sure)
4- close the canloader, launch icubInterface and send us a new log.

Cheers,
MarcoR

-----Original Message-----
From: Giovanni Saponaro [mailto:[hidden email]]
Sent: lunedì 6 gennaio 2014 17:59
To: Stefano Saliceti
Cc: RobotCub Mailinglist; [hidden email]; Ricardo Nunes; Lorenzo Jamone; Marco Randazzo
Subject: Re: [Icub-support] iCubLisboa01 head torso problem

On 31 December 2013 07:54, Stefano Saliceti <[hidden email]> wrote:

Hi all,

A few updates from us:

> Can you send us a screenshot of the CanLoader? My suspect is that some wire in the back of the robot got strained in the "accident".
> Indeed the boards that control the waist / torso motors are located in the lower back part of the robot (right under the "underwear") therefore I'd suggest a visual inspection of the board stack and see if any of those behaves different than the others (blinking wise).
>

1) We removed the "underwear", and we noticed that a wire connected to the left capacitor had burned. Not sure if this problem is related and if it occurred recently or a long time ago. Anyway, we replaced the wire (see capacitors.jpg). Afterwards, we made a video of the lights of the board in question compared to the lights of the other boards, here it is:

http://youtu.be/bhALGVQhq68

> Another suspect cable to pay close attention to is the absolute encoder in the "belly button" of the robot. The cable that connects it to its board tends to be in the way when you bend over the robot and chances are that it got cut / damage with the accident.
>

2) Looking at the "belly button" absolute encoder cable, it seems like its protecting rubber suffered a small dent (see belly_button_enc.jpg).

3) Other tests that we ran today:

* iCubInterface (log attached) still prints lots of lines like this one:
  cfw2can [0] Received message but no threads waiting for it. (id:
0x3f, Class:0 MsgData[0]:7)
Usually, the torso motors are *not* started.

* canLoader can usually connect to all the networks - in particular
CAN0 appears like in the screenshot that I sent in the previous email.

* robotMotorGui cannot open any robot part, due to "yarpdev:
***ERROR*** driver <remote_controlboard> was found but could not open"
errors.

* if we try to start the FireWire camera driver on the freshly rebooted pc104, icubmoddev gives this error:
ERROR: no active cameras
LINE: 209
DragonflyDeviceDriver2: can't open camera

* in one occasion, we started iCubInterface and after a few seconds the head started shaking at neck level, with a vibration of small amplitude but high frequency -- we stopped the interface, then we visually inspected the head looking for backlashes, and the head seems OK (no backlash).

Thanks for any hint,
Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Giovanni Saponaro-2
On 6 January 2014 20:22, Marco Randazzo <[hidden email]> wrote:

Hi Marco, hi all,

Good news: the problem was indeed with a wrong board ID, details below.

> [...]
> Actually no board should have id 0x0F, it is a reserved address for broadcast messages and it is never used in our system. Instead, looking at your screenshot I noticed a board with id 15 (second line), that could be responsible for your malfunctioning.  (did you changed the original board address to 15 accidentaly?!)
>

No, we never changed that board address.
In fact, our firmware update sequence (that we last performed several
months ago, using this file  iCubLisboa01/scripts/firmwareUpdate.txt)
contains this line with ID 14:
cfw2can 0 14 4DC.2.15.out.S

What could be the cause of such board ID change, apart from manual
change by human users?

My colleagues tell me that we had exactly the same problem (a
'mysterious' change from ID 14 to ID 15) on our other robot Vizzy,
that uses your modified 4DC 24V boards.

> [...]
> 3- change the can ID of board 15 to 14 by clicking on the number 15 and editing the number (a window will appear to ask you if you are really sure)
> 4- close the canloader, launch icubInterface and send us a new log.

Thanks! After setting the ID back to 14, all robot parts are now well
operational again :).
New iCubInterface log attached.

Cheers,
-Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers

140107_iCubLisboa01.txt (122K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Giovanni Saponaro-2
On 7 January 2014 17:10, Giovanni Saponaro <[hidden email]> wrote:
> Thanks! After setting the ID back to 14, all robot parts are now well
> operational again :).

Sorry, a new problem surfaced regarding joint 4 of the right arm.
During calibration, that motor moves to a limit and then abruptly
moves to the other direction. robotMotorGui shows it as idle, but then
we are able to activate it.

The canLoader screen of the relevant network CAN2 (attached) looks
wrong. Also, iCubInterface prints the following errors:
cfw2can [2] msg from board 3: BIG CURR J0 502205!
cfw2can [2] msg from board 3: BIG CURR J0 500766!
[...]
cfw2can [2] board 3 OVERCURRENT AXIS 0
cfw2can [2] board 3 FAULT OVERLOAD AXIS 0

The values used by the calibrators are the ones in
iCubLisboa01/conf/icub_right_arm.ini, and we have not changed them.

Any suggestion? Full iCubInterface log also attached for completion.

Thanks for the help,
-Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers

140108_iCubLisboa01_right_arm_j4_problem.txt (109K) Download Attachment
140108_iCubLisboa01_CAN2.png (55K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Stefano Saliceti
Hi Giovanni,
it does not seem to be related to the problem you experienced before.

I supposed you restarted the robot and everything. Is that right?
It might happen something like that if you just run iCubInterface right after switching on the motors without waiting at least 5 seconds.

Is the problem consistent or it happens just sometimes?

Talk you soon
stefano

-----Original Message-----
From: Giovanni Saponaro [mailto:[hidden email]]
Sent: 08 January 2014 18:13
To: Marco Randazzo
Cc: Stefano Saliceti; RobotCub Mailinglist; [hidden email]; Ricardo Nunes; Lorenzo Jamone
Subject: Re: [Icub-support] iCubLisboa01 head torso problem

On 7 January 2014 17:10, Giovanni Saponaro <[hidden email]> wrote:
> Thanks! After setting the ID back to 14, all robot parts are now well
> operational again :).

Sorry, a new problem surfaced regarding joint 4 of the right arm.
During calibration, that motor moves to a limit and then abruptly moves to the other direction. robotMotorGui shows it as idle, but then we are able to activate it.

The canLoader screen of the relevant network CAN2 (attached) looks wrong. Also, iCubInterface prints the following errors:
cfw2can [2] msg from board 3: BIG CURR J0 502205!
cfw2can [2] msg from board 3: BIG CURR J0 500766!
[...]
cfw2can [2] board 3 OVERCURRENT AXIS 0
cfw2can [2] board 3 FAULT OVERLOAD AXIS 0

The values used by the calibrators are the ones in iCubLisboa01/conf/icub_right_arm.ini, and we have not changed them.

Any suggestion? Full iCubInterface log also attached for completion.

Thanks for the help,
-Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Giovanni Saponaro-2
On 8 January 2014 17:30, Stefano Saliceti <[hidden email]> wrote:
> I supposed you restarted the robot and everything. Is that right?
> It might happen something like that if you just run iCubInterface right after switching on the motors without waiting at least 5 seconds.
>
> Is the problem consistent or it happens just sometimes?

Hi Stefano,

Yes, we had restarted pc104, motors, laptop + performed "yarp clean"
properly, waiting for some time between each step.
We have verified it again a number of times with the same procedure,
even with a different pc104 USB pen drive, and the problem is
consistent.

Cheers,
-Giovanni

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Stefano Saliceti
Ok.

Then launch iCubInterface with the the FAULT button pressed. Wait for all the timeouts to pass and when the calibration is done run robotMotorGui.

Move the pronosupination join of the right arm and check if the cprresponding value is reading anything in the GUI.

I suspect one of the wire that goes from the motor-encoder to the corresponding board might be damaged.

The board is the 2B2 under the cover of the upperarm. The connector is P4 (see attached picture).

This could cause the trouble you describe.

Let us know your findings.

S.

-----Original Message-----
From: Giovanni Saponaro [mailto:[hidden email]]
Sent: 08 January 2014 19:08
To: Stefano Saliceti
Cc: Marco Randazzo; RobotCub Mailinglist; [hidden email]; Ricardo Nunes; Lorenzo Jamone
Subject: Re: [Icub-support] iCubLisboa01 head torso problem

On 8 January 2014 17:30, Stefano Saliceti <[hidden email]> wrote:
> I supposed you restarted the robot and everything. Is that right?
> It might happen something like that if you just run iCubInterface right after switching on the motors without waiting at least 5 seconds.
>
> Is the problem consistent or it happens just sometimes?

Hi Stefano,

Yes, we had restarted pc104, motors, laptop + performed "yarp clean"
properly, waiting for some time between each step.
We have verified it again a number of times with the same procedure, even with a different pc104 USB pen drive, and the problem is consistent.

Cheers,
-Giovanni

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers

100_1439.jpg (1M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Giovanni Saponaro-2
On 9 January 2014 07:55, Stefano Saliceti <[hidden email]> wrote:
>

Hi,

> Then launch iCubInterface with the the FAULT button pressed. Wait for all the timeouts to pass and when the calibration is done run robotMotorGui.
>
> Move the pronosupination join of the right arm and check if the cprresponding value is reading anything in the GUI.
>

When we move the pronosupination, we can see the encoder reading
changing accordingly in the GUI, although the values are outside the
normal range - screenshot attached. On the other hand, all the other
joints seem to have normal readings when we move them.

Shall we try to reflash the firmware? Or any other test?

Thanks,
G


> I suspect one of the wire that goes from the motor-encoder to the corresponding board might be damaged.
>
> The board is the 2B2 under the cover of the upperarm. The connector is P4 (see attached picture).
>
> This could cause the trouble you describe.
>
> Let us know your findings.
>
> S.

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers

fault_j4.png (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Stefano Saliceti
Hi Giovanni,
it's normal that the value you read it's outside normal limits as the joint did not calibrate.

This is the Action Plan:

1. Launhc iCubInterface with FAULT button pressed.
2. Launch robotMotorGui and Look for jumps or spikes in the reading through all the range of joint 4.
3. If the reading are smooth then you can launch:
        roborMotorGui --calib
which will enable the calib button on the GUI.

4. Only at this point release the FAULT button
5. Hit CALIB on joint 4 of the right arm.
6. Check that the calibration performs as it should and report.

7. Reflashing the firmware for the MC4 board (board ID2 on CAN2) and both BLLs could be a nice shot (to do after the tests listed above and compare results).

Talk you soon
Stefano

-----Original Message-----
From: Giovanni Saponaro [mailto:[hidden email]]
Sent: 09 January 2014 12:21
To: Stefano Saliceti
Cc: Marco Randazzo; RobotCub Mailinglist; [hidden email]; Ricardo Nunes; Lorenzo Jamone
Subject: Re: [Icub-support] iCubLisboa01 head torso problem

On 9 January 2014 07:55, Stefano Saliceti <[hidden email]> wrote:
>

Hi,

> Then launch iCubInterface with the the FAULT button pressed. Wait for all the timeouts to pass and when the calibration is done run robotMotorGui.
>
> Move the pronosupination join of the right arm and check if the cprresponding value is reading anything in the GUI.
>

When we move the pronosupination, we can see the encoder reading changing accordingly in the GUI, although the values are outside the normal range - screenshot attached. On the other hand, all the other joints seem to have normal readings when we move them.

Shall we try to reflash the firmware? Or any other test?

Thanks,
G


> I suspect one of the wire that goes from the motor-encoder to the corresponding board might be damaged.
>
> The board is the 2B2 under the cover of the upperarm. The connector is P4 (see attached picture).
>
> This could cause the trouble you describe.
>
> Let us know your findings.
>
> S.

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Giovanni Saponaro-2
On 9 January 2014 11:34, Stefano Saliceti <[hidden email]> wrote:
>

Hi,

By the way, we noticed that the "CAN2 canLoader bogus address" error
that we mentioned yesterday is not consistent. At least in one case
today, we observed correct CAN2 addresses - new screenshot attached.

However, even when CAN2 gets correct addresses, we observe the wrong
pronosupination calibration on the robot - that problem is indeed
consistent.

Also, in this morning's tests ("Move the pronosupination join of the
right arm and check if the cprresponding value is reading anything in
the GUI."), the GUI reading was updating, but it was off by a factor
of 2: we were moving the arm by 90 degrees, the GUI reading changed by
45.

We followed your plan:

> 1. Launhc iCubInterface with FAULT button pressed.
> 2. Launch robotMotorGui and Look for jumps or spikes in the reading through all the range of joint 4.
>

We launched the GUI as soon as the device was created by
iCubInterface, and we confirmed the reading of j4 to be constant.

> 3. If the reading are smooth then you can launch:
>         roborMotorGui --calib
> which will enable the calib button on the GUI.
> [...]

We tried to calibrate, but obtained the error in the attachment.
I suppose we are missing a "right_arm_calib" group in our
iCubLisboa01/conf configuration files?

Thanks,
-Giovanni

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers

calib_not_done.png (164K) Download Attachment
140109_iCubLisboa01_CAN2_correct.png (52K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Giovanni Saponaro-2
In reply to this post by Giovanni Saponaro-2
On 7 January 2014 17:10, Giovanni Saponaro <[hidden email]> wrote:

> Hi Marco, hi all,
>
> Good news: the problem was indeed with a wrong board ID, details below.
>
>> [...]
>> Actually no board should have id 0x0F, it is a reserved address for broadcast messages and it is never used in our system. Instead, looking at your screenshot I noticed a board with id 15 (second line), that could be responsible for your malfunctioning.  (did you changed the original board address to 15 accidentaly?!)
>>
>
> No, we never changed that board address.
> In fact, our firmware update sequence (that we last performed several
> months ago, using this file  iCubLisboa01/scripts/firmwareUpdate.txt)
> contains this line with ID 14:
> cfw2can 0 14 4DC.2.15.out.S
>
> What could be the cause of such board ID change, apart from manual
> change by human users?
>
> My colleagues tell me that we had exactly the same problem (a
> 'mysterious' change from ID 14 to ID 15) on our other robot Vizzy,
> that uses your modified 4DC 24V boards.
>
>> [...]
>> 3- change the can ID of board 15 to 14 by clicking on the number 15 and editing the number (a window will appear to ask you if you are really sure)
>> 4- close the canloader, launch icubInterface and send us a new log.
>
> Thanks! After setting the ID back to 14, all robot parts are now well
> operational again :).

Hi Marco, hi all,

Just wanted to report that we experienced another "mysterious" board
address change while turning on our iCub, similar to the one we
described a few months ago.

Today the CFW2CAN6 network (right hand) started with its 2B3 board
having an ID of 15 instead of 5 as it's supposed to
(http://wiki.icub.org/wiki/Can_addresses_and_associated_firmware).
After we corrected the ID with canLoader, that part became operational
again.

We never changed that board address, nor did we upgrade the firmware
lately, nor the power supplies voltage and current.

In any case, our robot is going to IIT soon for maintenance and
upgrades. If necessary we can provide further details and logs to
investigate this matter.

Cheers,

--
Giovanni Saponaro
http://www.isr.ist.utl.pt/~gsaponaro/

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: [Icub-support] iCubLisboa01 head torso problem

Stefano Saliceti
Hi Giovanni and all,
indeed the problem is so randomic that it's difficult to nail down.
We do not have resources right now to fully investigate the issue, but we are confident that this is not a job-stopper.
Moreover the new firmware implements more check on board integrity and therefore on boards ID.
While this dos not fix the issue it will in principle make it easier to catch and troubleshoot.

We will have a look at the boards during the upgrade anyway and see if any needs to be replaced.

Cheers
Stefano


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Giovanni Saponaro
Sent: 25 July 2014 14:45
To: Marco Randazzo; RobotCub Mailinglist; [hidden email]
Subject: Re: [Icub-support] iCubLisboa01 head torso problem

On 7 January 2014 17:10, Giovanni Saponaro <[hidden email]> wrote:

> Hi Marco, hi all,
>
> Good news: the problem was indeed with a wrong board ID, details below.
>
>> [...]
>> Actually no board should have id 0x0F, it is a reserved address for
>> broadcast messages and it is never used in our system. Instead,
>> looking at your screenshot I noticed a board with id 15 (second
>> line), that could be responsible for your malfunctioning.  (did you
>> changed the original board address to 15 accidentaly?!)
>>
>
> No, we never changed that board address.
> In fact, our firmware update sequence (that we last performed several
> months ago, using this file  iCubLisboa01/scripts/firmwareUpdate.txt)
> contains this line with ID 14:
> cfw2can 0 14 4DC.2.15.out.S
>
> What could be the cause of such board ID change, apart from manual
> change by human users?
>
> My colleagues tell me that we had exactly the same problem (a
> 'mysterious' change from ID 14 to ID 15) on our other robot Vizzy,
> that uses your modified 4DC 24V boards.
>
>> [...]
>> 3- change the can ID of board 15 to 14 by clicking on the number 15
>> and editing the number (a window will appear to ask you if you are
>> really sure)
>> 4- close the canloader, launch icubInterface and send us a new log.
>
> Thanks! After setting the ID back to 14, all robot parts are now well
> operational again :).

Hi Marco, hi all,

Just wanted to report that we experienced another "mysterious" board address change while turning on our iCub, similar to the one we described a few months ago.

Today the CFW2CAN6 network (right hand) started with its 2B3 board having an ID of 15 instead of 5 as it's supposed to (http://wiki.icub.org/wiki/Can_addresses_and_associated_firmware).
After we corrected the ID with canLoader, that part became operational again.

We never changed that board address, nor did we upgrade the firmware lately, nor the power supplies voltage and current.

In any case, our robot is going to IIT soon for maintenance and upgrades. If necessary we can provide further details and logs to investigate this matter.

Cheers,

--
Giovanni Saponaro
http://www.isr.ist.utl.pt/~gsaponaro/
_______________________________________________
Icub-support mailing list
[hidden email]
http://lists.icub.iit.it/mailman/listinfo/icub-support

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers