How do I Post to the Game Q&A Forum?

Welcome to the FTC Game Q&A Forum! If this is your first time here, please refer to the Instructions for Forum Use section before posting.

Thank you!

Posts created to sell a product or service are not permitted and will be deleted!

Page 8 of 10 FirstFirst ... 678910 LastLast
Results 71 to 80 of 91

Thread: Gyro Read Latency... Development team update.

  1. #71
    Member
    Join Date
    Oct 2015
    Location
    Orlando, FL
    Posts
    31
    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.

  2. #72
    Senior Member
    Join Date
    Jun 2015
    Location
    West Milford, NJ
    Posts
    201
    Quote Originally Posted by skatefriday View Post
    With the latest beta, the gyro is as responsive as any other device.

    Your latency will increase as you add devices, but there is no longer a non-linear penalty for the gyro. Rather, everyone shares in the bandwidth equally and all devices are penalized equally as device count increases.

    I am skeptical that you'd achieve a meaningful improvement by partitioning i2c devices across multiple CDIM's. Each controller has it's own usb read/write thread, but they all share the single bus from the robot controller to the hub in the PDM. So there's still that bottleneck. And that is inherent to the hardware architecture.
    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?

  3. #73
    Senior Member
    Join Date
    Jun 2015
    Location
    Massachusetts
    Posts
    379
    Quote Originally Posted by Alec View Post
    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?
    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.

  4. #74
    Member
    Join Date
    May 2015
    Location
    Yorktown Heights, NY
    Posts
    57
    Quote Originally Posted by Philbot View Post
    The following Gyro latency times indicate the improvements that have be obtained from methods 1 and 2.
    These times indicate how many mSec between changing Gyro values.

    Configuration: 1 Gyro
    (27 mSec) SDK 2.3 and 2.4
    (13 mSec) SDK 2.5

    Configuration: 1 Gyro, 2 color sensors
    (80 mSec) SDK 2.3 and 2.4
    (25 mSec) SDK 2.5
    (14 mSec) SDK 2.5 with Color sensors disabled while driving.


    Configuration: 1 Gyro, 2 color sensors, 4 Motor Controllers, 1 Servo Controller.
    (170 mSec) SDK 2.3 and 2.4
    (65 mSec) SDK 2.5
    (25 mSec) SDK 2.5 with Color sensors disabled while driving.
    Hi Philbot,
    I have a very basic question.. how did you measure these latencies? Does the MRgyro give time stamped data?

  5. #75
    Senior Member
    Join Date
    Dec 2011
    Location
    MD
    Posts
    1,039
    Quote Originally Posted by rbFTC View Post
    Hi 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.

    I did this over a number of readings and averaged the results.

  6. #76
    Senior Member
    Join Date
    Sep 2013
    Posts
    151
    @Philbot
    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!

  7. #77
    Senior Member
    Join Date
    Nov 2015
    Location
    Carol Stream, IL
    Posts
    154
    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.

  8. #78
    Senior Member
    Join Date
    Jul 2016
    Location
    Virginia
    Posts
    146
    Quote Originally Posted by 5294-jjkd View Post
    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?

  9. #79
    Senior Member
    Join Date
    Dec 2011
    Location
    MD
    Posts
    1,039
    Quote Originally Posted by FTC7253 View Post
    @Philbot
    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?
    My "limited" understanding here is that it's not a data transmission issue, it's a communications setup/breakdown time issue.
    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.

  10. #80
    Member
    Join Date
    May 2015
    Location
    Yorktown Heights, NY
    Posts
    57
    Quote Originally Posted by Philbot View Post
    Hi All....

    This post specifically addresses the issues raised about how quickly (slowly) gyro updates are available to an opmode.
    It does not address ODS issues that may or may not be related.

    The planned schedule is to migrate the current 2.4 Beta to release status this Monday.
    At the same time (or very soon afterwards) a new 2.5 beta will be made available on the GitHub site.

    There are three topics I wanted to discuss here.

    1) There were some inefficiencies in the MR Gyro I2C handling code which were slowing down the transfer of fresh heading information from the Gyro.
    These inefficiencies translated into a 100% overhead. So, once they were removed, the data latency was reduced to about 50%.
    These changes have already been implemented in the forthcoming 2.5 beta.

    2) Since any device which exists in the robot configuration has the effect of adding to the overall data latency, there are gains to be realized by "disabling" any devices not currently being used. (thnaks to other posters on this forum for this idea) In the case of this year's game, this definitely includes the MR color sensors that aren't needed for normal driving, only for beacon identification.

    The dev. team sees a real advantage to providing an API to enable and disable sensors to improve performance, but this requires further coding and testing, so it's also unlikely to be included in the 2.5 beta, but it is possible for teams to selectively implement this same process in their own opmodes. (see end of post)

    3) There may be some small gains in I2C efficiency that can be gained from a tweak of the general I2C interface to utilize block data transfers.
    These changes are still under review, and will probably not be implemented until after the 2.5 Beta.

    To give you an idea what can be expected...

    The following Gyro latency times indicate the improvements that have be obtained from methods 1 and 2.
    These times indicate how many mSec between changing Gyro values.

    Configuration: 1 Gyro
    (27 mSec) SDK 2.3 and 2.4
    (13 mSec) SDK 2.5

    Configuration: 1 Gyro, 2 color sensors
    (80 mSec) SDK 2.3 and 2.4
    (25 mSec) SDK 2.5
    (14 mSec) SDK 2.5 with Color sensors disabled while driving.


    Configuration: 1 Gyro, 2 color sensors, 4 Motor Controllers, 1 Servo Controller.
    (170 mSec) SDK 2.3 and 2.4
    (65 mSec) SDK 2.5
    (25 mSec) SDK 2.5 with Color sensors disabled while driving.

    So your specific improvments will depend on what you have on your robot and whether you can disable other sensors while driving.

    The following code shows how the color sensors can be initailized, and then subsequently enabled and disabled.


    Code:
    // Declare Color Sensor objects (and other items required to enable/disable)
    ModernRoboticsI2cColorSensor  leftColor = null;
    ModernRoboticsI2cColorSensor  rightColor = null;
    
    I2cAddr leftColorAddress  = I2cAddr.create8bit(0x3c);
    I2cAddr rightColorAddress = I2cAddr.create8bit(0x4c);
    
    I2cController   leftColorController;
    I2cController   rightColorController;
    
    I2cController.I2cPortReadyCallback leftColorCallback;
    I2cController.I2cPortReadyCallback rightColorCallback;
    
    boolean colorSensorsDisabled = false;
    Code:
    /***
    * Initialize two color sensors, and take a copy of callback handlers for later use.
    */
    public void colorInit() {
    	leftColor   = myOpMode.hardwareMap.get(ModernRoboticsI2cColorSensor.class, "left color");
    	leftColor.setI2cAddress(leftColorAddress);
    	leftColorController = leftColor.getI2cController();
    	leftColorCallback =  leftColorController.getI2cPortReadyCallback(leftColor.getPort());
    
    	rightColor  = myOpMode.hardwareMap.get(ModernRoboticsI2cColorSensor.class, "right color");
    	rightColor.setI2cAddress(rightColorAddress);
    	rightColorController = rightColor.getI2cController();
    	rightColorCallback =  rightColorController.getI2cPortReadyCallback(rightColor.getPort());
    
    	colorSensorsDisabled = false;
    }
    Code:
    /***
    *   enable color sensors by re-registering callbacks
    */
    public void colorEnable() {
    	if(colorSensorsDisabled) {
    	    if (leftColorCallback != null)
    		leftColorController.registerForI2cPortReadyCallback(leftColorCallback, leftColor.getPort());
    	    if (rightColorCallback != null)
    		rightColorController.registerForI2cPortReadyCallback(rightColorCallback, rightColor.getPort());
    	}
    	colorSensorsDisabled = false;
    }
    Code:
    /***
    *   disable color sensors by de-registering callbacks
    */
    public void colorDisable()
    {
    	if (!colorSensorsDisabled) {
    	    leftColorController.deregisterForPortReadyCallback(leftColor.getPort());
    	    rightColorController.deregisterForPortReadyCallback(rightColor.getPort());
    	}
    	colorSensorsDisabled = true;
    }
    Quote Originally Posted by Philbot View Post
    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.
    @Philbot, Thank you for your insightfull info.

    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?

Page 8 of 10 FirstFirst ... 678910 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •