Announcement

Collapse
No announcement yet.

Update on USB Disconnect Issues (unable to detect USB modules during scan)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • My team is experiencing problems with intermittent USB disconnects. While this does not affect the teleop mode(thanks to the changes in the firmware/SDK this season), it is still affecting the autonomous mode if a drive system motor controller is disconnected precisely when the program calls getCurrentPosition(). In this case, we get the encoder values as '0', which messes up the autonomous program.
    This issue can be mitigated if we can programmatically know whether the getCurrentPosition() returned a value when the motor controller was disconnected. So, my question is: is there an API that allows us to know if a motor controller is connected or not?

    Comment


    • Originally posted by rbFTC View Post
      My team is experiencing problems with intermittent USB disconnects. While this does not affect the teleop mode(thanks to the changes in the firmware/SDK this season), it is still affecting the autonomous mode if a drive system motor controller is disconnected precisely when the program calls getCurrentPosition(). In this case, we get the encoder values as '0', which messes up the autonomous program.
      This issue can be mitigated if we can programmatically know whether the getCurrentPosition() returned a value when the motor controller was disconnected. So, my question is: is there an API that allows us to know if a motor controller is connected or not?
      If getCurrentPosition() returns 0 when the controllers are disconnected, you can probably detect this fact and mitigate appropriately. For example, the ultrasonic sensor may return 255cm when it misses a ping. So in our code, we always remember the last ultrasonic reading and if we see 255cm and is quite different from the last reading, we drop the current reading and just return the last reading.

      Comment


      • Thank you for the suggestion. We implemented it with a minor enhancement, to handle the fact that encoders are genuinely 0 at beginning of the run. So far we do not see any problems.

        Comment


        • Originally posted by rbFTC View Post
          Thank you for the suggestion. We implemented it with a minor enhancement, to handle the fact that encoders are genuinely 0 at beginning of the run. So far we do not see any problems.
          At the beginning of the run when the encoders are genuinely 0, I assume you also initialize your "prevEncoderValue" to zero, then it's not a problem even if you detected zero and replace it with zero. However, you probably need to handle the scenario when you call setMode(STOP_AND_RESET_ENCODER). In that case, you also need to reset your "prevEncoderValue" variable.

          Comment


          • Originally posted by mikets View Post
            At the beginning of the run when the encoders are genuinely 0, I assume you also initialize your "prevEncoderValue" to zero, then it's not a problem even if you detected zero and replace it with zero. However, you probably need to handle the scenario when you call setMode(STOP_AND_RESET_ENCODER). In that case, you also need to reset your "prevEncoderValue" variable.
            We do not use the STOP_AND_RESET_ENCODER mode. We have an ElapsedEncoderCount class similar to ElapsedTime, which can give the difference in encoder counts since it was instantiated/reset.
            In our case prevEncoderValue can be 0 at the beginning because the while loop iterations are much faster than the encoder count updates. So we needed a timer based check to allow the encoder value to be 0 for the first few hundred milli seconds.

            Comment


            • Our team experienced USB issues all season that were very troubling. We had issues with the scanning for devices and connection of Logitech gamepads. Sometimes mid-match, our robot lost connection with various devices and we had to restart it while the match continued. We added 3D printed cases before the season started and we think that eliminated some issues, but we still had lots of problems.
              We have almost no problems before we go to competition, but then we run into these issues all the time at competition. We use the ZTE Speed for both Robot Controller and Driver Station. We don't want to run into these issues next year, but we don't know what to do in order to solve them. We have tried many different things to solve these, but we are willing to try more.

              Comment


              • Version 3.0 of the SDK, out now at ftctechnh/ftc_app in the alpha branch, contains USB resiliency changes specifically to address ESD related disconnects.

                Comment


                • I'm seeing total USB scan failures with the new REV Robotics expansion hub. Details, while experimenting with the hub, two motors, a servo and two sensors just wired up and sitting on a table top:

                  Adding servo support. HiTEC HS-485HB servo initializes (moves to 0.5 position). Then another USB scan failure. Restart both phones: USB scan good. Servo initialized, then another USB scan failure. Made different servo initialization method.
                  Servo stopped working. Try another: nope. Try another port, with change of configuration file: nope. Try the external servo sample: nope. Position report changes, but no actual servo motion. Back to port 0, with change of configuration file: nope. The motor test runs.
                  Run the servo sample with no servo: no voltage on any port 0 pin, or any other servo port pin. Battery and +5V pins correct. Swap hubs, rewrite configuration file: nope. Motor test runs. No voltage on any of swapped-in hub servo pins.

                  Comment


                  • Hi jrasor,

                    If you would please write into our support email support@revbotics.com we'd love to look into this issue with you.

                    Best,
                    Rachel from REV

                    Comment


                    • Thanks, Rachel! I'll write to your support people.
                      Meanwhile, some info from today's logcat. Support will get this.



                      1:07 re-deploy, run again to completion. Log says


                      Time PID TID prior tag message

                      ================================================== ==============

                      13:06:35.249 6469 6639 V LynxPwmOutputController: initializeHardware() mod#=2
                      ... skipped tons of blather about battery checking and garbage collection ...
                      13:06:35.259 6469 6639 W RobotCore: LynxSetPWMEnableCommand not implemented by lynx hw; ignoring. It tried 4 times to do this and LynxSetPWMConfigureCommand. That is definitely no good; servo needs pulse width modulation.

                      [B]

                      Comment

                      Working...
                      X