donkeycar
donkeycar copied to clipboard
autorope
921 tachometer odometer kinematics parts
Add new encoder, tachometer, odometer and kinematics parts
- the encoder/tachometer/odometer break up the these concerns into separate layers so we can avoid hoisting all that functionality into each separate encoder.
- encoders simply count ticks
- tachometers take ticks and output revolutions
- odometers take revolutions and output distance and velocity
- We support either one odometer for car-like vehicles or two encoders/odometers for differential robots.
- the kinematics are used to estimate the vehicle pose (x, y, heading). This will eventually be used in two ways
- we can use this as a source of pose in the path_follow template. TBD in a separate pull request.
- we can use this, along with closed loop speed control, to implement a velocity based neural network model. TBD in a separate pull request.
- car-like vehicles uses bicycle kinematics
- differential drive vehicles uses unicycle kinematics
All of these parts have been run-tested for a few months in another branch using a highly modified path_follow.py. That branch has a lot of changes, so I've created this pull request just for the encoder/odometer/kinematics pipeline. Future pull requests will 1) add changes to path_follow to bring it up to snuff with the complete template 2) add closed-loop speed control and a velocity-based neural network model.
This is draft because I still need to test it on track.
Status is that the kinematics are producing a repeatable path, but it is not accurate. so the strange results is that if you record a path and put it in path follow mode then it will looks like it is doing a great job. However, if you look at the path (I've added the ability to save path as .csv) in something like https://www.csvplot.com/ the path will not look anything like what your recorded. So the path looks totally wrong, but because it is repeatably and reliably wrong in the same way each time the PID path follow algorithm can still 'follow' the wrong path and get the correct real-world output.
We've added in support for odometry/kinematics in the simulator and it seems to produce a similar issue. NOTE that all of these tests are currently with a differential encoder setup.
I've checked and rechecked the math; it looks correct; same math as I have used in other projects and their paths look correct.
My current thinking is that we don't have a fast enough update loop. The encoders and kinematics are running in non-threaded mode, so locked in at 20hz, which may be too slow for good pose estimation. The kinematics formulas assume that vehicles has driven in a straight line between estimates; we may be build error very quickly because we break this assumption. This theory is supported by the behavior we see; the path look correct if you just go straight, but creates weird loops when attempting to turn. The other potential issue is the lag between getting an encoder update and making a pose estimate; because these are all separate parts and we may get interrupted by threaded tasks (we have a lot of those), we may have varying latency between when we get an update an when we apply it.
So I think the next thing to do is make sure the serial encoder and kinematics can run in threaded mode. We may also want to make those a single process so that we update the pose immediately after getting an encoder update.
Another potential way to handle this is to change the vehicle loop so that it runs as fast as it can. By default we will still only call non-threaded parts at 20hz. However, we can add a part as non-throttled so it will get called as fast as the loop can go. Doing that we could avoid a lot of issues with trying to coordinate a bunch of separate threaded parts.
This effectively what I do in the Esp32CameraRover project; it's update loop runs at full speed. Some things throttle themselves based on current time. Others greedily run as fast as they can. It can do pose estimation and line following and it is using a microcontroller (Esp32) not a full SBC.