Pre-competition rover.py refactor 2: Electric Boogaloo

[onkoe]

This refactor is a total rewrite of many parts of the Autonomous codebase. In the files that have seemed fallible for too long, we're writing an easier API.

More importantly, though, we plan to maintain the rover's current state as we take actions. This means that a Rover class progresses its various fields/members - each with its own state.

When we go from GPS navigation to ARUCO/YOLO navigation, it won't just be a broken for loop. Instead, its entire state changes, and another method runs entirely.

These changes all work together through the use of threads (and possibly multiprocessing). We'll see :)

[onkoe]

open to renaming communication.py if someone comes up with something clever

[onkoe]

thank u remi

[onkoe]

i want this to be the commit that confused future generations

[onkoe]

i won't say what it does. but it fixes ci :3

[onkoe]

anyways, calling it a night here. here's what remains to be implemented:

• ar_tracker.py
  • the last bit of math stuff
  • the charuco board. like someone needs to go make a fucking board with paper and cardboard please help
    • i think you just print out the checkerboard part. then, print + cut out the charuco markers and glue them on the white parts of the checkerboard.
• rover.py
  • the actual driving part.
  • some processes
  • solve this problem: Both Communication and Navigation have threads, and it's possible to share state with Rover using multiprocessing.Value. However, the state types are zero-sized, so the C has a stroke when you try to share the type over processes. Also, the Navigation wants to give directions and take the directions, and Communication needs a way to get those directions without overloading the microcontrollers. But I'm sure that's not a big deal! 👹
• communication.py
  • take messages of a certain type. but then what's the point of having all those little public methods? honestly it could be a completely internal class that you just .start() and send messages to over a Queue. that'd be muuuuch easier
• navigation.py
  • the damn driving logic. it's hard to reason about right now. consider adding an 'actual' queue of actions that the Navigation creates..? otherwise, hardcode it like it is now :(

[onkoe]

note: all modules need to be synced to run for the same amount of time as expected.

i.e. HappySad/libs/drive.py had a desync:

Ok so in terms of comparing the driveAlongCoordinates function between the old version and the version we're running on the Rover, it definitely seems like the issue is a threading issue with the sleep() statements. Main 2 changes that could be causing the timing to get out of sync with what the old code was able to do are:
- The change from print statements to logging: while it IS better to use logging statements within threads, the reason they're better is because print statements do have the ability to affect the timing/synchonization of the code, and can mess with sleep() statements in weird ways. We might want to try going back to print statements temporarily just to see if it makes the Rover perform better.
- Another thing that could be affecting the threading is this part from the newer code:

            self.speeds = self.get_speeds(
                # change self.base_speed to base_speed
                self.base_speed,
                bearing_to,
                200,
            )  # It will sleep for 100ms
            sleep(0.1)  # Sleeps for 100ms

Ok so in terms of comparing the driveAlongCoordinates function between the old version and the version we're running on the Rover, it definitely seems like the issue is a threading issue with the sleep() statements. Main 2 changes that could be causing the timing to get out of sync with what the old code was able to do are:
- The change from print statements to logging: while it IS better to use logging statements within threads, the reason they're better is because print statements do have the ability to affect the timing/synchonization of the code, and can mess with sleep() statements in weird ways. We might want to try going back to print statements temporarily just to see if it makes the Rover perform better.
- Another thing that could be affecting the threading is this part from the newer code:

            self.speeds = self.get_speeds(
                # change self.base_speed to base_speed
                self.base_speed,
                bearing_to,
                200,
            )  # It will sleep for 100ms
            sleep(0.1)  # Sleeps for 100ms

Ok so in terms of comparing the driveAlongCoordinates function between the old version and the version we're running on the Rover, it definitely seems like the issue is a threading issue with the sleep() statements. Main 2 changes that could be causing the timing to get out of sync with what the old code was able to do are:
- The change from print statements to logging: while it IS better to use logging statements within threads, the reason they're better is because print statements do have the ability to affect the timing/synchonization of the code, and can mess with sleep() statements in weird ways. We might want to try going back to print statements temporarily just to see if it makes the Rover perform better.
- Another thing that could be affecting the threading is this part from the newer code:

            self.speeds = self.get_speeds(
                # change self.base_speed to base_speed
                self.base_speed,
                bearing_to,
                200,
            )  # It will sleep for 100ms
            sleep(0.1)  # Sleeps for 100ms

In the original code, the 3rd argument to the function was 100, not 200, and it was for the "timing" part of the function, which I assume is why it says that the code will sleep for 100ms. But for some reason (feel free to explain, I'm just unaware why), we changed it to 200ms, but then still only sleep for 100ms afterwards. It might be a good idea to either change back to 100ms, or if there's a reason to switch to 200ms, then we could try changing the sleep statement afterwards to sleep(0.2) to match the timing of the function.

In the original code, the 3rd argument to the function was 100, not 200, and it was for the "timing" part of the function, which I assume is why it says that the code will sleep for 100ms. But for some reason (feel free to explain, I'm just unaware why), we changed it to 200ms, but then still only sleep for 100ms afterwards. It might be a good idea to either change back to 100ms, or if there's a reason to switch to 200ms, then we could try changing the sleep statement afterwards to sleep(0.2) to match the timing of the function.