What is the official position on the USB connectivity issues?

[ViperMentor]

The lack of any clear solution for the USB connectivity issues (not being able to reliably detect the MR USB modules) suggests that the official position is that there is no problem - it's all just user error or can be blamed on faulty hardware. So are we to understand that no one is looking into this potentially being a real bug in the RC software?

[nanoninjas]

Hi Viper,

Have you tried the latest SDK from GIT hub? https://github.com/ftctechnh/ftc_app

We are getting a consistent result for the scan when we follow the steps. Let us know if you need the steps our team following.

[dmssargent]

The lack of any clear solution for the USB connectivity issues (not being able to reliably detect the MR USB modules) suggests that the official position is that there is no problem - it's all just user error or can be blamed on faulty hardware. So are we to understand that no one is looking into this potentially being a real bug in the RC software?

Have you tried different USB cables (aka ones that aren't provided to you by FIRST)?

[Tom Eng]

The lack of any clear solution for the USB connectivity issues (not being able to reliably detect the MR USB modules) suggests that the official position is that there is no problem - it's all just user error or can be blamed on faulty hardware. So are we to understand that no one is looking into this potentially being a real bug in the RC software?

ViperMentor,

In our testing we have not seen widespread USB connectivity issues (but that does not mean there is not a problem -we have just not been able to reproduce it reliably). One of the primary differences that I have observed is the USB connections. On our test robots, we made sure we properly secured and strain relieved all of the USB cables and we also secured the phones and electronic modules. We suspect that some of the connectivity issues (when not attributed to faulty/defective hardware) are caused by loose/vibrating cables. In particular the cable that is shipped with the Power MOdule (the one that connects the Android phone's Micro USB port to the Power Module's mini USB port) in our testing seemed to cause problems occasionally, particularly with the early production/prototype cables that were provided to us by Modern Robotics.

dmssargent's suggestion to try new USB cables and adapters is not a bad idea if there budget for additional cables. However, before you replace the cables, I would first make sure the modules are properly mounted to the robot (you don't want them vibrating or moving). I would also make sure the phone is secure and does not vibrate/move too much and I would make sure the cable connections are secure. We often zip tie them so they will not shake loose during a match.

I suspect that in some cases, the connector cable between the phone and the power module might shake loose which can cause comm errors. In our demo and tests, we do not usually use this connector cable that came with the power module. We often use a Monoprice USB Micro OTG adapter (like the kind used for the driver station and game pads) and a Monoprice Mini USB (gold tipped with ferrite chokes) cable. You can use electrical tape to securely fasten the adatper to the USB cable, then strain relieve both ends of the cable so the connection will not come loose during a match.

Unfortunately, the micro USB port on the phone isn't as secure a connector as the RJ-45 style connectors of the LEGO NXT, but it is the type of connector that we have to work with (by law, smartphones in the European Union and other countries are required to have this type of connector to reduce the amount of electronic waste produced annually).

Here is a link to the Monoprice cables we typically use for our test and demo robots:

Monoprice micro USB OTG adapter:

http://www.monoprice.com/product?p_id=9724

Here's the monoprice mini usb cable we used to connect the phone to the OTG adapter (and then to the power module):

http://www.monoprice.com/product?c_i...seq=1&format=2

We also use the mini usb cable listed above (in different lengths) to connect the USB modules (servo, DC motor, legacy, and core device interface module) to the Power Module.

Hope this info helps.

Tom

[korimako]

