Go to Post My favorite quote from my 4 year old daughter is, "if it works, who cares?" - drwisley [more]
Home
Go Back   Chief Delphi > FIRST > General Forum
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rating: Thread Rating: 29 votes, 5.00 average. Display Modes
  #181   Spotlight this post!  
Unread 01-03-2015, 12:26
Thad House Thad House is online now
Volunteer, WPILib Contributor
no team (Waiting for 2021)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Thousand Oaks, California
Posts: 1,106
Thad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

We competed with our robot this weekend, and we had more of the navX issues. Probably in 5 or 6 matches, the navX would have the issue where it always returned 0. We were not able to actually figure out if it was the bus issue or an actual issue with the gyro, but have you guys been able to look more into the issue with the busses?
__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.
Reply With Quote
  #182   Spotlight this post!  
Unread 02-03-2015, 00:32
Dunngeon Dunngeon is offline
Pumped
AKA: Ryan
FRC #0973 (Greybots)
Team Role: College Student
 
Join Date: Mar 2014
Rookie Year: 2012
Location: Cal Poly San Luis Obispo
Posts: 299
Dunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond reputeDunngeon has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by Thad House View Post
We competed with our robot this weekend, and we had more of the navX issues. Probably in 5 or 6 matches, the navX would have the issue where it always returned 0. We were not able to actually figure out if it was the bus issue or an actual issue with the gyro, but have you guys been able to look more into the issue with the busses?
Was this the same issue that caused your issues in the semifinal match?

You guys are on labview right?
__________________
(2015-?): 973
(2012-2015): 955
Reply With Quote
  #183   Spotlight this post!  
Unread 02-03-2015, 00:36
Thad House Thad House is online now
Volunteer, WPILib Contributor
no team (Waiting for 2021)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Thousand Oaks, California
Posts: 1,106
Thad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by Dunngeon View Post
Was this the same issue that caused your issues in the semifinal match?

You guys are on labview right?
The issue in the semi final match was caused by either a bad Ethernet cable or something with the field. The gyro issue wasn't super noticeable, as long as we ran the auto we ran all through eliminations. But we still need to get it figured out, because not being able to rotate at times in auto is a bad thing.
__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.
Reply With Quote
  #184   Spotlight this post!  
Unread 02-03-2015, 09:48
Shahil_FRC's Avatar
Shahil_FRC Shahil_FRC is offline
Mentor
FRC #0176 (Aces High)
Team Role: Engineer
 
Join Date: Mar 2015
Rookie Year: 2004
Location: connecticut
Posts: 9
Shahil_FRC is on a distinguished road
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by Thad House View Post
We competed with our robot this weekend, and we had more of the navX issues. Probably in 5 or 6 matches, the navX would have the issue where it always returned 0. We were not able to actually figure out if it was the bus issue or an actual issue with the gyro, but have you guys been able to look more into the issue with the busses?
We had a similar issue this past weekend in our QF2 match in autonomous. We believe there was a spi bus or gyro error which led to a value of 0 being returned continuously. This issue caused our robot to enter an uncontrollable spin and the FTA disabling our robot for the remainder of the round. I feel bad for our alliance partners because this issue did not let us move forward to the SF. We could have returned to open loop control upon start of teleop.....
Reply With Quote
  #185   Spotlight this post!  
Unread 02-03-2015, 13:03
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 356
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by Thad House View Post
We competed with our robot this weekend, and we had more of the navX issues. Probably in 5 or 6 matches, the navX would have the issue where it always returned 0. We were not able to actually figure out if it was the bus issue or an actual issue with the gyro, but have you guys been able to look more into the issue with the busses?
Here's the issues we've seen so far:

