Instead of returning accel, what if we return (dist to travel this tick, new speed).
- How can we sanity check that those choices are reasonable? Seems like we
still have to sorta reason about acceleration properties of vehicles.
- But maybe not. each constraint...
- dont hit lead... if we're ALREADY close to them (current speed * timestep puts us within follow_dist of them right now), just warp follow_dist away from where they are now.
- if we need to stop for a point that's close, then we ideally want to do the kinda (do this distance, over this duration) thing and somehow not reason about what to do the next few ticks. event based approach for one thing. :\
Or different primitives, much closer to event sim...
- Often return (dist to wind up at, duration needed to get there)
- linear interpolate position for rendering in between there
- use for freeflow travel across most of a lane
- to slow down and stop for a fixed point, do a new interval
(STOPPING_DISTANCE_CONSTANT, few seconds to stop). the vehicle will
kinda linearly slow down into the stop. as long as the stopping
distance and time is reasonable based on the vehicle and the speed
limit (freeflow vs shuffling forwards case?), then this'll look fine.
- What about following vehicles?
- it'd be cool to have some freeflow movement to catch up to a lead vehicle, but if we look at the lead's position when we first analyze, we'll cover some ground, then replan again and do zenos paradox, planning freeflow for less new dist...
- parked cars departing will have to interrupt existing plans!
- rendering becomes expensive to do piecemeal; need to process cars in order on a queue to figure out positions. if we need to lookup a single one, might need to do a bunch of hops to figure out the front.
- not really easy to percolate down a single time to pass the intersection from the lead vehicle... intersections need to stay pretty detailedish.
