To compensate for this, I just reset the timer every thirty seconds.
Unfortunately, this also times out at around 32.8 seconds. To get the most accurate reading for time elapsed, I rewrote the program to use the time1 timer, which is a timer that returns readings in milliseconds. So the value is not an accurate depiction of the actual time elapsed. This happens because it was using wait1Msec() instead of using timers. Essentially, instead of waiting 10 milliseconds, it waits 10 milliseconds, then it waits for other tasks to run, and then it runs. However, I doubt the ability for this to work when there are other tasks that take up lots of processing space (actually I know that this won’t work from other people’s experiences). W hen other tasks work simultaneously with the gyro task, the gyro drastically underestimated its heading. This worked when tested in the gyro testing program. So to do this, I just made the time elapsed always equal to 10 milliseconds and entered in all the other variables, getting the below code, which is placed in a while loop. Like I stated above, getting the heading of the robot just involves finding the Euler sum of the gyro readings. Making the first rotation reading task was fairly simple. This fixed my problem with the gyro reading. Mine made an initial value, float initial, and made it a mean value of 100 resting gyro readings. To compensate for this, instead of using the original initialization routine, I made my own. I inferred that the rest reading must not be 607 but rather a number between 607 and 608. The other was that when the NXT was in a resting position, gyro readings altered between 607 and 608. One was that the rest reading kept changing. I ran the program a few times, and I noticed a few things. When I made a simple program that did this, I noticed a problem that was also present in Xander’s example program: the heading continuously increased. Therefore, the theoretical algorithm for finding the heading is: When it rotates, that value moves up and down, so the difference between the current reading and the resting reading is what we actually want. The gyro sensor also outputs a value around 607 (but not always 607) when held still.
Essentially, the gyro readings are a representation of its turning velocity in degrees per second. I learned that the gyro uses a Euler sum to calculate the heading of the robot. To start, I made a function that outputted raw values like the base gyro reading, updated gyro readings, the calculated heading, and time elapsed. This would allow my team to have a robot capable of precise turns and outlandish driving functions (including our superdrive task, which I’ll talk about soon). I was determined to make a task that gave me an accurate representation of my robot’s heading. I decided to do some experimenting and get to the bottom of this gyro sensor.
Robotc tasks drivers#
I download Xander’s drivers and sample code, and when I used it, I noticed that the rotation steadily increased, which made the rotation calculations almost useless for anything but quick turns.
My Program on GithubĪfter reading a few example programs and uploading one to our NXT, I found that even the developers at HiTechnic haven’t been able to make the gyros work well. My team has always wanted to use a gyro sensor, but doing that is apparently much harder than just pulling a sensor value every few milliseconds. The gyro is easily one of the most useful sensors in FTC, but it is also really really hard to use, and it has many unexplained nuances.
0 kommentar(er)