Have you tried different USB cables (aka ones that aren't provided to you by FIRST)?

Have these cables been known bad? I was watching the kids drive around and things stopped mid stream. Robot controller couldn't find USB devices, and the WiFi direct was lost. A plethora of rebooting/restarting didn't help much. Finally turned everything OFF, and that allowed us to reconnect and run. This was with the current SDK they had just installed, a basic K9 type bot, with only the reversed motor changed (Andymark motors). I saw the whole episode , there wasn't any severe driving involved, just going straight across the field and stop. Worrying if that'll happen in competitions. It'll all get thrown on the teams shoulders, so lets hope these issues don't plague us. It did reconnect with no cable wiggling, so that wasn't the issue.

[Tom Eng]

Have these cables been known bad? I was watching the kids drive around and things stopped mid stream. Robot controller couldn't find USB devices, and the WiFi direct was lost. A plethora of rebooting/restarting didn't help much. Finally turned everything OFF, and that allowed us to reconnect and run. This was with the current SDK they had just installed, a basic K9 type bot, with only the reversed motor changed (Andymark motors). I saw the whole episode , there wasn't any severe driving involved, just going straight across the field and stop. Worrying if that'll happen in competitions. It'll all get thrown on the teams shoulders, so lets hope these issues don't plague us. It did reconnect with no cable wiggling, so that wasn't the issue.

korimako,

We haven't confirmed the cause of the problem yet so I don't think we can definitely say that the cables are an issue. We (FIRST) have seen, however, some cases where it does appear that loose cables might have been the potential problem. Swapping them out and then strain relieving them really made an improvement. In one instance, we simply just had to replace the Modern Robotics (MR) cable that connected the phone to the Power Module. We replaced it with a Monoprice USB mini type B cable and a Monoprice USB Micro OTG adapter and the team's problem (phone would not detect their legacy module) went away. In a second, recent incident, we had a bot that was intermittently experiencing lost communication with the legacy module during a demo. The robot would just stop, even when they were not driving aggressively (for example, they just drove across the floor slowly at about 3 feet in front of me when it stopped). In that case we replaced the MR USB cables with brand new Monoprice ones and we used the Monoprice USB Micro OTG adapter and Monoprice USB mini type b cable instead of the integrated MR cable (the one that connects the phone to the Power module) and then we strain relieved the cables and the team's problems went away. Prior to the switch the team was experiencing loss of communications with their legacy module intermittently and pretty frequently. After replacing the cables and strain relieving them they did not report any of this type of problem for the rest of the day.

In your case, with the robot just stopping while the team was driving it across the field (not even very aggressively) it sounds very similar to the most recent problem that I observed first hand. It might be a connection issue.

Do you still have access to the robot and the Android devices? If so, would you be able to pull the logfiles and scan through them and go to the date and time where the stops occurred? If you can cut and paste the logcat statements from a little before through a little after the event it would help us gain insight into the problem.

Tom

[Alec]

It sounds like the MR issues being reported are ESD related. Either the MR modules or the ZTE Speed, or both, are inadequately protected against ESD.

ESD will lock up the FTDI chip or the MR microcontroller. The only way to recover is to power cylcle the MR modules.

In some cases a USB device will appear as though it is online and working fine to the USB driver when in fact the USB device is actually locked up due to ESD.

[Tom Eng]

It sounds like the MR issues being reported are ESD related. Either the MR modules or the ZTE Speed, or both, are inadequately protected against ESD.

ESD will lock up the FTDI chip or the MR microcontroller. The only way to recover is to power cylcle the MR modules.

In some cases a USB device will appear as though it is online and working fine to the USB driver when in fact the USB device is actually locked up due to ESD.

Hi Alec,

I don't know if the issue is ESD related, but in our testing we did not see ESD related issues. I've posted an update to the USB issues on this forum. MR has informed us that they suspect that there is a potential hardware issue with some of their power modules which might require that a part be replaced to correct the intermittent comm errors.

http://ftcforum.usfirst.org/showthre...s-during-scan)

Tom

[korimako]

korimako,

Do you still have access to the robot and the Android devices? If so, would you be able to pull the logfiles and scan through them and go to the date and time where the stops occurred? If you can cut and paste the logcat statements from a little before through a little after the event it would help us gain insight into the problem.

Tom

it had already been a while, and I wasn't on the lookout at the time, so not even sure when that occurred. Would it be possible for you to write an app/opmode that we can fire off afterwards that sends the logfile somewhere, to us, or you?

[dlevy]

it had already been a while, and I wasn't on the lookout at the time, so not even sure when that occurred. Would it be possible for you to write an app/opmode that we can fire off afterwards that sends the logfile somewhere, to us, or you?

Don't need to have a new opmode.
Just change com.qualcomm.ftccommon.ViewLogsActivity to include the following:

"ViewLogsActivity" is currently called from the RC app's

Intent intent = new Intent(Intent.ACTION_SEND);
intent.putExtra(Intent.EXTRA_SUBJECT, "Error Log reported");
intent.putExtra(Intent.EXTRA_EMAIL, new String[]{ <email address>});
intent.putExtra(Intent.EXTRA_TEXT, "Please see attached file);
intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File(<path to logfile>)));
intent.setType("text/plain");