Go Back   VEX Forum > Community > General Forum

General Forum Open Discussion of the VEX Robotics System that can be answered by anyone. VEX Robotics Engineers will not answer questions posted here; see Official VEX Technical Support below.

Reply
 
Thread Tools
  #1  
Old 04-12-2012, 05:59 AM
tutman96's Avatar
tutman96 tutman96 is offline
Senior Member
VEX # 675A
 
Join Date: May 2011
Location: Duluth, GA
Posts: 384
Images: 1
Exclamation WARNING Using the New Integrated Encoders on Worlds Firmware

I have recently encountered a problem running the I2C encoders. At random times our cortex suddenly "bugs out". The VEXnet light shows that it is still connected but the robot light shows a "User Microprocessor Error". When this happens, the motors keep going the same power that they were when it "bugged out".

I unplugged the encoders from the cortex and it doesn't "bug out" any more. This is very puzzling. I have replaced the cortex and all of the batteries. I haven't tried setting the sensor value to "SensorNone" in RobotC, but will try it this afternoon.

What do you all think is the problem?
__________________
Team Leader of Team 675A

Tournament Champions (11/17/12)
Excellence Award Winner (1/26/13)
Driver Skills Champion (280)(1/26/13)
Programming Skills Champion (175)(1/26/13)
Tournament Champions (2/23/13)
Reply With Quote
  #2  
Old 04-12-2012, 09:15 AM
supwer supwer is offline
Junior Member
VEX # #675D
 
Join Date: Apr 2011
Location: Suwanee, GA
Posts: 5
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

We're having almost exactly the same problem. I hope someone can answer this before worlds.
Reply With Quote
  #3  
Old 04-12-2012, 10:17 AM
Team80_Giraffes's Avatar
Team80_Giraffes Team80_Giraffes is offline
Senior Member
VEX # 80
 
Join Date: Feb 2011
Location: Downingtown, PA
Posts: 512
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

Caveat: we are avoiding these I2C sesnors until May. Others in our lub are rolling the dice in my mind, but we were on that early release version of Robot C with the I2C and had our robot spin uncontrollably at a competition even with the competition switch set to disable. So we had similar issues with this as well.

If you look at how I2C communication works, you have to send messages out to poll each device for information. There are some old posts on this when the I2C sensors came out so look them up.

We put in some timer delays in our loop to let the I2C sensor get another value and that helped somewhat but it seemed to be more like playing the lottery than a real fix. The idea was that we wanted to ensure we were not interfering with this polling communication over the serial communication to the I2C sensors (we had 2 in the chain). Unless there's proper semaphore blocks on the sensor values you're reading in the underlying RobotC code masked from you, could you be reading while it's writing or in the middle of communicating and parsing the I2C causing some nastiness? Or it could be in the I2C communication handler with some memory out of bounds or other nastiness. It could be a lot of things.

So just a thought and sorry it's not a definative fix. Otherwise it might just be some other bug related to the I2C.

Also, doesn't I2C work pretty reliably for Mindstorms on Robot C? I've never used it so I have no idea. What makes Vex different? Cortex hardware/firmware and SensorValue masking the underlying I2C communication. If successfully masked it's wonderful.

Hence we're back on quad encoders for worlds.... On the to do list for May though! Those I2C sensors have huge promise.
__________________
Vexmen Teams 80[A-Z]$|81[A-Z]$|90[A-Z]$|91[A-Z]$ Downingtown, PA, USA

The Vexmen, Downingtown, PA, USA
Reply With Quote
  #4  
Old 04-12-2012, 10:30 AM
tutman96's Avatar
tutman96 tutman96 is offline
Senior Member
VEX # 675A
 
Join Date: May 2011
Location: Duluth, GA
Posts: 384
Images: 1
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

I actually tried setting the SensorType to sensorNone. I did this for both encoders and it eliminated the problem. I think what I am going to do now is try only initializing one of the encoders. Technically this should only "bug out" only half the time. Can you confirm?
__________________
Team Leader of Team 675A

Tournament Champions (11/17/12)
Excellence Award Winner (1/26/13)
Driver Skills Champion (280)(1/26/13)
Programming Skills Champion (175)(1/26/13)
Tournament Champions (2/23/13)
Reply With Quote
  #5  
Old 04-12-2012, 10:37 AM
jpearman's Avatar
jpearman jpearman is offline
Senior Member
VEX # 8888
 
Join Date: Apr 2011
Location: Los Angeles
Posts: 3,079
Images: 2
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

Quote:
Originally Posted by Team80_Giraffes View Post
If you look at how I2C communication works, you have to send messages out to poll each device for information. There are some old posts on this when the I2C sensors came out so look them up.