(a) [LabView] an I2C bus hang when communicating w/the navX MXP using I2C (after a simulated stage 2 brownout) in a benchtop test configuration and,
(b) [Java] several I2C bus hangs on our competition robot when using the LIDAR Lite on the MXP I2C bus (in this case, we are currently suspicious of a noise issue corrupting a transmission on the I2C bus, but that hasn't been proven yet).

To get data again from these sensors in both cases required a Roborio reboot (restarting the roborio code did not resolve this issue). We've verified that a Roborio reboot does not cause the navX MXP to be rebooted (the MXP 5VDC rail stays powered across the reboot). This, combined w/the fact the issue occurs w/both LabView, and Java points to a Roborio-side problem, and perhaps at a level lower than the Roborio-side libraries. [All testing was performed w/the latest RoboRio firmware/software versions.]

Our next steps are to refine our test setup to find the simplest reproducible case that will hang the I2C bus (to identify the range of the of time during which a Stage 2 brownout can cause the I2C/SPI bus to hang, and try to get some more info on the bus line states and errors received on the RoboRio side) - and also to reproduce the SPI bus hang on the navX MXP you have mentioned. Once we've got that we'll package up the info and send it along to National Instruments.

Until a resolution is found, these are the recommendations:

- We haven't seen the MXP TTL UART communication path to the navX MXP get hung by the disconnect, so using the MXP TTL UART this is recommended for teams experiencing I2C/SPI bus hangs.

- As noted before, if keeping the navX MXP powered in the face of a Roborio Stage 2 brownout is needed, use the USB interface 5VDC/GND leads connected to a 5VDC, 500mA output from the VRM.

One question for you: have you any evidence of brownouts in your Driver Station Logs during the period of time when the I2C bus was hung? Or do you think another condition may be triggering this case?

Last edited by slibert : 02-03-2015 at 13:11.
Reply With Quote
  #186   Spotlight this post!  
Unread 02-03-2015, 15:30
Thad House Thad House is online now
Volunteer, WPILib Contributor
no team (Waiting for 2021)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Thousand Oaks, California
Posts: 1,106
Thad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by slibert View Post
Here's the issues we've seen so far:

(a) [LabView] an I2C bus hang when communicating w/the navX MXP using I2C (after a simulated stage 2 brownout) in a benchtop test configuration and,
(b) [Java] several I2C bus hangs on our competition robot when using the LIDAR Lite on the MXP I2C bus (in this case, we are currently suspicious of a noise issue corrupting a transmission on the I2C bus, but that hasn't been proven yet).

To get data again from these sensors in both cases required a Roborio reboot (restarting the roborio code did not resolve this issue). We've verified that a Roborio reboot does not cause the navX MXP to be rebooted (the MXP 5VDC rail stays powered across the reboot). This, combined w/the fact the issue occurs w/both LabView, and Java points to a Roborio-side problem, and perhaps at a level lower than the Roborio-side libraries. [All testing was performed w/the latest RoboRio firmware/software versions.]

Our next steps are to refine our test setup to find the simplest reproducible case that will hang the I2C bus (to identify the range of the of time during which a Stage 2 brownout can cause the I2C/SPI bus to hang, and try to get some more info on the bus line states and errors received on the RoboRio side) - and also to reproduce the SPI bus hang on the navX MXP you have mentioned. Once we've got that we'll package up the info and send it along to National Instruments.

Until a resolution is found, these are the recommendations:

- We haven't seen the MXP TTL UART communication path to the navX MXP get hung by the disconnect, so using the MXP TTL UART this is recommended for teams experiencing I2C/SPI bus hangs.

- As noted before, if keeping the navX MXP powered in the face of a Roborio Stage 2 brownout is needed, use the USB interface 5VDC/GND leads connected to a 5VDC, 500mA output from the VRM.

One question for you: have you any evidence of brownouts in your Driver Station Logs during the period of time when the I2C bus was hung? Or do you think another condition may be triggering this case?
It would not report data on bootup. And there was no way to check if it was actually reporting data until the field connected, and by that point we had to be off the field. We did have the USB cord plugged into the VRM, so I highly doubt our issues were caused by a brownout. Everytime we tested in the pits it came up correctly. Just on the field it would only come up about 70% of the time.
__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.
Reply With Quote
  #187   Spotlight this post!  
Unread 02-03-2015, 18:28
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 356
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by Thad House View Post
It would not report data on bootup. And there was no way to check if it was actually reporting data until the field connected, and by that point we had to be off the field. We did have the USB cord plugged into the VRM, so I highly doubt our issues were caused by a brownout. Everytime we tested in the pits it came up correctly. Just on the field it would only come up about 70% of the time.
Can you please post the drive station logs for the games of interest, and any other data which might provide some insight as to what factors may be different on the field vs. in the pits?

The logs should point out any power-related issues, and may provide indications as to other factors that are coming into play in the on-field setting.
Reply With Quote
  #188   Spotlight this post!  
Unread 03-03-2015, 07:38
rich2202 rich2202 is offline
Registered User
FRC #2202 (BEAST Robotics)
Team Role: Mentor
 
Join Date: Jan 2012
Rookie Year: 2012
Location: Wisconsin
Posts: 1,251
rich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

We are going to try and incorporate the navX this weekend onto our practice bot. We are going to start with the sample code.

In order to avoid the I2C problem, how do we set it up for UART communications?

Thanks.
Reply With Quote
  #189   Spotlight this post!  
Unread 03-03-2015, 12:12
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 356
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by rich2202 View Post
We are going to try and incorporate the navX this weekend onto our practice bot. We are going to start with the sample code.

In order to avoid the I2C problem, how do we set it up for UART communications?

Thanks.
The navX MXP can communicate via TTL UART, SPI and I2C; selecting the communication path is a software setting. No hardware changes are necessary as long as the "plug-n-play" installation method is used.

For C++ / Java, currently only the TTL UART is supported in software; simply review the respective page on the navX MXP wiki for pointers on getting started.

For LabView, in addition to I2C, both SPi and TTL UART are supported. We have done pretty extensive testing as have others on SPI, and it is the fastest way to communicate with the navX MXP. Our testing on SPI recently has focused on verifying brownout recovery, and for SPI that it is very robust, too. Our current understanding: if you have connected the navX MXP USB to the VRM, the SPI bus is reliable even if there is a RoboRio Stage 2 (or even Stage 3) brownout - and other teams are using this interface w/out problem. If the USB/VRM backup power source is not present, the navX MXP will get reset when a Roborio Stage 2 brownout occurs, but our testing has verified that the RoboRio/navX MXP SPI interface recovers in this case, too.

However, for those that experience trouble w/SPI, the Labview library also has a Serial Example, as well.
Reply With Quote
  #190   Spotlight this post!  
Unread 03-03-2015, 13:31
marshall's Avatar
marshall marshall is offline
My pants are louder than yours.
FRC #0900 (The Zebracorns)
Team Role: Mentor
 
Join Date: Jan 2012
Rookie Year: 2003
Location: North Carolina
Posts: 1,332
marshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond reputemarshall has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by slibert View Post
For LabView, in addition to I2C, both SPi and TTL UART are supported. We have done pretty extensive testing as have others on SPI, and it is the fastest way to communicate with the navX MXP. Our testing on SPI recently has focused on verifying brownout recovery, and for SPI that it is very robust, too. Our current understanding: if you have connected the navX MXP USB to the VRM, the SPI bus is reliable even if there is a RoboRio Stage 2 (or even Stage 3) brownout - and other teams are using this interface w/out problem. If the USB/VRM backup power source is not present, the navX MXP will get reset when a Roborio Stage 2 brownout occurs, but our testing has verified that the RoboRio/navX MXP SPI interface recovers in this case, too.

However, for those that experience trouble w/SPI, the Labview library also has a Serial Example, as well.
Let us know if you have trouble with the LabView library. We're here to help.
Reply With Quote
  #191   Spotlight this post!  
Unread 03-03-2015, 17:06
rich2202 rich2202 is offline
Registered User
FRC #2202 (BEAST Robotics)
Team Role: Mentor
 
Join Date: Jan 2012
Rookie Year: 2012
Location: Wisconsin
Posts: 1,251
rich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond reputerich2202 has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by slibert View Post
For C++ / Java, currently only the TTL UART is supported in software; simply review the respective page on the navX MXP wiki for pointers on getting started.
Since we use C++, I presume the default settings (TTL UART) is what we want.
Reply With Quote
  #192   Spotlight this post!  
Unread 03-03-2015, 20:19
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 356
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by Shahil_FRC View Post
We had a similar issue this past weekend in our QF2 match in autonomous. We believe there was a spi bus or gyro error which led to a value of 0 being returned continuously. This issue caused our robot to enter an uncontrollable spin and the FTA disabling our robot for the remainder of the round. I feel bad for our alliance partners because this issue did not let us move forward to the SF. We could have returned to open loop control upon start of teleop.....
Been thinking about what could be causing this issue.

Over the last few days extensive brownout testing w/SPI has been going on; no matter what scenario we throw at it, the LabView SPI library and the navX MXP keep recovering.

However, there was an update to the navX MXP firmware back on Jan. 20 this year that fixed an issue in the navX MXP where it would hang if it encountered a UART error (which could be caused by electrical noise). Since the UART on the navX MXP is always active (as long as the UART dip switch is enabled), and if you didn't have this firmware fix, the navX MXP could lock up even if SPI is being used.

The latest version of the firmware is v. 1.0.482. You can display the firmware version number using the "Magnetometer Calibration Tool".

If you do have a version earlier than v. 1.0.482, directions for upgrading the navX MXP firmware are here.
Reply With Quote
  #193   Spotlight this post!  
Unread 03-03-2015, 20:59
Thad House Thad House is online now
Volunteer, WPILib Contributor
no team (Waiting for 2021)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Thousand Oaks, California
Posts: 1,106
Thad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by slibert View Post
Been thinking about what could be causing this issue.

Over the last few days extensive brownout testing w/SPI has been going on; no matter what scenario we throw at it, the LabView SPI library and the navX MXP keep recovering.

However, there was an update to the navX MXP firmware back on Jan. 20 this year that fixed an issue in the navX MXP where it would hang if it encountered a UART error (which could be caused by electrical noise). Since the UART on the navX MXP is always active (as long as the UART dip switch is enabled), and if you didn't have this firmware fix, the navX MXP could lock up even if SPI is being used.

The latest version of the firmware is v. 1.0.482. You can display the firmware version number using the "Magnetometer Calibration Tool".

If you do have a version earlier than v. 1.0.482, directions for upgrading the navX MXP firmware are here.
I know ours is 1.0.482, because I2C and SPI didnt work at all in the version that was preloaded, and looking at the flash drive we used to update it was 1.0.482. So at least on our end I don't think thats the issue. But I will double check.

And just to be clear, our issues over the past weekend were all seen on SPI. If it matters, we have the Update rate set to 60hz, The read is getting called once in the teleop loop, which is running every 20ms, and once in periodic tasks in a 20ms loop.
__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.
Reply With Quote
  #194   Spotlight this post!  
Unread 04-03-2015, 02:39
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 356
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by Thad House View Post
I know ours is 1.0.482, because I2C and SPI didnt work at all in the version that was preloaded, and looking at the flash drive we used to update it was 1.0.482. So at least on our end I don't think thats the issue. But I will double check.

And just to be clear, our issues over the past weekend were all seen on SPI. If it matters, we have the Update rate set to 60hz, The read is getting called once in the teleop loop, which is running every 20ms, and once in periodic tasks in a 20ms loop.
Thanks for clarifying, the details help; we've restarted the SPI longevity and brownout tests at 60Hz. They've been running for an hour now with no interruption, but it's a 24 hour test cycle.

Since you haven't sent any logs, I trust you've reviewed this and ruled out any other systemic issues including brownouts, Roborio CPU usage, loss of communication w/driver station, etc..

One other thing to check would be to look for any shorting between any of the pins on the navX MXP SPI connector header. These pins are electrically connected to the same MXP SPI bus pins used to communicate between the RoboRio and the navX MXP. If anything shorts the CS, SCK, MISO or MOSI pins (e.g., "swarf", or bent pins), that could cause bus communication failures. One other team encountered an issue where the Digital I/O pins on the navX MXP pin were accidentally shorted together (the pins were bent), so it's feasible this could be going on in your case.
Reply With Quote
  #195   Spotlight this post!  
Unread 04-03-2015, 02:42
Thad House Thad House is online now
Volunteer, WPILib Contributor
no team (Waiting for 2021)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Thousand Oaks, California
Posts: 1,106
Thad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by slibert View Post
Thanks for clarifying, the details help; we've restarted the SPI longevity and brownout tests at 60Hz. They've been running for an hour now with no interruption, but it's a 24 hour test cycle.

Since you haven't sent any logs, I trust you've reviewed this and ruled out any other systemic issues including brownouts, Roborio CPU usage, loss of communication w/driver station, etc..

One other thing to check would be to look for any shorting between any of the pins on the navX MXP SPI connector header. These pins are electrically connected to the same MXP SPI bus pins used to communicate between the RoboRio and the navX MXP. If anything shorts the CS, SCK, MISO or MOSI pins (e.g., "swarf", or bent pins), that could cause bus communication failures. One other team encountered an issue where the Digital I/O pins on the navX MXP pin were accidentally shorted together (the pins were bent), so it's feasible this could be going on in your case.
I dont have the logs yet. They are still sitting in the trailer. Hopefully I'll have them tomorrow.
__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 16:48.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi