Go to Post Thanks GDC for opening a can of Chuck Norris Brain Hurt - Garrett.d.w [more]
Home
Go Back   Chief Delphi > Technical > Technical Discussion
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
  #46   Spotlight this post!  
Unread 28-07-2015, 23:56
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 803
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: Which sensors should be used throughout the robot?

Quote:
Originally Posted by Necroterra View Post
What kind of delay is there on the interrupt system if you are running everything default, no thread priorities, on Java? I feel like 0.1-1 ms is more than a fast enough response time for virtually every FRC application, considering that other methods like CAN can have >10ms of cycle time, but I know think I remember hearing that you guys had overclocked the CAN rates too.
Most teams will never notice latency issues. 971 happens to be special in that we design complicated systems which require tight timing to make work at the levels of precision and reliability that we target.

Tom from 254 reports that he was able to get it down to ~2 ms in Java. I have never used Java on a FRC robot, so I can't confirm or deny. When 254 was doing thread.sleep, to time a loop in a separate thread, he reported up to 0.25 seconds of latency.

Latency can be modeled as another source of noise. We used the fast response time to zero our claws in 2014, and other systems this year. Our control loops could hit somewhere in the order of +- 0.002 radians, and measure another order of magnitude more precise than that. If you are zeroing at 2 rad/sec, that means that you are going to add 0.002 rad of noise per millisecond of error. To hit 0.0002 rad/sec (below your positioning accuracy by an order of magnitude), you need to move at either 0.2 rad/sec or have less latency.

