WARNING Using the New Integrated Encoders on Worlds Firmware

[tutman96]

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?

[supwer]

We're having almost exactly the same problem. I hope someone can answer this before worlds.

[Team80_Giraffes]

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.

[tutman96]

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?

[jpearman]

Originally Posted by Team80_Giraffes

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.

[tutman96]

Which processor does the I2C communication? Is it the user microprocessor?

[jpearman]

Originally Posted by tutman96

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.

[tutman96]

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?

[jpearman]

Originally Posted by tutman96

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.

[tutman96]

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.