aedancullen
commented
7 years ago At least from my experience reading the Qualcomm internal code, your best option is probably just to spawn a separate thread. The entire architecture of the FTC system isn't great in terms of update speed, since even if calls weren't blocking, there would still be overhead as a result of the FTDI UART and USB layers while the data is sent to the Android app. There won't be any fix possible that can get you all the way up to the native update speed of the sensor. Less than 50ms is actually quite impressive considering that all of this data is being shoved through a UART and then to a scheduled operating system kernel on the Android phone. A microcontroller is really the proper platform for a robotics system, not a cell phone. I know, it's quite disappointing..
AlecHub
Using 3.x, calls to get orientation (imu.getAngularOrientation) and position (motor.getCurrentPosition) appear to be blocking. The call to get orientation blocks for ~20ms, while getCurrentPosition seems to take ~3ms. Last year, I recall that the calls to MR gyro.getIntegratedZ were not blocking - they would return immediately with the last received angle. Early in the season, the updates were period was very long when using multiple I2C devices, but that improved with changes made to I2C in the SDK. The net result is that "frames" that would take ~5ms last year now take 30+ms this year. Granted, the frames appear to be acting on "latest" data, but I wonder if that really matters given the communication delays. An average of 20ms for imu returns seems long - especially given that the BNO055 reports a gyro update period of 10ms. And while 3ms per encoder position call does not seem horrid, it quickly adds up with multiple wheels (and lifters, etc). This spawns several questions... Were these changes to blocking calls part of improving overall USB communication performance? Are they specific to connections with the REV hub? Would it be helpful or harmful to create a thread that repeatedly makes imu.getAngularOrientation calls, and simply returns the latest received value to calls from our opMode? Perhaps similar for getCurrentPosition and other inputs? Would there be any benefit to comms overhead by setting up the REV to package messages containing the input returns of the relevant devices setup in a config? This could reduce/eliminate the need for SDK->REV requests, and allow more efficient packing of REV->SDK data. After all, it is not a stretch to assume that if a input device is in the config (imu, motor with encoder, other sensor), the user is probably going to want the data. We have 1 bot with 1 REV hub (with imu), 2 drive motors with encoders, 1 lift motor with encoder, 3-4 servos. The frames appear to be around 30ms. Our other bot has 1 REV hub (with imu), 4 drive motors with encoders, 1 MR CPDM, 1 MR CMC with 1 lift motor with encoder, 3-4 servos. The frames are taking 45-75ms!! We are using Android Studio, SDK 3.5, various phones (S5, ZTE, Moto), REV expansion hubs (haven't updated to 1.7 firmware yet). Thanks for all the tech team does, and thanks for answers/help with these questions.