2bndy5 / drivetrain Goto Github PK

I have a port of this library for circuitpython MCUs that can't use the threading module acting as a counterpart to the NRF24L01 interface. We also have that C++port in the arduino-miner repo to act as a counterpart for the USB interface.

These solutions need a better home, for just 10 cent a day, you too could....blah blah blah

Its even worse on the TX2: no pre-existing libraries at all. nVidia officials are still suggesting to do sof-timed PWM on the TX1 + TX2. At least we can use pigpio or rpi.gpio on the raspberry pi

all the following code references assume myThread = threading.Thread(target=func_pointer) where func_pointer is the function that is executed by the myThread object once myThread.start() has been called. NOTE: func_pointer() is the functionality we want to reuse to smooth acceleration/deceleration on the drivetrain/motor object(s).

As it turns out, myThread.join() will block until the thread is considered "not alive" which can be determined as a bool by calling myThread.is_alive(). If we pass a timeout value to join(timeout=5.5), then the function will only wait for the myThread has finished for a up to 5.5 seconds. This does not mean the thread is finished if the timeout has been reached, rather the thread is still busy and join gave up on waiting for it to finish. Despite wheather the thread is alive or not, to execute a threaded func_pointer(), the func_pointer needs to be passed again as the target parameter to newThread = threading.Thread(target=func_pointer) object (and initiated with newThread.start() function). This is problematic since both threads can be executing simultaneously instead of aborting previous thread and re-start()-ing in under the newThread's context. Using the threading module's context managers -- like using with statements -- won't solve this either because they only care about what main program "owns" the thread.

Furthermore, threads only get cleaned up or deleted when the main python program exits (to the best of the interpreter's ability -- see the paragraph about "dummy/alien threads" just above this link). This is why we need to better manage the threads that are created.

Enter the multiprocessing module... More on this when I get my hands dirty. As it is the drivetrain is stable, so I'll be starting a new branch to do some preliminary tests.

In order to test/play with mechanism wheels, we need a class that takes 2 Tank drivetrain objects upon instantiation and uses them to drive a robot with 4 mecanum wheels oriented (pointing) in the same direction. Each of the wheels' "treads" (the free spinning angled parts that make up the contact surface with the terrain) should be 45 degrees from the robot's center. This new class should take the same x-axis and y-axis input commands, but with the addition of a strafe Boolean to indicate weather turning should alter the robot's facing direction or not.

To allow for non direct GPIO usage like via USB/I2C/etc, the motors' c'tors should take PWMOut or DigitalInOut objects where applicable; not board.<Pin_numbers>. This also better allows for compatibility with MicoPython via new included helpers or other objects made to be PWMOut-like wrapper classes.

There is a use case for instantiating a single Solenoid object with 2 pins (using 2 separate solenoids in concert): an engine akin to that that of actual locomotive trains. Think about it! Each solenoid applies force in alternating turns... Of course, this requires a new Drivetrain child class that coordinates the solenoids based on a boolean-ized sensor (like a pressure switch or hall sensor) to determine when to alternate applied force between solenoids (the default behavior of the Solenoid class when its value is changed from positive to negative and vice versa).

We should support the cheap BLE Serial modules via UART bus; 1 for RX-ing commands, and 1 for TX-ing. It may be possible to use Bluetooth modules if they are builtin or the MCU is Bluetooth compatible (nRF52840 based boards).

Alternative Leads

Outside of that, I think we can just use Linux Bluetooth stack to manage the devices and just grab events with python-evdev. I know CircuitPython's bleio API seems to follow IanHarvey's bluepy (for CPython) API (bluepy github). I am interested in using a webapp server running on the pi to manage the Bluetooth Devices "Trusted" list on Linux. Windows may need more research, but I've had success using a "Serial Monitor" on Windows with its builtin Bluetooth module acting as a Bluetooth Serial to my Phone's and Raspberry Pi's builtin Bluetooth modules

a backburner issue, but opened this issue as a self reminder