[FTC] Gyro problem

Technical
,
1

Hi, We’re trying to get our robot to use the gyro to correct some drive that’s happening when we try to drive straight and we’re running into some trouble. I’m the mentor, so here’s what the student has to say about the problem:
We found that our IMU was severely lagging our programming, reducing the speed of the code by >99%. We decided that it might be best if we ran the IMU in a thread separate from the main thread, so they wouldn’t slow the robot down. However, after we put the IMU reading into a thread, it only returned 0.0 for all of the angles. We know that IMU was not null as it didn’t return a null point error. What could be causing our problem? Code is here: GitHub - mallratsftc01/RightStage_threaded, the thread is in ThreadedIMU.java.

We have the REV control hub and Expansion hubs that were shipped in 2020, so they both have Bosch BNO055 IMU. The best solution would be one where we don’t have to put they gyro in another thread.

Fran
18387 The Mall Rats

2

I can probably help more with a copy of your code, but my guess would be some sort of concurrency/parallelization issue with sending data between threads.

As a note, threading the IMU won’t get you the speedup you are thinking of most likely. All hardware interactions share a single concurrency mutex lock, meaning that by putting the IMU in a seperate thread, whenever a read is initiated, it will still block any hardware (i.e. motor.setPower()) interactions on your main thread. Your best bet is to use another source of heading information (i.e. deadwheel odometry) or decrease the sampling rate of the IMU (i.e. only read angles once every 5-10 loops)

3

Thanks for taking a look at this.

Here’s the code: GitHub - mallratsftc01/RightStage_threaded

Is there a right way to poll the IMU without killing the rest of the code? Decreasing the sample rate is still going to cause a massive slowdown.

4

Nothing obvious I can see right off the bat but I also can’t find the ThreadedIMU.java class.

Unfortunately polling is probably one of your best bets. You can try time optimizing other things to compensate, like using bulk reads if you aren’t and making sure you aren’t setting powers to motors if the requested power hasn’t actually changed since the last iteration. Deadwheel odometry is usually the solution here since you can derive your angle from 3 pods, and those can be bulk read all at once which is faster then using the IMU.

5

My programmer says the bulk read and polling the IMU less often is probably going to work.

Thanks for the help.

6

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.