Open Ezward opened 2 years ago
@Ezward,
The whole reason for using an RC controller is to be able to drive a DC robot chassis without using a webui over WiFi. I believe that a phone webui would require having the SBC be the WiFi Hotspot or have to have a local WiFi Hotspot. When I drive my DC robot chassis I use the screen app to keep DC running while it is out of WiFi range and reestablish an SSH connection over WiFi when it is back in range. Since I can't use a gamepad at the same time I am using an RC controller with the path_follow.py template, it would be nice to be able to be able to save the recorded path either with the RC controller or from the SSH CLI.
Regards, TCIII
I did an analysis of the RC controller code. It was super confusing because I think we have some abandoned code.
The method controller.py:get_js_controller() returns the chosen game controller class IF it is one based on controller.py:JoystickController class.
Notice https://github.com/autorope/donkeycar/blob/050009fbf09675e5034bbe04763187ca234528db/donkeycar/parts/controller.py#L1725
This is an RC controller with 3 channels. It is based on JoystickController, which means it is mapped to a Linux device at /dev/input/js0.
Now look at complete.py:add_user_controller(), the method that actually adds the controller(s) to the vehicle pipeline based on the configuration.
Note
This adds a controller that is not based on controllers.py:JoystickController at all. It is documented as having no buttons.
So it seems there are two configurations for RC controllers as joysticks; "pigpio_rc" and "rc3". They are implemented in two very different ways. The 'pigpio_rc' is a special controller that uses the pigpio library to read the channels of an RC controller. It does read 3 channels; it uses the third channel to cycle the user modes.
The 'rc3' seems to be a more traditional Linux driver that exposes the RC controller as a Linux device at /dev/input/js0 just like other joysticks. I suspect this magic is done using a Teensy or other microcontroller that can act as an HID (Human Interface Device) using some emulation and a USB connection. However, we don't have that sketch anywhere, so I suspect this is abandoned code. In anycase, with the RC hat we want read the joystick with the gpio pins. So I don't think we are using 'rc3' anymore.
'rc2' that has button code that is erasing the records etc. based on the button down or button up state (not just a simple button push)
The 'pigpio_rc' controller does not do this; it is hard coded to just cycle through the user and pilot modes. So if we changed that what would we do. What would the cycle be in path_follow and what would the cycle be in complete.py and what would the cycle be in the cv template? So there is no simple hack to make this work; if I touch it and make it work for path follow it will break the complete template. So we have to take a more considered approach.
For pigpio_rc we probably need to be able to define a cycle of states or calls that will be made as the button is pushed.
We probably want to handle several buttons; better controllers have more buttons available.
Or we could focus on making the phone's web ui have programmable buttons and stop it from sleeping, so users would be expected ot use their phones to get the game-controller functions while using an RC controller. See https://github.com/autorope/donkeycar/issues/928 and https://github.com/autorope/donkeycar/issues/1022
All of took me a couple of hours to figure out.