We put in some timer delays in our loop to let the I2C sensor get another value and that helped somewhat but it seemed to be more like playing the lottery than a real fix. The idea was that we wanted to ensure we were not interfering with this polling communication over the serial communication to the I2C sensors (we had 2 in the chain). Unless there's proper semaphore blocks on the sensor values you're reading in the underlying RobotC code masked from you, could you be reading while it's writing or in the middle of communicating and parsing the I2C causing some nastiness? Or it could be in the I2C communication handler with some memory out of bounds or other nastiness. It could be a lot of things.
If CMU have implemented this correctly, the I2C communication should be going on in the background and placing the encoder counter into memory. Reading the encoder from ROBOTC code should access the value in memory and place in a user defined variable (or whatever you are doing), it should (hopefully) not initiate any I2C communications directly. I have to admit that I lost interest in using the IMEs when it became clear they would not be ready for the team to use in March, perhaps I should pull them out and see if I can reproduce any of the problems you are seeing. I've used I2C in lots of products and there is nothing inherently unreliable as long as the firmware can handle potentially corrupted data. As the CPU generates the clock it is in some ways easier to deal with than say RS232 asynchronous communication.
Reply With Quote
  #6  
Old 04-12-2012, 10:39 AM
tutman96's Avatar
tutman96 tutman96 is offline
Senior Member
VEX # 675A
 
Join Date: May 2011
Location: Duluth, GA
Posts: 384
Images: 1
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

Which processor does the I2C communication? Is it the user microprocessor?
__________________
Team Leader of Team 675A

Tournament Champions (11/17/12)
Excellence Award Winner (1/26/13)
Driver Skills Champion (280)(1/26/13)
Programming Skills Champion (175)(1/26/13)
Tournament Champions (2/23/13)
Reply With Quote
  #7  
Old 04-12-2012, 10:54 AM
jpearman's Avatar
jpearman jpearman is offline
Senior Member
VEX # 8888
 
Join Date: Apr 2011
Location: Los Angeles
Posts: 3,079
Images: 2
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

Quote:
Originally Posted by tutman96 View Post
Which processor does the I2C communication? Is it the user microprocessor?
As far as I can tell it's the user processor. My notes show they are using port B bits 8 & 9 on the STM32. This means (I assume) that CMU and Intelitek have implemented this independently unless VEX gave them the low level code.
Reply With Quote
  #8  
Old 04-12-2012, 10:56 AM
tutman96's Avatar
tutman96 tutman96 is offline
Senior Member
VEX # 675A
 
Join Date: May 2011
Location: Duluth, GA
Posts: 384
Images: 1
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

I tried disabling the robot with the competition switch and by turning off the robot and neither would stop the robot moving. Can you think of anything that could be helpful?
__________________
Team Leader of Team 675A

Tournament Champions (11/17/12)
Excellence Award Winner (1/26/13)
Driver Skills Champion (280)(1/26/13)
Programming Skills Champion (175)(1/26/13)
Tournament Champions (2/23/13)
Reply With Quote
  #9  
Old 04-12-2012, 11:06 AM
jpearman's Avatar
jpearman jpearman is offline
Senior Member
VEX # 8888
 
Join Date: Apr 2011
Location: Los Angeles
Posts: 3,079
Images: 2
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

Quote:
Originally Posted by tutman96 View Post
I have recently encountered a problem running the I2C encoders. At random times our cortex suddenly "bugs out". The VEXnet light shows that it is still connected but the robot light shows a "User Microprocessor Error". When this happens, the motors keep going the same power that they were when it "bugged out".

I unplugged the encoders from the cortex and it doesn't "bug out" any more. This is very puzzling. I have replaced the cortex and all of the batteries. I haven't tried setting the sensor value to "SensorNone" in RobotC, but will try it this afternoon.

What do you all think is the problem?
How many IMEs do you have in the chain? How long are the cables between them?

How long is the "random time", do you have any way that you can cause this to happen under your control or is it just a case of waiting?

Do you know if your code is still running when this happens, is there a code controlled LED or LCD display you can use to help show what may be happening?

Do you know if you can still send values to the motors? You could add an "emergency stop" switch that would disable everything, although not a proper solution it would help by showing that motor control was still possible from user code.
Reply With Quote
  #10  
Old 04-12-2012, 11:09 AM
tutman96's Avatar
tutman96 tutman96 is offline
Senior Member
VEX # 675A
 
Join Date: May 2011
Location: Duluth, GA
Posts: 384
Images: 1
Re: WARNING Using the New Integrated Encoders on Worlds Firmware

We are using only 2 sensors and are using just one cable between them (i think 12 inches). I can't send any values to the motors as my arm keeps rising even after the software limit. I can try to see if the code is still running by flashing an led, but I really don't think that it is still running.
__________________
Team Leader of Team 675A

Tournament Champions (11/17/12)
Excellence Award Winner (1/26/13)
Driver Skills Champion (280)(1/26/13)
Programming Skills Champion (175)(1/26/13)
Tournament Champions (2/23/13)
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

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

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


All times are GMT -6. The time now is 12:49 PM.


VEX and VEX Robotics are trademarks or service marks of Innovation First International, Inc.
Copyright © 2002-2013. All Rights Reserved. VEX Robotics, Inc. is a subsidiary of Innovation First International, Inc.
All other product names/marks of others are the property of their respective owners.