After INIT pressed, BNO055IMUImpl.initialize(), which is synchronized, gets called from the op mode thread. This method calls VirtualBot.getHeadingRadians(), which was also synchronized. So the op mode thread owns the BNO055IMUImpl lock, and must obtain the VirtualBot lock before it can proceed.
At the same time VirtualBot.updateStateAndSensors(), which is synchronized, is being called repeatedly by the game loop thread. This calls BNO055IMUImpl.updateHeadingRadians(), which is also synchronized. So the game loop thread owns the VirtualBot lock, and mus obtain the BNO055IMU lock before it can proceed.
The above can cause a deadlock.
Solution: make VirtualBot x, y, and headingRadians fields volatile, and remove the 'synchronized' keyword from their getter methods.
After INIT pressed, BNO055IMUImpl.initialize(), which is synchronized, gets called from the op mode thread. This method calls VirtualBot.getHeadingRadians(), which was also synchronized. So the op mode thread owns the BNO055IMUImpl lock, and must obtain the VirtualBot lock before it can proceed.
At the same time VirtualBot.updateStateAndSensors(), which is synchronized, is being called repeatedly by the game loop thread. This calls BNO055IMUImpl.updateHeadingRadians(), which is also synchronized. So the game loop thread owns the VirtualBot lock, and mus obtain the BNO055IMU lock before it can proceed.
The above can cause a deadlock.
Solution: make VirtualBot x, y, and headingRadians fields volatile, and remove the 'synchronized' keyword from their getter methods.