I'm not sure where you heard the rumor that we over-clocked CAN, but we chose to not use CAN after benchmarking the latency of it and looking at the other options (and it being new). We couldn't figure out how to synchronize our control loops with the CAN send cycle, and after hooking up some external CAN monitoring equipment from my work, saw high peak latency on the bus. PWM is a known quantity, so we moved on. Reading sensors over CAN has the same issues you described, so we kept them connected to the FPGA so we could read them faster. (The FPGA is memory-mapped into the process's address space, which makes accesses fast.)

Quote:
Originally Posted by Necroterra View Post
Also, I'm not super familiar with JNI or the fancier parts of WPILIB, but it looks to me like you just pass your Handler function into the FGPA, which I assume would be watching it on a specified thread already. It might be different if you are working with WPILIBC though, since WPILIBJ just stops once you hit the native calls and I don't remember where/if you can look up with implementation.
The WPILib C implementation uses NI's library, which spawns a thread, does an ioctl until the interrupt happens, and then calls a handler function. Similar to you, I don't know how that interfaces with the JNI/Java code and the GC.
  #47   Spotlight this post!  
Unread 29-07-2015, 01:09
Necroterra's Avatar
Necroterra Necroterra is offline
Registered User
FRC #4183 (Bit Buckets)
Team Role: Programmer
 
Join Date: Jan 2015
Rookie Year: 2015
Location: Tucson
Posts: 26
Necroterra will become famous soon enough
Re: Which sensors should be used throughout the robot?

Quote:
Originally Posted by AustinSchuh View Post
...
I see now why such accuracy would be necessary, we never aimed for anywhere close to that level of detail.

So if I understand this DMA thing, the FGPA reads off the sensor values on an event happening, and the relatively slow accessing of the memory can be done later? Wouldn't that still give you inaccurate data unless you added on the expected change since it was read?

Also, by upstreamed, do you mean it will be part of default WPILIB?

Also, I read about CAN a while ago and iirc it isn't designed to have a specific frequency of changing the message frame, it just does it whenever it has time within a certain range. You can mess with the frequencies, but then you run the risk of maxing out the buffer. I would guess that it's intended for more complex data communication, and PWM is definitely better for a sensor that outputs a single value.

As for the JNI bindings, wpilibJ loads up a library called "libwpilibJavaJNI.so", which I would assume is either the NI library or a bridge to it.
__________________

2015 Arizona East - Regional Winners, Creativity Award
  #48   Spotlight this post!  
Unread 29-07-2015, 01:21
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: Which sensors should be used throughout the robot?

Quote:
Originally Posted by Necroterra View Post
I see now why such accuracy would be necessary, we never aimed for anywhere close to that level of detail.

So if I understand this DMA thing, the FGPA reads off the sensor values on an event happening, and the relatively slow accessing of the memory can be done later? Wouldn't that still give you inaccurate data unless you added on the expected change since it was read?

Also, by upstreamed, do you mean it will be part of default WPILIB?

Also, I read about CAN a while ago and iirc it isn't designed to have a specific frequency of changing the message frame, it just does it whenever it has time within a certain range. You can mess with the frequencies, but then you run the risk of maxing out the buffer. I would guess that it's intended for more complex data communication, and PWM is definitely better for a sensor that outputs a single value.

As for the JNI bindings, wpilibJ loads up a library called "libwpilibJavaJNI.so", which I would assume is either the NI library or a bridge to it.
All of the WPILib code is public, but its kind of a pain to find. It also uses the NI implementation. This is the callback that gets called by the interrupt.

Code:
void interruptHandler(uint32_t mask, void *data) {
	INTERRUPTJNI_LOG(logDEBUG) << "Calling INTERRUPTJNI interruptHandler";
	InterruptHandlerParam *param = static_cast<InterruptHandlerParam *>(data);

	INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam Ptr = " << param;
	INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam->obj = " << param->handler_obj;
	INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam->param = " << param->param;

	//Because this is a callback in a new thread we must attach it to the JVM
	JNIEnv *env;
	jint rs = jvm->AttachCurrentThread((void**)&env, NULL);
	assert (rs == JNI_OK);
	INTERRUPTJNI_LOG(logDEBUG) << "Attached to thread";

	env->CallVoidMethod(param->handler_obj, param->mid, mask, param->param);
	if (env->ExceptionCheck()) {
		env->ExceptionDescribe();
	}

	rs = jvm->DetachCurrentThread();
	assert (rs == JNI_OK);
	INTERRUPTJNI_LOG(logDEBUG) << "Leaving INTERRUPTJNI interruptHandler";
So any slowness with interrupts would happen in this function. My guess would be that it attaches the interrupt thread to a new JVM thread, and then gets sent to the JVM scheduler, which doesnt have to start the thread in Java immediately.
__________________
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.
  #49   Spotlight this post!  
Unread 29-07-2015, 08:52
Gdeaver Gdeaver is online now
Registered User
FRC #1640
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 2001
Location: West Chester, Pa.
Posts: 1,370
Gdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond repute
Re: Which sensors should be used throughout the robot?

For a gyro-IMU-AHRS solution we used the NavX MXP in 2015. It has worked for us, but we have had problems. We bought 2 boards. One has failed, will not initialize. We have had problems with the IO ports. Some are unusable and others are not reliable. We mounted our Roborio vertical. This forced us to use a cable between the Rio and the Navx. We use the NavX for 2 tasks. The NavX tells us which way our robot is pointing. (not which way our robot is moving). Second, it tells us if the robot is tilting. We fell over 3 times in competitions this year. We use the navx to stop us from tipping. If the the angle of tilt goes beyond x degrees, reverse the drive motors. It works.
For 2016 we are looking for a better IMU. We recently purchased a Arduino Shield with a Bosch BMO055 orientation sensor. It has a 3 axis accelerometer, gyro and magnetometer. Plus a Arm cortex M0 core running fusion code. Easy set up. Initialize the I2C port, write to a few registers and its running. We bought the Arduino shield for testing. Will use the Adafruit board on the robot if we go with it. Only have 1 hour of testing. Gyro, accelerometer fusion looks rock solid. Add in the mag and it is not good. Interesting is the linear acceleration output. It's a little noisy but with a little clean up could give direction of motion. Not suitable for distance. Better than the Invensense outputs. Looks good but you never know until it's on the robot.
  #50   Spotlight this post!  
Unread 29-07-2015, 09:20
marshall's Avatar
marshall marshall is online now
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,330
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: Which sensors should be used throughout the robot?

Quote:
Originally Posted by Gdeaver View Post
For a gyro-IMU-AHRS solution we used the NavX MXP in 2015. It has worked for us, but we have had problems. We bought 2 boards. One has failed, will not initialize. We have had problems with the IO ports. Some are unusable and others are not reliable. We mounted our Roborio vertical. This forced us to use a cable between the Rio and the Navx. We use the NavX for 2 tasks. The NavX tells us which way our robot is pointing. (not which way our robot is moving). Second, it tells us if the robot is tilting. We fell over 3 times in competitions this year. We use the navx to stop us from tipping. If the the angle of tilt goes beyond x degrees, reverse the drive motors. It works.
For 2016 we are looking for a better IMU. We recently purchased a Arduino Shield with a Bosch BMO055 orientation sensor. It has a 3 axis accelerometer, gyro and magnetometer. Plus a Arm cortex M0 core running fusion code. Easy set up. Initialize the I2C port, write to a few registers and its running. We bought the Arduino shield for testing. Will use the Adafruit board on the robot if we go with it. Only have 1 hour of testing. Gyro, accelerometer fusion looks rock solid. Add in the mag and it is not good. Interesting is the linear acceleration output. It's a little noisy but with a little clean up could give direction of motion. Not suitable for distance. Better than the Invensense outputs. Looks good but you never know until it's on the robot.
Scott from Kauai Labs has implemented some changes for the NavX recently that help significantly with mounting the sensor and improving the stability of readings. Also, you should contact him about the failed board, he might be able to help revive it. He's a really nice guy and he takes care of his customers. We ordered 2 and only received 1 but he made it right and it's been a good friendship since.

I wasn't aware of the Bosch sensor but it looks cool. Hopefully we'll see some additional MXP boards based around more sensors for this coming year.
__________________
"La mejor salsa del mundo es la hambre" - Miguel de Cervantes
"The future is unwritten" - Joe Strummer
"Simplify, then add lightness" - Colin Chapman
  #51   Spotlight this post!  
Unread 29-07-2015, 12:38
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: Which sensors should be used throughout the robot?

Quote:
Originally Posted by Gdeaver View Post
For a gyro-IMU-AHRS solution we used the NavX MXP in 2015. It has worked for us, but we have had problems. We bought 2 boards. One has failed, will not initialize. We have had problems with the IO ports. Some are unusable and others are not reliable. We mounted our Roborio vertical. This forced us to use a cable between the Rio and the Navx. We use the NavX for 2 tasks. The NavX tells us which way our robot is pointing. (not which way our robot is moving). Second, it tells us if the robot is tilting. We fell over 3 times in competitions this year. We use the navx to stop us from tipping. If the the angle of tilt goes beyond x degrees, reverse the drive motors. It works.
For 2016 we are looking for a better IMU. We recently purchased a Arduino Shield with a Bosch BMO055 orientation sensor. It has a 3 axis accelerometer, gyro and magnetometer. Plus a Arm cortex M0 core running fusion code. Easy set up. Initialize the I2C port, write to a few registers and its running. We bought the Arduino shield for testing. Will use the Adafruit board on the robot if we go with it. Only have 1 hour of testing. Gyro, accelerometer fusion looks rock solid. Add in the mag and it is not good. Interesting is the linear acceleration output. It's a little noisy but with a little clean up could give direction of motion. Not suitable for distance. Better than the Invensense outputs. Looks good but you never know until it's on the robot.
Please do send in the board that won't initialize, we'll get it replaced for you. Just send it and return address info to:

Kauai Labs
2371E Nimualu Road
Lihue, HI 96766

The updated firmware (it'll be loaded on your replacement board) includes the new Omnimount feature which enables vertical, horizontal and upside-down mounting, and has some reliability improvements. The addressing of the Digital IO pins has given folks some trouble, it has gaps in the address space, documented on this page. If you have details on a port that isn't working, please send that information along, too.

We're getting ready also to release new Java/C++ Libaries w/SPI support at 2Mhz, with that enhancement the measurement latencies and RoboRIO CPU usage are very low.

Which board are you are using w/the Bosch sensor? I'd like to compare the linear acceleration values it generates with those from the navX MXP. I'd agree Invensense has some work to do on accelerometer noise levels on the MPU-9250, but wasn't aware the Bosch sensor specs were that much better, am very interested to hear your findings.

Thanks,

- scott
  #52   Spotlight this post!  
Unread 29-07-2015, 12: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: Which sensors should be used throughout the robot?

Quote:
Originally Posted by slibert View Post
Please do send in the board that won't initialize, we'll get it replaced for you. Just send it and return address info to:

Kauai Labs
2371E Nimualu Road
Lihue, HI 96766

The updated firmware (it'll be loaded on your replacement board) includes the new Omnimount feature which enables vertical, horizontal and upside-down mounting, and has some reliability improvements. The addressing of the Digital IO pins has given folks some trouble, it has gaps in the address space, documented on this page. If you have details on a port that isn't working, please send that information along, too.

We're getting ready also to release new Java/C++ Libaries w/SPI support at 2Mhz, with that enhancement the measurement latencies and RoboRIO CPU usage are very low.

Which board are you are using w/the Bosch sensor? I'd like to compare the linear acceleration values it generates with those from the navX MXP. I'd agree Invensense has some work to do on accelerometer noise levels on the MPU-9250, but wasn't aware the Bosch sensor specs were that much better, am very interested to hear your findings.

Thanks,

- scott
Do we have any idea if FIRST is going to fix the FPGA bug with SPI and I2C? It was nice finding a workaround, but it would be even better if they would fix the MXP ports.
__________________
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.
  #53   Spotlight this post!  
Unread 29-07-2015, 13:39
Ari423's Avatar
Ari423 Ari423 is offline
LabVIEW aficionado and robot addict
AKA: The guy with the yellow hat
FRC #5987 (Galaxia)
Team Role: Mentor
 
Join Date: Mar 2015
Rookie Year: 2012
Location: Haifa, Israel
Posts: 656
Ari423 has much to be proud ofAri423 has much to be proud ofAri423 has much to be proud ofAri423 has much to be proud ofAri423 has much to be proud ofAri423 has much to be proud ofAri423 has much to be proud ofAri423 has much to be proud ofAri423 has much to be proud of
Re: Which sensors should be used throughout the robot?

Quote:
Originally Posted by slibert View Post
The updated firmware (it'll be loaded on your replacement board) includes the new Omnimount feature which enables vertical, horizontal and upside-down mounting, and has some reliability improvements. The addressing of the Digital IO pins has given folks some trouble, it has gaps in the address space, documented on this page. If you have details on a port that isn't working, please send that information along, too.
Will the new firmware be available to put on previous NavX boards or will teams who want the Omnimount feature be required to buy a new one? Hopefully it is the former.
__________________
2017-present: Mentor FRC 5987
2017-present: CSA for FIRST in Israel
2012-2016: Member FRC 423
2013: Programmer
2014: Head Programmer, Wiring
2015: Head Programmer, Wiring
2016: Captain, Head Programmer, Wiring, Manipulator, Chassis, CAD, Business, Outreach (basically everything)


  #54   Spotlight this post!  
Unread 29-07-2015, 14:53
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: Which sensors should be used throughout the robot?

Quote:
Originally Posted by Thad House View Post
Do we have any idea if FIRST is going to fix the FPGA bug with SPI and I2C? It was nice finding a workaround, but it would be even better if they would fix the MXP ports.
No word on a resolution by NI - it's likely been because we can't give them a reproducible case; Joe Hershberger of NI has indicated suspicion of a lock not being held correctly during opening of the MXP port, but that hasn't been confirmed.

However in testing it's been discovered that the various communication peripherals on the navX MXP are experiencing bus errors sometimes when the RoboRio is starting up (e.g., upon initial power up, and when "Reboot RobRIO" is selected in the driver station, but not when restarting the robot code). In these cases, a few seconds after the reboot occurs (about one in every ten times) I2C circuits on the navX (including - notably - the internal I2C bus which communicates with the MPU-9250) experience bus errors. My suspicion is that problems occur when the robot app opens a MXP port before the RoboRIO FPGA code that manages the MXP port has completed initialization, and the result is the navX MXP experiences random noise during that time. And the fact that an internal (non-MXP) I2C bus is experiencing error implies the noise is on the power/ground which are used to pull up the internal I2C bus lines. I haven't got it captured on a scope yet, but my hunch is there's a noisy MXP ground sometimes during RoboRIO startup.

[These errors can cause navX MXP comm to the MPU-9250 to lockup. The visible symptom of the internal I2C bus lockup is that only one of the two Green LEDs on the navX MXP will be lit up (in normal operation, both LEDs should be on).]

So the reasonable conclusion is that when using MXP-based SPI/I2C, the navX was being exposed to more of these glitches than when using non-MXP communication, and every now and then could no longer talk to the MPU-9250.

The recent navX MXP firmware has added code to detect these bus errors and reset the affected communication peripherals. In testing, we were able to reproduce the error, and demonstrate successful recovery by the navX MXP firmware. Based on that, I believe the latest navX MXP firmware is resilient to these transients. However these transients could impact other MXP devices too, so the plan is to document this and send the findings to NI and to the ChiefDelphi community.

I'll send out a general update to ChiefDelphi once the latest navX MXP firmware has passed all our tests and is ready for release; I'd recommend retesting at that time, believing the above was the root cause for the sporadic startup failures you saw.
  #55   Spotlight this post!  
Unread 29-07-2015, 14:54
marshall's Avatar
marshall marshall is online now
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,330
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: Which sensors should be used throughout the robot?

Quote:
Originally Posted by Ari423 View Post
Will the new firmware be available to put on previous NavX boards or will teams who want the Omnimount feature be required to buy a new one? Hopefully it is the former.
I didn't carry it out but it was an easy upgrade for ours. I'll let Scott elaborate on the process.
__________________
"La mejor salsa del mundo es la hambre" - Miguel de Cervantes
"The future is unwritten" - Joe Strummer
"Simplify, then add lightness" - Colin Chapman
  #56   Spotlight this post!  
Unread 29-07-2015, 14:58
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: Which sensors should be used throughout the robot?

Quote:
Originally Posted by Ari423 View Post
Will the new firmware be available to put on previous NavX boards or will teams who want the Omnimount feature be required to buy a new one? Hopefully it is the former.
The latest installation program will include a firmware installation utility, so that existing navX users can upgrade their existing boards to the new firmware. With this new utility, the firmware upgrade process is pretty straightforward.

An announcement will be posted on ChiefDelphi once the released version of this new firmware and the firmware update is ready for public consumption.
  #57   Spotlight this post!  
Unread 29-07-2015, 16:06
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: Which sensors should be used throughout the robot?

Quote:
Originally Posted by slibert View Post
No word on a resolution by NI - it's likely been because we can't give them a reproducible case; Joe Hershberger of NI has indicated suspicion of a lock not being held correctly during opening of the MXP port, but that hasn't been confirmed.

However in testing it's been discovered that the various communication peripherals on the navX MXP are experiencing bus errors sometimes when the RoboRio is starting up (e.g., upon initial power up, and when "Reboot RobRIO" is selected in the driver station, but not when restarting the robot code). In these cases, a few seconds after the reboot occurs (about one in every ten times) I2C circuits on the navX (including - notably - the internal I2C bus which communicates with the MPU-9250) experience bus errors. My suspicion is that problems occur when the robot app opens a MXP port before the RoboRIO FPGA code that manages the MXP port has completed initialization, and the result is the navX MXP experiences random noise during that time. And the fact that an internal (non-MXP) I2C bus is experiencing error implies the noise is on the power/ground which are used to pull up the internal I2C bus lines. I haven't got it captured on a scope yet, but my hunch is there's a noisy MXP ground sometimes during RoboRIO startup.

[These errors can cause navX MXP comm to the MPU-9250 to lockup. The visible symptom of the internal I2C bus lockup is that only one of the two Green LEDs on the navX MXP will be lit up (in normal operation, both LEDs should be on).]

So the reasonable conclusion is that when using MXP-based SPI/I2C, the navX was being exposed to more of these glitches than when using non-MXP communication, and every now and then could no longer talk to the MPU-9250.

The recent navX MXP firmware has added code to detect these bus errors and reset the affected communication peripherals. In testing, we were able to reproduce the error, and demonstrate successful recovery by the navX MXP firmware. Based on that, I believe the latest navX MXP firmware is resilient to these transients. However these transients could impact other MXP devices too, so the plan is to document this and send the findings to NI and to the ChiefDelphi community.

I'll send out a general update to ChiefDelphi once the latest navX MXP firmware has passed all our tests and is ready for release; I'd recommend retesting at that time, believing the above was the root cause for the sporadic startup failures you saw.
Ah. Luckily we have the workaround, and with the new firmware allowing sideways mounting, we will probably just use that from the start. We wouldn't want to take the risk of the gyro failing mid competition again, and would rather run a few extra cables, especially since we have to run USB for power anyway.
__________________
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.
  #58   Spotlight this post!  
Unread 29-07-2015, 16:19
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,537
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
Re: Which sensors should be used throughout the robot?

Quote:
Originally Posted by slibert View Post
No word on a resolution by NI - it's likely been because we can't give them a reproducible case; Joe Hershberger of NI has indicated suspicion of a lock not being held correctly during opening of the MXP port, but that hasn't been confirmed.

However in testing it's been discovered that the various communication peripherals on the navX MXP are experiencing bus errors sometimes when the RoboRio is starting up (e.g., upon initial power up, and when "Reboot RobRIO" is selected in the driver station, but not when restarting the robot code). In these cases, a few seconds after the reboot occurs (about one in every ten times) I2C circuits on the navX (including - notably - the internal I2C bus which communicates with the MPU-9250) experience bus errors. My suspicion is that problems occur when the robot app opens a MXP port before the RoboRIO FPGA code that manages the MXP port has completed initialization, and the result is the navX MXP experiences random noise during that time. And the fact that an internal (non-MXP) I2C bus is experiencing error implies the noise is on the power/ground which are used to pull up the internal I2C bus lines. I haven't got it captured on a scope yet, but my hunch is there's a noisy MXP ground sometimes during RoboRIO startup.

[These errors can cause navX MXP comm to the MPU-9250 to lockup. The visible symptom of the internal I2C bus lockup is that only one of the two Green LEDs on the navX MXP will be lit up (in normal operation, both LEDs should be on).]

So the reasonable conclusion is that when using MXP-based SPI/I2C, the navX was being exposed to more of these glitches than when using non-MXP communication, and every now and then could no longer talk to the MPU-9250.

The recent navX MXP firmware has added code to detect these bus errors and reset the affected communication peripherals. In testing, we were able to reproduce the error, and demonstrate successful recovery by the navX MXP firmware. Based on that, I believe the latest navX MXP firmware is resilient to these transients. However these transients could impact other MXP devices too, so the plan is to document this and send the findings to NI and to the ChiefDelphi community.

I'll send out a general update to ChiefDelphi once the latest navX MXP firmware has passed all our tests and is ready for release; I'd recommend retesting at that time, believing the above was the root cause for the sporadic startup failures you saw.
It's interesting that you have problems with the MXP. We experienced exactly the opposite. Our Lidar would simply not function on the dedicated I2C port on the roborio, but worked perfectly on the MXP port with the exact same code.

Anyway, this thread has been outstanding so far. I've always had trouble finding inexpensive sensors that work well for our system and have relied on what I've seen on other robots. For instance, one of our favorites was always the sick ZL1 series that we ordered from automationpartsexpress.com for under $40 (credit to 33 and Jim for finding them), but they seem to be out of business.

It'd be fantastic if people kept suggesting sensors they use. So far, I have this list:

Sensor Type Part # Website

Encoder, multiple shaft, multiple counts per rev AMT10-V http://www.cui.com/product/component...ar/amt10-v-kit

Magnetic reed switch / position switch 59140-010-ND http://www.digikey.com/product-detai...0-010-ND/43977

IR reflective 42EF Rightsight http://ab.rockwellautomation.com/Sen...tSight-Sensors

IR Reflective / cheap 30 CM E18-B03P1 http://www.amazon.com/6-36V-Photoele...lectric+sensor

Hall effect switch / position switch WCP-0971 http://www.wcproducts.net/sensors

Hall effect switch / position switch MC1104 http://www.amazon.com/Effect-Sensor-...y+Switc h+NPN

SICK photoelectric Z series IR sensors ZL1-E2415 Not available

So we've got IR reflective and hall effect reed/limit switches. What about cheap through beams (that aren't garage door sensors)? One of the nice features on the Allen Bradley RightSight was the manual adjustability so that it would work with reflectors, or even colored tape. It was also capable of 10000+ samples / second. What else is out there with those capabilities?

Last edited by Tom Line : 29-07-2015 at 16:21.
  #59   Spotlight this post!  
Unread 29-07-2015, 16:48
AllenGregoryIV's Avatar
AllenGregoryIV AllenGregoryIV is offline
Engineering Coach
AKA: Allen "JAG" Gregory
FRC #3847 (Spectrum)
Team Role: Coach
 
Join Date: Jul 2008
Rookie Year: 2003
Location: Texas
Posts: 2,562
AllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond repute
Send a message via AIM to AllenGregoryIV
Re: Which sensors should be used throughout the robot?

I'd go back through this thread as well.

http://www.chiefdelphi.com/forums/sh...d.php?t=117219

Some very good suggestions by a lot teams.
__________________

Team 647 | Cyber Wolf Corps | Alumni | 2003-2006 | Shoemaker HS
Team 2587 | DiscoBots | Mentor | 2008-2011 | Rice University / Houston Food Bank
Team 3847 | Spectrum | Coach | 2012-20... | St Agnes Academy
LRI | Alamo Regional | 2014-20...
"Competition has been shown to be useful up to a certain point and no further, but cooperation, which is the thing we must strive for today, begins where competition leaves off." - Franklin D. Roosevelt
  #60   Spotlight this post!  
Unread 30-07-2015, 10:02
carpedav000's Avatar
carpedav000 carpedav000 is offline
Studenting is hard, but worth it!
AKA: David Carpenter
no team (Jerry-Rigg school of DuctTapeology)
Team Role: Mechanical
 
Join Date: Jan 2015
Rookie Year: 2010
Location: Greenwood, IN
Posts: 477
carpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant futurecarpedav000 has a brilliant future
Re: Which sensors should be used throughout the robot?

I'm not a programmer, but I would say a gyro would be very useful if you want to drive field-oriented.
Closed Thread


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 12:57.

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