Implement single mixer class instead of separate throttle/steering classes

[yconst]

A single "mixer" class that handles command distribution to all actuators is more flexible than separate "throttle" and "steering" classes. For instance in differential or skid steering one should be aware of both the throttle as well as the steering value to assign correct (PWM) values to the actuators

[wroscoe]

Good point. I think the best place to add this would be as a new vehicle class that provided this awareness for skid steering vehicles in the drive loop. This library has so far focused on cars that steer by angling the front wheels but this would be a great addition. @adammconway may also have thoughts.

[adammconway]

Hi @yconst are you considering implementing a car based on differential drive using Donkey? am I understanding the request properly? thanks!

[yconst]

@adammconway yes indeed, I have a differential steering frame available and am thinking of "emulating" the constraints in "regular" car steering by limiting the difference in throttle to the motors on each side/making it proportional to collective throttle.

[adammconway]

@yconst that is awesome, so glad you are looking to join us.

@wroscoe feels like differential drive should be a different setup... this goes back to how we abstract out the various hardware. Downstream if we choose to add odometry and other sensors we will also have further differences. I know that sensors and actuators are separate now, but I think it is possible we will see interplay between them as we add certain sensors.

[wroscoe]

@yconst this would be great. We were looking to find a vehicle that could compete on the RGB(colored lines) track.

The place to put a new vehicle build would be below the BaseVehicle class here; https://github.com/wroscoe/donkey/blob/master/donkey/vehicles.py#L3 You could inherit the BaseVehicle class and change the drive loop to use the logic specific to the differential drive vehicle.

@adammconway There is no real difference between sensors and actuators. The files are used only for organization.

[yconst]

@wroscoe , @adammconway I took the liberty of modifying the actuator code to accommodate for mixing. I've pushed the changes in my fork currently: https://github.com/yconst/donkey/blob/actuator_mixer/donkey/actuators.py

I'm not sure, but I felt an additional level of abstraction between "vehicle" and "hardware" would make for better distribution of tasks. Thus came the mixer class.

There are also changes to the vehicle and demo classes to accommodate the new actuators class.

Please keep in mind, this is all just a concept, nothing is tested yet.

[wroscoe]

Great!. I made a pull request for this change and will merge once we have both types of cars working on this branch. https://github.com/wroscoe/donkey/pull/26

[yconst]

I fixed some errors in the files and separated them in different modules, ie added mixers.py.

Re. actuators, I saw that the current PWM classes inherited from the Adafruit controller base class. I thought that this could be better achieved by composition over inheritance, so in the latest commit I refactored the code a bit, and now the PWM classes take a "controller" as a init parameter. The controller is the fundamental hardware "driver" (in this case the Adafruit controller), and the PWM functionality is abstracted from the hardware.

This way, other controllers (e.g. I'm using a NAVIO hat) can be easily switched without needing to re-write the PWM workings.