Changes in mode change for color sensor #1025
Conversation
When changing the mode to another, the new values are checked to make sure they are in the range that the mode corresponds to. We also additionally skip a few values to make sure that the sensor gives us values from the set mode.
Maximum cycle time for protection. Do not work for a port where no sensor is connected.
|
I made some changes, it turns out that adequate values come after 30-40 ms after switching the mode, at least from reflection mode to raw reflection values mode. |
I figured out that the getUartStatus() method on input gives status 8 when the sensor has changed mode most of the time. Displayed in control.dmesg and checked it, but periodically the value jumped more than 1024 as before, the value was 40 thousand. I additionally added a condition that the value cannot be greater than 1023.
|
I figured out that the getUartStatus() method on input gives status 8 when the sensor has changed mode most of the time. Displayed in control.dmesg and checked it, but periodically the value jumped more than 1024 as before, the value was 40 thousand. I additionally added a condition that the value cannot be greater than 1023. The mode change time is different, maybe about 15 ms, and maybe about 50 ms, but this algorithm came out better. The reliability of obtaining the correct values is much higher.
|
|
@jwunderl look here please |
Co-authored-by: Joey Wunderlich <jwunderl@users.noreply.github.com>
Co-authored-by: Joey Wunderlich <jwunderl@users.noreply.github.com>
…Eb0nny/pxt-ev3 into changes-in-mode-change-for-cs
When changing the mode to Reflection Raw, I noticed that you can get inadequate ones. These numbers are greater than 1023, which cannot be at all. Something like 40 thousand.
I even recorded a video with this problem.
https://photos.app.goo.gl/ZKhqqND3uNrmJhPs5
I decided to write an algorithm inside the function for setting the operating mode. Valid only when the mode is changed once.
At first I just made the algorithm so that it simply ignored values greater than 1023, but then I remembered about other modes (reflection and external environment from 0 to 100, and color mode from 0 to 7). But later I realized that ignoring values greater than 1023 is not enough, because. We can get the values from the previous mode from the color sensor, this is from 0 to 100 (since at startup, the default mode is 0 - reflection mode).
I wrote a more complex algorithm that, when launched, initially looks at what the value was before switching the mode. Then in the loop it is checked that the value is not the same as before the mode change. For the cycle, a time protection of 100 ms is additionally implemented. During this time, the color sensor should definitely have changed several values.
In general, from experience, this was a problem for the implementation of movement along the line follow. In the loop before the algorithm, it was necessary to implement code with protection that the values in the mode of raw reflection values are less than 1024, because the algorithm for normalizing raw values in the range from 0 to 100 could give 0 immediately because of this, and the robot did not go anywhere right away, because. I thought he had already reached the crossroads.
The algorithm actually gives a bit of a delay of tens of ms before using the sensor, but so far I have not observed problems with the ralized code on hardware.
Lego in the firmware has something to poll whether the sensor has completed the mode change and whether it is ready to give data, but I did not understand how to implement this in Makecode.
I've seen some guys at competitions switch very quickly between color mode and reflection mode instantly while the robot is driving down the line. Of course, my code will not allow this, because there will be some delay. To do this, you need to implement a firmware poll about whether the sensor is ready to receive new values, which I showed above...