Closed serena-ivaldi closed 8 years ago
francesco-romano
commented
8 years ago I think your robot configuration is not updated.
Check what @randaz81 did here: https://github.com/robotology/icub-main/commit/27c8513227d13bbf54408cff512b9957de7f7b50
randaz81
commented
8 years ago Additionally, you should check the firmware of the 2FOC boards. They probably need to be updated as well (verifyBoardsPresence fails). And icub-firmware-shared too!
randaz81
commented
8 years ago icub-main has been just updated with new configuration parameters for your robot
robertocalandra
commented
8 years ago @francesco-romano what does it means robot configuration?
yesterday we updated: -icub-firmware-shared -icub-firmware -yarp -icub-main
@randaz81 ok, we will update again icub-main. What is the procedure to update the firmware of the 2FOC boards?
francesco-romano
commented
8 years ago @robertocalandra I meant what @randaz81 has just done :smile:
marcoaccame
commented
8 years ago Hi @robertocalandra,
I will help you to upgrade the FW of CAN boards on an ETH robot.
here are the steps. later on we shall add a dedicated issue on github so that everybody can refer to it.
ethLoader and send a Discovery. You repeat the command until you can see the ETH boards in updater mode. You can close ethLoader now.canLoader. In the second selection box, instead of the default ecan you select EMS.canLoader will show the FW version of the new application.canLoader, before you can use robotInterface it is important to restart the ETH boards, so that they move away from the updater mode. Quickest way to do it is to power motors OFF and then ON again.robertocalandra
commented
8 years ago thanks, I will now proceed with the updating. Where do we find the binaries to upload?
marcoaccame
commented
8 years ago For upgrading to icub-main version 1.2.17 it is enough to update the FW of the EMS boards (ems.hex) and of the 2FOC boards (2FOC.hex), which can be found in icub-firmware-build.
I would however recommend also updating FW of MTB boards (skin.hex).
Moreover, VERY IMPORTANT THING: after the full SW and FW update DO NOT run robotInterface straight away unless with the EXTERNAL FAULT pressed.
Read issue #104 for further details and arrange with @randaz81 some remote assistance for fine tuning of new parameters.
marcoaccame
commented
8 years ago @robertocalandra: you need to be sure to have pulled latest icub-firmware-build repository. from your previous post it seems that you forgot to do this.
serena-ivaldi
commented
8 years ago @marcoaccame I just git pulled all the folders, and icub-firmware-build was properly pulled yesterday.
serena-ivaldi
commented
8 years ago @marcoaccame I just git pulled yarp, icub-main, icub-firmwars-shared, icub-firmware-build. I recompiled yarp and icub-main on the pc104, using the build-pc104. Everything seems to work... only that if I launch ethLoader on the pc104 now it cannot find find yarp libraries. yarp is working though, and other programs are working. See below
icub@pc104:~$ ethLoader ethLoader: error while loading shared libraries: libYARP_OS.so.1: cannot open shared object file: No such file or directory icub@pc104:~$ yarp This is the YARP network companion. Call with the argument "help" to see a list of ways to use this program.
randaz81
commented
8 years ago ethLoader was not built correctly.
1) check that you are not using old executables with new libraries (which ethLoader ecc)
2) maybe yarp/icub-main was built with old cmake options? Keep a backup copy of your build folders and start cmake in a new folder, with a clean cache.
serena-ivaldi
commented
8 years ago I re-did it in the meantime, now the error is: icub@pc104:~$ ethLoader ethLoader: error while loading shared libraries: libethLoaderLib.so: cannot open shared object file: No such file or directory
serena-ivaldi
commented
8 years ago I have an idea: can you confirm that on the pc104 you do not have to do make install? maybe this is the problem. I checked in their bashrc they have
export PATH=$PATH:$ICUB_DIR/bin:$YARP_DIR/bin
but the ethLoader is in
icub@pc104:~$ which ethLoader /usr/local/bin/ethLoader
It's an old file and my recompiling doesn't overwrite it because there have been no changes since then. Could it be that?
randaz81
commented
8 years ago It is that. Do make install to replace the wrong old executable with the new one. (Or remove the files in /usr/local/bin (make unistall), this is up to you, according to your lab policy. In this case, executables will by taken from the PATH). However, I suggest to keep the current make install policy.
lornat75
commented
8 years ago Actually if the PATH points to $YARP_DIR/bin do not do install otherwise you will have duplicated executables in your path.
Do:
sudo make uninstall
Double check that the yarp+icub executables are not in /usr/local/bin
then do simply:
make
lornat75
commented
8 years ago @serena-ivaldi: about your complain. We use github issues so that we can better track people's requests. It may not be optimal but it is much better than using emails (issues are public and can be useful to others, they are indexed by google, you can reference other issues, you can add people to the conversation and you can search using keyworkds, labels etc ...).
Issues do no substitute procedures, apologies if the procedure for updating the firmware is not in the wiki we will add it!
serena-ivaldi
commented
8 years ago @lornat75 Thanks :) I think it definitely needs to be in the manual!!
lornat75
commented
8 years ago @marcoaccame, @randaz81 Can you have a look and update this page: http://wiki.icub.org/wiki/Firmware
serena-ivaldi
commented
8 years ago @lornat75 @randaz81 the uninstall worked! now i can launch ethLoader. i will try to follow the firmware update instructions of @marcoaccame
serena-ivaldi
commented
8 years ago @marcoaccame I launched ethLoader and clicked discovery. how do I know when the boards are in updater mode? there is apparently nothing changing.
I can see 11 boards with IPs 10.0.1.1-11, vers 2 build 17.
robertocalandra
commented
8 years ago if you see 2.17 they are in update mode.
On Thu, Nov 12, 2015 at 1:23 PM, Serena Ivaldi notifications@github.com wrote:
@marcoaccame https://github.com/marcoaccame I launched ethLoader and clicked discovery. how do I know when the boards are in updater mode? there is apparently nothing changing. I can see 11 boards with IPs 10.0.1.1-11, vers 2 build 17. [image: screenshot from 2015-11-12 13 19 58] https://cloud.githubusercontent.com/assets/3786602/11118226/92d1ddb2-8940-11e5-8307-27062081ee4f.png
— Reply to this email directly or view it on GitHub https://github.com/robotology/icub-support/issues/108#issuecomment-156090842 .
serena-ivaldi
commented
8 years ago @marcoaccame Sorry for bothering but it's the first time I do this update and I am afraid of making mistakes!
I tried updating the firmware starting from the 1st board:
Is that right? What am I flashing precisely? Because there is no " additional note" in the firmware, I remember in the old CAN system every board had the name of its body part (e.g., right arm)
Please confirm that I am doing right... I will continue flashing the other IPs
serena-ivaldi
commented
8 years ago @marcoaccame just to check, i am now on 10.0.1.2 and I can see 4 boards:
Is the mais supposed to be updated with skin.hex? What about the other RM 4DC boards?
marcoaccame
commented
8 years ago wait a minute.
marcoaccame
commented
8 years ago first thing: the 2FOC.
it is correct that you have fw version 3.0.0, as you can read from the git log of 2FOC.hex
serena-ivaldi
commented
8 years ago ok i am flashing the 2FOC also in the other IPs.
what about the other boards? i can see MAIS, strain, RM...
also should i do can1 and can2?
marcoaccame
commented
8 years ago then: i have already written that it is necessary to update the 2FOC only.
Possibly also the skin boards.
the 2FOC boards are always on CAN1 bus on addresses: 10.0.1.[3, 5, 6, 7, 8, 9]
the skin boards are on CAN2 of addresses 10.0.1.[2, 4] and on CAN1 / CAN2 of 10.0.1.[10, 11].
serena-ivaldi
commented
8 years ago yes but what is possibly? of course it is possible, i am updating. so i will do it.
what is the name of the boards for the skin? I remember MAIS. Are strain and RM also connected to the skin?
serena-ivaldi
commented
8 years ago we just flashed the skin boards on 10.0.1.2, CAN2. The canLoader was saying Release 2, vers 10, build 17. But the debug information was saying that it discivered version 2.16.17 --> i think there is a bug somewhere
Anyway, we uploaded the skin.hex new version (git says 2.17.0) Again, the canLoader shows release 2, version 11, build 0. However the debug information says it successfully uploaded version 2/17.0
We are going on uploading the other IPs for the skin
marcoaccame
commented
8 years ago I suggest that you to update all 2FOC first. That is the minimum you need to have the system ready for the new version of icub-main.
Then, if you have time you can also update the skin boards. They have new features that you can read in the log of skin.hex. The name of skin boards is not MAIS. It is skin. You can see them in 10.0.1.[2, 4] CAN2
All other boards (MC4, STRAIN, MAIS) dont need to be updated.
marcoaccame
commented
8 years ago The canLoader uses hex notation, the debug information decimal.
serena-ivaldi
commented
8 years ago We have updated everything (2FOC first then the SKIN).
However we have a problem with the boards 10.0.1.11 and 10.0.1.10. They do not answer to canLoader (Communication Error, No answer received - no boards found), both with CAN1 and CAN2.
Since iCubDarmstadt is now currently without the upper cover of the left leg, so this could be related. However it is 2 IPs and 2 CAN bus... is that the problem? Apparently @robertocalandra and the other guys removed it because of some hardware errors. Should we put it back?
Could you confirm that the 2 IPs are related to the left leg? This would help debugging. In the meantime I will try to turn off and on the boards.
marcoaccame
commented
8 years ago board 10.0.1.10 is on left leg. it has attached two patches of skin. one on can1 and one on can2.
board 10.0.1.11 is the same but for right leg.
if the canLoader gets such an error it typically means that there are not CAN boards attached, or a wire is broken.
serena-ivaldi
commented
8 years ago I found a document about the placement of the boards here: http://wiki.icub.org/wiki/Electrical_wiring#Logic_and_Harness_iCub_2.5-_ETHERNET_based
It seems the board 10.0.1.11 is in the right leg, while 10.0.1.10 is in left leg.
So we can say it is normal for the left leg (no upper cover of the skin right now) but there is a problem in the right leg. How can we debug if there is a broken cable on the right leg?
Also, @robertocalandra was reporting power issues on the legs, could be related to that?
marcoaccame
commented
8 years ago now @serena-ivaldi i need to go because i am on a meeting.
if you need immediate help, please arrange a skype session with someone from icub-support.
serena-ivaldi
commented
8 years ago ok thanks for helping. we will leave the right leg skin not updated - not a big issue right now.
pattacini
commented
8 years ago Let me chime in and moderate this exchange.
We try to organize skype/remote sessions to help people having whatever issues with the robot and/or the software. Please, let's stick to this policy and avoid using this service as a chat.
serena-ivaldi
commented
8 years ago so we are launchin robotInterface now and of course there is plenty of errors because it cannot connect to boards 10 and 11. should I remove the corresponding items in the config file of the robotInterface?
another problem: we are trying to debug with yarplogger but it does not show anything. is it normal?
serena-ivaldi
commented
8 years ago @pattacini can you come on skype now? sorry to put pressur but i am staying only 1 day basically and i would like to fix it before leaving.
I commented the two lines of the skin in the XML file of the robotInterface.ini
So the robotInterface does not seem to bother anymore about that. However, it's giving errors and the robot won't start or calibrate. Here is the error from the robotInterface:
[INFO]created device
pattacini
commented
8 years ago Nope, sorry
/cc @robotology/icub-support-team
randaz81
commented
8 years ago francesco-romano
commented
8 years ago @serena-ivaldi @robertocalandra if there are any issues on hardware or electronic level please contact ASAP @robotology/icub-support-team and arrange a Skype meeting, in order to assess the gravity of the problem. We need to know urgently the state of the robot.
cc @DanielePucci @lornat75 @iron76
serena-ivaldi
commented
8 years ago @francesco-romano I am trying to fix the issues, stay tuned!
@randaz81 I git pulled and the error on the head disappeared. Thanks! Now it is calibrating. I still have two issues:
1) The error on the boards (10 and 11) .. not possible to debug the robotIntefrace with these errors, there's red everywhere! Is there a way to disable the creation of the drivers for these two boards? I tried commenting the xml file in the lines related to left and right leg skin, but it is not sufficient apparently.
2) The calibration of the right arm does not look super correct. It is calibrating the left arm then the right one. But the lower arm is not moving symmetrically as the left (a thin difference), and the wrist is down (problem in the zero calibration?). I also heard a bad noise (like something sudden moving a cable) coming from the right wrist. Do I need to redo the wrist calibration?
marcoaccame
commented
8 years ago @serena-ivaldi, if you comment out from robotInterfce.ini down to whatever it calls any reference to the skin on legs, then boards 10 and 11 are not used at all. It may be that you edited a file and robotInterface is using another one.
In short, if your robotInterface.ini is as in repository which calls icub_all.xml, then to remove presence of boards 10 and 11 you should use the following extract of icub_all.xml
<!-- SKINS -->
<devices file="wrappers/skin/left_arm-skin_wrapper.xml" />
<devices file="wrappers/skin/right_arm-skin_wrapper.xml" />
<devices file="wrappers/skin/torso-skin_wrapper.xml" />
<devices file="hardware/skin/torso-cfw2_can9-skin.xml" />
<devices file="hardware/skin/left_arm-ems2-skin.xml" />
<devices file="hardware/skin/right_arm-ems4-skin.xml" />
<!-- removed because we don't want skin in legs
<devices file="wrappers/skin/right_leg-skin_wrapper.xml" />
<devices file="wrappers/skin/left_leg-skin_wrapper.xml" />
<devices file="hardware/skin/left_leg-ems10-skin.xml" />
<devices file="hardware/skin/right_leg-ems11-skin.xml" />
-->
Hi guys, just to update, I commented the entries of the legs skin in the icub_all.xml Together with @julijenv @robotology/icub-support-team we also fixed the issue in the wrist calibration and updated the calibration files. Now the robot calibrates and the robotInterface runs ok (no message errors).
We created (thanks to Alex Paraschos) a pull request to update the files on the repository (https://github.com/robotology/icub-main/pull/239) please accept it!
jeljaik
commented
8 years ago Hello guys, this is just a reminder that the instructions for firmware update on ETH robots is still not clearly available in iCub's wiki. If it is at least, not in the firmware update section. Thanks!
If instead it is already there, please hand me the link, because I may have missed it, and disregard this reminder :smile:
hu-yue
commented
8 years ago @jeljaik I don't know if it's in the wiki, but I know there's a howto file in the icub-firmware-shared repo at least for the EMS : https://github.com/robotology/icub-firmware-build/blob/master/EMS/howto.txt
jeljaik
commented
8 years ago You’re the best. Thanks Yue! I was forgetting about it.
Hi, I am with @robertocalandra and Alex Paraschos, we are trying to update the iCub firmware in iCubDarmstadt01. After updating with ethLoader, we have version 2 build 15 on all boards. Launching the robotInterface now gives a lot of errors that we do not know. Here the log of the robotInterface: