Open ghost opened 7 years ago
These are my initial thoughts, as discussed with @amiller27 and @aftersomemath this week. I started to play with what the code might look like in b74d063ca487726d3b75e607f754e678fc6b9fda (headers only).
It's a bit vague, but hopefully it makes some structure apparent.
... and worth noting that since that drawing, I've at least
Drivetrain
to SkidSteerCar
drive()
function between Maneuvers
and SkidSteerCar
as the place where gyro and range get pre-baked into the LinearRotationalProfile
For anyone interested: Proof of concept for Straight
on branch motion-test-1
(557058fae6bfe63018ac4f5974b8ae75288a8b31).
I've convinced myself that the general structure for new motion is working. Now I need to straighten out the other maneuvers and tune everything. I found out our feed-forward tuning is currently awful, but I think we knew that :-)
Also worth noting. With encoders only, the robot drives way more smoothly than legacy motion. Depending on what we observe, we might want to investigate smoothing range and/or gyro errors.
New concept that I'm currently working on using "matrix" math. Will allow independent control and tuning of linear/rotational feed-forward/correction. Has plenty of errors and oversights, but I like where this is going.
This would replace SkidSteerCar
, PointOnBody
, and Wheel
.
Worth noting, this issue will also involve #12 and #13. To tune new motion we'll need to tune feed-forward followed by PID for all components.
Straight
and Pivot
zig-zag proof of concept on branch motion-test-2
(9dc236c4953ee0625d13ac5343d2aab7d40884b4).
Today, each type of motion is a function declared in
motion.h
, such asmotion_forward()
andmotion_corner()
. Though motions do use common elements such as a linear trapezoidal motion profile calculator, sensors, and motors, there is still a lot of repeated code. Moreover, the code is hard to understand to the point that further development is difficult.The first thing we need is a design discussion.