Robotology
Unable to communicate/detect 2FOC board after firmware update #734
Unanswered
plinioMoreno
asked this question in
Q&A
Replies: 4 comments 16 replies
|
Hello! Can I ask you something that could help us understand better the problem?
|
6 replies
|
2FOC led have a behavior like this? MicrosoftTeams-video.4.mp4
What error yarprobotinterface give? Something like CAN board discovery fails? Or could be an error of mismatch of the 2FOC version in the configuration files? Can you post the log? Still strange that you can't see the boards from FirmwareUpdater. I will check with other colleagues next days for some additional help. |
|
Good afternoon, Thank you for your support, and apologies for the late reply. It took a while to set everything up before we could respond, as we were performing other tests in the meantime. However, we have come across another error and are continuing in this thread, as we believe you will also need the yarprobotinterface logs to assist us. The current issue is a HW_FAULT during calibration initiation. Nothing moves at all. The full log of yarprobotinterface can be found below (CAN1-related messages and timing warnings were filtered out, as the unused CAN1 bus floods the output with repetitive errors): The configuration used for this run of yarprobotinterface is available here. A video of the board's behaviour is below (light turns red after the HW_FAULT): hw_fault_video.mp4The schematics PDF is available here. Please note that the fault pins are not yet represented in the schematic, but they are connected at P1 and P6 (pin 3 of each connector). We are currently using 24V, reducing the chances of an undervoltage issue. Two individual motors were tested, reducing the chances of this being a motor-related issue. We would greatly appreciate any guidance on resolving the HW_FAULT Thanks in advance! |
|
Hello!!
|
|
Hello! Thank you for the quick follow up. To address your questions:
Thanks in advance! |
|
In the setup shown above, not the robot i cannot see a hard stop, so calibration type 5 will not go well. Probably is a FW problem, given the fact that 2FOC board is not usually used with DC motors. Ok, in case you can use yarpmotorgui to check the readings. |
|
Hi all, I think that there can be a couple issues. REMARKThe 2FOC board needs at least 18 V power supply, otherwise it is likely that you get an |
4 replies
|
Hello! Thank you for the reply, we were unaware of this. We did update all the boards firmware to the 1.23.0 build version and are indeed using the 1.6 CAN protocol version. We would appreciate it if you could provide us the updated 2FOC-DC compatible firmware with the protocol updated to 1.7. Thank you! |
|
I see. If your EMS version has CAN protocol 1.6 you should be safe on this side with the 2FOC-DC firmware in repo: https://github.com/robotology/icub-firmware-build/blob/devel/CAN/2foc/2foc.r1.dc.hex I'll manage to update the 2FOC-DC protocol as soon as possible. |
|
Thank you! We will test with that firmware you referenced and update you with the results. |
|
Hello! Sorry for only replying at this time. We continued development of other functionalities of Vizzy and only now we are returning to the boards upgrade. We flashed the 2FOC-DC firmware from here and updated the Motor Control Service file accordingly (changes in this commit). CAN discovery now passes with application ver 5.3.220 / protocol 1.6, and embObjMotionControl opens correctly, so we are now on the DC-motor firmware you pointed us to. However, the HW_FAULT at calibration persists. Full log below. Some observations:
As before: 24V supply is used. Here follows the log: |
|
Hi all, I've found this old issue on this topic that can be helpful: robotology/icub-main#750 (comment) Starting from this software version, the EMS should be able to calibrate in hard stop with 2FOC boards: |
2 replies
|
Hi @ale-git, thank you for the pointers! That makes things clearer. This issue was in fact our original feature request for calibration type 5, and at the time, as I understand it, we only got it working through calibration type 10 with the custom EMS firmware you built for us (ems004.lisboa.zip), which was never integrated into the official builds. Also, if we understand correctly, this commit means hard-stop calibration with 2FOC boards (motor encoder only) is now supported in the official EMS firmware, so we should update our EMS and use calibration type 5 directly. As stated previously, our EMS4 is currently running FW 3.48 (built 2021 Dec 15), which predates that PR, so this likely explains why our calibration attempt fails on the current setup. Before we update, we'd like to confirm that this presents a limitation, since the updated EMS firmware uses CAN protocol 1.7, while the 2foc.r1.dc.hex in icub-firmware-build speaks 1.6. We are required to use a 2FOC-DC firmware with protocol updated to 1.7, correct? Thanks in advance! |
|
Hi @ale-git, I just want to provide more context about the old issue. You sent by email a firmware version to @wevmacedo, after you fixed some communication issue between the EMS4 and the 2FOC. That version sent by email, was our starting point in this new thread, and @JPLDevMaster run the tests with that customized firmware version, which we could not configure it to work as expected. However, I was not aware of the calibration type 10. I mentioned this at the beginning of the thread. About the firwmare version that supports hard stop with 2FOC boards, can you add the DC support for us to test here? What would be the timing for that to be available? |
|
Hi all, this version should work in a V 1.7 CAN protocol environment. |
4 replies
|
Hi! Thank you for your reply. We tested the firmware package you referenced (2FOC-DC.1.7.zip) and observed the same failure mode. The relevant log is included below: This raises a few questions on our end that we'd appreciate your input on:
We don't encounter this issue when using roie, and are unsure why CAN2:1:0 is rejected as an invalid connector string in this context (doesn't happen in roie mode). As a further diagnostic step, we set skipCalibration to true in general.xml (with the encoder still set to roie): having obtained the following: With this configuration, yarprobotinterface starts successfully and reaches the running state without errors. However, yarpmotorgui reports the joint in an HW fault state, with the encoder reading fixed at 0.000 and showing no variation under manual motion. We repeated this test with raw encoder values enabled and observed the same HW fault status. We'd appreciate guidance on how to proceed, specifically on the correct encoder configuration for the 2FOC-DC setup as well and answers to our questions, which, in short, are:
Any other tests you need us to perform, please don't hesitate to ask. Thank you in advance! |
|
Hi, roie is just a brand/type of quadrature encoder, since all quadrature encoders are managed in the same way.
I think that this could be a bug in the parser @valegagge Now I'm going to analyze the configuration files... |
|
Hi all, I reckon that we had to do a slight modification in the EMS code. I compared the special version of some years ago, and made the same modification in the latest devel version. Please let me know if it works. It seems to me that without the check removal that I made the board cant complete the hard stop calibration in your hardware configuration. |
|
Hello, thanks for the help! After uploading that EMS firmware to the board and trying again, we obtained the following logs with skipCalibration set to True: This log seems to indicate a deeper problem regarding the Firmware, as indicated by the text: Please advise on how to proceed. Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
We are continuing the 2FOC test for our robot Vizzy. To give context, we were not able to calibrate properly motors connected to 2FOC in our setup (see here. After some debugging at the time in Genoa, @ale-git sent a firmware version to @wevmacedo, which worked. At the time that version was not integrated in the firmware builds.
On our new tests, and we run into a problem: After upgrading the firmware of both EMS4 and 2FOC to V1.23.0, we are not able to find the 2FOC board anymore. Despite following the standard wiring configuration, the EMS4 board fails to detect any connected 2FOC units. The desired system configuration is the following:
Wiring: Configured according to the following schematics (just shows the EMS4 and 2FOC boards):
Our final setup includes two MC4+ and one EMS4 connected in daisy chain. The detection failure is visible in the status output below, which also confirms the firmware versions currently in use:
To isolate the cause, we have conducted the following tests without success:
The 2FOC boards remains unreachable across all configurations. Also, as suggested in the firmware updater documentation (here), we clicked on the Discover button right after clicking on the Restart ETH board, suggested to find hidden CAN boards, but that did not work either.
Let us know what we can do to solve this issue.
cc @JPLDevMaster
All reactions