Announcement

Collapse
No announcement yet.

new "rotate to angle" & "drive in a straight line" examples for navX-Micro/navX-MXP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • new "rotate to angle" & "drive in a straight line" examples for navX-Micro/navX-MXP

    There are now a number of example OpModes available for use w/the navX-Micro (and navX-MXP) IMU / AHRS sensor.

    These include the "navXRotateToAnglePIDOp.java" and "navXDriveStraightPIDOp.java" opModes, which demonstrate using the Yaw angle and a PID Controller to control a 2-wheel robot. More discussion of these samples can be found at the navX-Micro examples pages.

    Other opmodes include:

    - "navXProcessedOp.java": Displays Yaw, Pitch, Roll, Compass Heading, 9-Axis Heading, Linear Acceleration and sensor status as telemetry data.
    - "navXRawOp.java": Displays Raw 3-axis gyro, accelerometer and magnetometer data as telemetry data.
    - "navXMotionDetectionOp.java": Displays Motion detection as telemetry data.
    - "navXCollisionDetectionOp.java": Displays Collision detection as telemetry data.

    Finally, there's also a very helpful "navXPerformanceTuningOp.java" which displays update rate performance statistics as telemetry data, and can be helpful to tune the sensor configuration to match your robot's system performance.

    If anyone has any other samples that they're interested in seeing, please feel free to ask. Work is underway for a "auto-balance" op mode and a "field-centric drive" op mode for a mecanum-based drive system. However, if there are other examples that make more sense, please speak up.

  • #2
    Thanks for all of the hard work!

    I looked at some of the op mode examples this morning and they were great. I saw the one for zeroing the yaw (resetting the heading) that I had asked you about and it was easy just like you said. I didn't quite understand it all, but it is just a few lines of code and easy to copy.

    I do have a question about the op mode using the yaw to rotate to an angle. Is there any reason that you used a linear op mode instead of a loop one? I didn't know if there might be something about the code or processes involved that might not work in a loop op mode. The reason I am asking is that there was an example op mode in a previous version of the SDK for the Modern Robotics Color Sensor. It used a linear op mode and it set the background color of the robot controller screen to whatever color the sensor was seeing. I tried to use it in a loop op mode that I was using and I kept getting an emergency stop and error message. When I switched my code over to a linear op mode, it worked just fine. I figured that there was something about the code being used that made it work only in a linear op mode. I was just wondering it that might be the case here.

    Comment


    • #3
      Originally posted by matrixguy View Post
      I do have a question about the op mode using the yaw to rotate to an angle. Is there any reason that you used a linear op mode instead of a loop one?
      A loop op mode is also very simple to implement.

      In the existing linear op mode in the example, the thread running the linear op mode blocks until a new sensor update is available, and then the thread is resumed and updates the motors.

      However in a loop mode, the code changes a little. Instead of calling the navXPIDController's waitForNewUpdate() in linear op mode, call isNewUpdateAvailable() in loop mode. The isNewUpdateAvailable() does not block, but rather polls to see if a new update is available. If isNewUpdateAvailable() returns false, no new data has arrived from the IMU since the last time the function was called; in that case, there's no need to update the motors since there's no new information to act up.

      I suggeset you give that a try, and let me know if there's anything that's not clear.

      Comment


      • #4
        Originally posted by FTC10386 View Post
        However in a loop mode, the code changes a little. Instead of calling the navXPIDController's waitForNewUpdate() in linear op mode, call isNewUpdateAvailable() in loop mode. The isNewUpdateAvailable() does not block, but rather polls to see if a new update is available. If isNewUpdateAvailable() returns false, no new data has arrived from the IMU since the last time the function was called; in that case, there's no need to update the motors since there's no new information to act up.
        For use as a reference, new sample op modes for rotating to angle and driving straight using loop-style op modes have been added to the navX-Micro Github respository.

        Comment


        • #5
          Originally posted by FTC10386 View Post
          A loop op mode is also very simple to implement.

          In the existing linear op mode in the example, the thread running the linear op mode blocks until a new sensor update is available, and then the thread is resumed and updates the motors.

          However in a loop mode, the code changes a little. Instead of calling the navXPIDController's waitForNewUpdate() in linear op mode, call isNewUpdateAvailable() in loop mode. The isNewUpdateAvailable() does not block, but rather polls to see if a new update is available. If isNewUpdateAvailable() returns false, no new data has arrived from the IMU since the last time the function was called; in that case, there's no need to update the motors since there's no new information to act up.

          I suggeset you give that a try, and let me know if there's anything that's not clear.
          Thanks for the help. I will give it a try.

          In the example op mode I mentioned for the Modern. Robotics Color Sensor it wasn't anything obvious - at least not to me. As a matter of fact, it was the line of code used to set the screen to the color reading from the sensor that would only work in a linear op mode, but I don't know why. That's why I had asked if there was a reason for using a linear op mode in the sample files.

          Originally posted by FTC10386 View Post
          For use as a reference, new sample op modes for rotating to angle and driving straight using loop-style op modes have been added to the navX-Micro Github respository.
          Thanks again! Now I can compare the 2 versions of each and see what the differences are.

          Comment


          • #6
            Originally posted by matrixguy View Post
            In the example op mode I mentioned for the Modern. Robotics Color Sensor it wasn't anything obvious - at least not to me. As a matter of fact, it was the line of code used to set the screen to the color reading from the sensor that would only work in a linear op mode, but I don't know why. That's why I had asked if there was a reason for using a linear op mode in the sample files.
            Would you mind posting your code? We have been trying to replicate this issue. Seeing your code would help a lot.

            Comment


            • #7
              Originally posted by matrixguy
              ;
              In the example op mode I mentioned for the Modern. Robotics Color Sensor it wasn't anything obvious - at least not to me. As a matter of fact, it was the line of code used to set the screen to the color reading from the sensor that would only work in a linear op mode, but I don't know why. That's why I had asked if there was a reason for using a linear op mode in the sample files.
              Would you mind posting your code? We have been trying to replicate this issue. Seeing your code would help a lot.
              Originally posted by Jonathan Berling View Post
              Would you mind posting your code? We have been trying to replicate this issue. Seeing your code would help a lot.
              Curious - is the Loop Opmond running on the the UI thread? If so then maybe you could just remove the "relativeLayout.post" wrapping code and just call the relativeLayout.setBackgroundColor... Just a guess.

              Comment


              • #8
                Originally posted by dlevy View Post
                Curious - is the Loop Opmode running on the the UI thread?
                No user code runs in the UI thread. The UI thread workload is kept to a minimum so that the app UI remains responsive.

                Comment


                • #9
                  Originally posted by Jonathan Berling View Post
                  Would you mind posting your code? We have been trying to replicate this issue. Seeing your code would help a lot.
                  Jonathan,

                  I was just trying to use the code from the sample Op Mode in the September SDK release for the Modern Robotics Color sensor. This is the code I was trying to use from the "MRRGBExample" to set the background color of the robot controller screen to the color detected by the sensor:

                  Code:
                  // get a reference to the RelativeLayout so we can change the background
                      // color of the Robot Controller app to match the hue detected by the RGB sensor.
                      final View relativeLayout = ((Activity) hardwareMap.appContext).findViewById(R.id.RelativeLayout);
                  
                  
                  // change the background color to match the color detected by the RGB sensor.
                        // pass a reference to the hue, saturation, and value array as an argument
                        // to the HSVToColor method.
                        relativeLayout.post(new Runnable() {
                          public void run() {
                            relativeLayout.setBackgroundColor(Color.HSVToColor(0xff, values));
                          }
                        });
                  I had a Loop Op Mode that I had tried to use it in and I keep getting an error message - "user code threw uncaught exception null". The op mode had worked fine before that and worked fine after I had removed that line of code. I realized that the sample was a linear op mode so I decided to switch over to a linear op mode and when I added the code - it worked fine. That's why I figured that there must be something about it that would only work in a linear op mode. The only thing that I did was switch it over to this:

                  Code:
                  relativeLayout.post(new Runnable() {
                                                  public void run() {
                                                      relativeLayout.setBackgroundColor(Color.argb(255, 200, 100, 100));
                                                  }
                                              });
                  I used the "Color.argb" and put the values for "alpha", "red", "green", and "blue" in manually to set the background to "red", green", and "blue" instead of using the "Color.HSVToColor" used in the original code.

                  This all started because I was trying to make some changes to code posted on the forum for using the front ZTE camera as a color sensor. I was wanting to add a couple of text boxes to the Robot Controller screen and set their background colors to the results from the camera. I tried several things but couldn't get anything to work. When I had posted on the forum to see about getting some help doing this - the responses said that I couldn't do it the way that I way trying to do it - see thread "How to use the camera as a sensor" posts 33, 37, 38, and 42. That's when I remembered the example op mode for the color sensor and I tried using the code.

                  I hope this helps,

                  Allen

                  Comment

                  Working...
                  X