We did start randomly experience the "OpMode stuck in loop" error again, and it turns out it was a bug int he 2.61 SDK that the 2.62 Alpha SDK was created to resolve. If you want the sensor updates in 2.61 I would highly suggest you get the 2.62 Alpha instead. We had a meet and several teams running the 2.61 Beta were experiencing the "OpMode stuck in loop" error. The FTA there was upgrading people to 2.62 to resolve the issue. I am not sure why they still have the 2.61 Beta up on the site, they should probably just replace that Beta with the 2.62 Alpha.
We have six I2C devices connected to a single CDIM. If we connect our six (or eight) I2C devices to the Adafruit I2C Multiplexer (with appropriate interface class or driver) instead of the CDIM, then we will have only one I2C device connected to the CDIM. In this case, each I2C device connected to the multiplexer should have close to the same latency as a single I2C device connected to a CDIM, correct?
Originally Posted by skatefriday
The latency of a single I2C command should be the same because the multiplexer is just choosing which bus to physically connect to the main bus. If you are reading from only one of the sensors, then it will work just like reading a sensor attached directly to the DIM after the initial command to switch. However, if you want to continuously read multiple sensors, you have to issue an I2C command to switch which bus is connected to the main bus between each read. For example, one read cycle of 2 sensors becomes [select sensor 1, read sensor 1, select sensor 2, read sensor 2]. This takes 4 I2C-port-ready cycles to get one new set of data, whereas having two devices connected directly to the DIM would let you read them both in only 1 cycle.
Originally Posted by Alec
Originally Posted by Philbot
I have a very basic question.. how did you measure these latencies? Does the MRgyro give time stamped data?
No, I just watched the gyro values as the robot was spinning (on a lazy susan) and recorded the times between value changes.
Originally Posted by rbFTC
I did this over a number of readings and averaged the results.
I still question why so much slow down when adding devices. Isn't there plenty of bandwidth on USB 2 to handle the relatively small amount of data being transferred from these sensors?
Do the controllers and CDIM "constantly" send data without being requested?
Have you looked at similar measurements for the update rate for encoders? We have 1 Gyro, 1 color sensor, 1 Servo controller with 2 devices, and 3 motor controllers (2 with encoders - and only 1 that uses the encoders during driving). Does adding the each device/controller incur a penalty? Even when no commands or requests are being made?
The time doubled when you added the motor controllers and servo controller while disabling the color sensors. Is there a way to "disable" the non-drive motor controllers and servo controllers during certain portions to free up time for power commands and encoder returns?
40Hz seems like a pretty big constraint on control loops!
Note that the USB bus is not likely the most significant limiting factor for I2C sensors. The I2C 'bus' in the CDIM is run at 100 kbits/sec (I2C 'standard mode') per the MR specs for the device. So, that data rate must be shared across all the I2C sensors attached to the CDIM. As you say, once you hit the USB bus, much more bandwidth is available, so why everything else seems slow is not obvious to me.
Maybe it's a limitation of the Android phone's USB chipset, being in OTG mode?
Originally Posted by 5294-jjkd
My "limited" understanding here is that it's not a data transmission issue, it's a communications setup/breakdown time issue.
Originally Posted by FTC7253
Yes, I2C and USB can transmit many 100 thousands /millions bits per seconds once an active USB connection has been established, and data is flowing between the Phone and a specific device.
But, the RC Phone and the various attached devices aren't/cant make full use of this bandwidth.
Each transaction with a CORE device (or in the case of the DIM, each I2C device) is performed as a transaction which has a definate fixed overhead associated with it.
It's this overhead (which appears to be largely independant of the USB or I2C data rate) is the main contributing factor to the overall transaction rates.
ie: it wouldn't matter if the volume of data in a packet was largely increased or decreased, the cycle times would be very similar.
I don't know how much of this delay is a function of the interfacing methods used, or something embedded into Android.
With Android, some things that you would expect to be fast, seem to have strange overheads....
eg: I was trying to use the phone's camera LED as an indicator, only to find that it added 100 mSec latencies to the cycle times. And this was completely within the Android SDK.
So... just explaining why for the moment the data rates don't justify the measured cycle times.
Originally Posted by Philbot
@Philbot, Thank you for your insightfull info.
Originally Posted by Philbot
Are all / majority of the transactions initiated by the Teamcode or do the transactions between the RC and controllers occur without ever being asked by Teamcode?
Way back at the beginning of ResQ season, when there was a notion of hardware cycle, I remember seeing some explanation like this: "the sdk reads the data from all the controllers into the memory, and it writes all the new values fromt the memory to the controllers. These two operations together constitute one hardware cycle."
While the notion of hardware cycle is gone, I am wondering if the SDK is still reading data without being asked by the Teamcode. If so, is there a way avoid it?