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

  • jrasor
    replied
    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]

    Leave a comment:


  • Rachel
    replied
    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

    Leave a comment:


  • jrasor
    replied
    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.

    Leave a comment:


  • skatefriday
    replied
    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.

    Leave a comment:


  • Stephen
    replied
    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.

    Leave a comment:


  • rbFTC
    replied
    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.

    Leave a comment:


  • mikets
    replied
    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.

    Leave a comment:


  • rbFTC
    replied
    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.

    Leave a comment:


  • mikets
    replied
    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.

    Leave a comment:


  • rbFTC
    replied
    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?

    Leave a comment:


  • FTC12070
    replied
    Thanks Alec!


    Crystal Kolarik
    McClintock Middle School Robotics Mentor



    Originally posted by Alec View Post
    We are all on the same team, so I'm glad my PSA is benefiting our teams.

    Send an email to support@modernroboticsinc.com, and they will guide you through the process of getting the modules upgraded free of charge.

    Leave a comment:


  • FTC4160
    replied
    Our team uses custom length wires. We have found that power poles will, if not done 100% correctly, experience random drops in power. The light on the controller will, of course, indicate whether or not it is receiving power, but only a brief interruption of power can cause a disconnection. We had a connection which only failed twice in about a week, further investigation revealed the powerpole crimps were inserted upside down.

    Leave a comment:


  • patfanman101
    replied
    Hi guys. So my team has an issue where the RC phone has the error, "unable to find DC Motor Controller (********)" At first, the problem could be fixed with disconnecting and re plugging in the motor controller's power cord. At our last competition, we had to unplug and re-plug around 15-20 times! I know it isn't the first problem, because it happens every time we start the robot. It is not the second problem, because our battery can be fully charged at it will not work. Which leads me to believe the problem is option 3. I want to make sure that there isn't another problem that I am forgetting. Is there anything else I can do to fix this problem? Any help welcome.

    Leave a comment:


  • Alec
    replied
    Originally posted by FTC12070 View Post
    Thanks Alec! We are a rookie Tech Challenge team that just purchased our kit last month, and after suffering with the scanning issues, found your post. The Core Device Discovery tool confirmed that we have the older firmware version on our modules. How do we send them in to be upgraded free of charge?

    Thanks so much!


    Crystal Kolarik
    McClintock Middle School Robotics Mentor
    We are all on the same team, so I'm glad my PSA is benefiting our teams.

    Send an email to support@modernroboticsinc.com, and they will guide you through the process of getting the modules upgraded free of charge.

    Leave a comment:


  • 5294-jjkd
    replied
    The update form/process is discussed here: http://modernroboticsinc.com/firmware-update

    You may wish to contact Modern Robotics first to confirm/let them know you are sending them modules from a this-season purchase, contact info here: http://modernroboticsinc.com/contactus

    Leave a comment:

Working...
X