Coupling optimal control software to VDrift - Printable Version +- Forums (https://www.vdrift.net/Forum) +-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4) +--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9) +--- Thread: Coupling optimal control software to VDrift (/showthread.php?tid=949) Coupling optimal control software to VDrift - vicovermeer - 05-02-2008 Hi there! Let me start by describing who we are and what we want to do, before I actually pose my questions... We are mathematicians from the University of Heidelberg, Germany. We are interested in optimal control algorithms, and in particular in discrete decisions, such as gear choices. So far we optimized the driving on an elliptic track and visualized the results with Povray. Right now we are thinking about a coupling between the state-of-the-art optimization algorithms we develop and an open source race simulator such as VDrift. If this works one might compare the different AI robots VDrift already has with a provably optimal solution. And we would have a brilliant way to visualize the results of our optimization algorithms. Well, there are several things we want to do on the long run. 1. The first step will be to adapt the physical model we currently use to the one in VDrift / vamos. And to select a specific track, use an appropriate coordinate system for it and calculate (in our software) an offline solution. Offline means that there is no feedback from the system (= VDrift). This calculated solution would then be used for a simulation inside VDrift (will probably crash in the first curve because of a slight model mismatch or different integration...). 2. In a next step we might try to get more robust solutions, taking a certain model mismatch into account from a mathematical point of view. This would lead to a slightly less performant, but eventually working driving behavior. 3. The next step would be to include feedback information from VDrift (we call that Nonlinear Model Predictive Control). Here we would have two integrators run at the same time, on one hand Muscod which is using information obtained from VDrift (current position, velocity, ...) to calculate FASTLY a new optimal control. And on the other side VDrift which runs just as usual, but provides feedback information every 4 (or 20 or whatever) msecs and gets a new control input. We typically apply this procedure to real-world systems (like a distillation column, car engines, harvesters, you name it). Here we would simply consider VDrift to be the real world and our ODE model of an inprecise mathematical model for it. Well, this is the basic idea. So what do we need (besides understanding the physics and coordinates you use)? Well, in the first two steps simply a way to alter the controls (and also to obtain the trajectory in a written file or something for a posteriori analysis). For the third step, which is still a little bit ahead so we shouldnt worry too much about it now, we will need a communication between two programs running at the same time (NMPC optimizer and VDrift). We thought about using pipes for this. The data is the same as before, controls in, trajectory data out. The main points to start with are (and here are finally my questions): What coordinates are you using and in what format are the tracks described? In what files (functions) do we find the physical ODE model? Is a description (paper or thesis) available? Is there already an interface function to set/get controls and to get the output of your integrator? Or: in what files / module / class should we integrate it? - Where in the code do we have for interfaces we might use? We want out (if possible in realtime) * position * velocity * relevant angles * ... and would like to put in something like * gear * acceleration * brakes * steering angle that would be given to the vamos engine. Do such interfaces exist? How much work would it be (for us) to include them? I would be very grateful if someone (rookie1?) might help us out with these basic questions. I estimate that VDrift might also profit very much from this: although Muscod is a proprietory software of the University of Heidelberg and can thus not be included in VDrift, we hopefully get some nice results analyzing existing algorithms and enhancing them. Plus that the created interfaces will then also work for other (possibly open source) external optimization codes. And VDrift could get a lot of free advertisement, as well. Thanks a lot, best regards, Sebastian Sager Re: Coupling optimal control software to VDrift - rookie1 - 05-04-2008 Great to have some one working on AI again! I'll try to answer your questions as best I can. vicovermeer Wrote:What coordinates are you using and in what format are the tracks described?According to Joe, there are a number of coordinate systems used in vdrift. I have mainly dealt with 2 of them when developing the AI driver. The 1st one is used by vamos. The positions in this coordinate system is represented by class Vamos_Geometry::Three_Vector (defined in include/vamos/geometry/Three_Vector.h). The other is used by vdrift track. Positions are represented by class VERTEX (defined in include/3dmath.h). To transform between these 2 coordinate systems, use the following (assumeing v1 is a Three_Vector object, v2 is a VERTEX object), v1[0] = v2.x; v1[2] = v2.y; v1[1] = -v2.z; Vdrift track is defined in include/track.h. Each track contains a number of roads. Each road contains a sequence of Bezier patch. Bezier patch is the basic component of the track. Track data is defined in data/tracks//roads.trk. Following is the format of this file, Control point coordinates of Bezier patch 1 (total 16 points) Control point coordinates of Bezier patch 2 (total 16 points) . . . . Control point coordinates of Bezier patch 1 (total 16 points) Control point coordinates of Bezier patch 2 (total 16 points) . . . . and so on vicovermeer Wrote:In what files (functions) do we find the physical ODE model? Is a description (paper or thesis) available?If I'm not wrong, Vdrift uses Bullet now instead of ODE. Joe probably can answer this question better. vicovermeer Wrote:Is there already an interface function to set/get controls and to get the output of your integrator? Or: in what files / module / class should we integrate it? - Where in the code do we have for interfaces we might use? We want out (if possible in realtime) * position * velocity * relevant angles * ... and would like to put in something like * gear * acceleration * brakes * steering angle that would be given to the vamos engine. Do such interfaces exist? How much work would it be (for us) to include them?The cars in vdrift are represented by a Vamos_Body::Car object. As long as you have a reference/pointer to this object, you can get all the realtime info such as position, velocity, angles, etc, as well as setting the control inputs. For example, assuming you have a pointer *car points to your AI controled car, call car->chassis().cm_velocity() to get the velocity vector. Calling car->chassis().position() will get the position vector. Similarly, calling car->brake(brake_value, 0.0) and car->gas(gas_value, 0.0) to set the brake and gas input respectively. Hope I'm making sense with the above. Let me know if you need more info. I'm sure Joe or thelusiv can also give some input if you need more help. Re: Coupling optimal control software to VDrift - joevenzon - 05-05-2008 vicovermeer Wrote:In what files (functions) do we find the physical ODE model? Is a description (paper or thesis) available? Unfortunately the physical ODE (ordinary differential equation) model used by Vamos is spread throughout a number of files: basically, everything in the include/vamos/body and src/vamos/body folders. The car chassis is treated as a rigid body, and forces are applied to the body using F=ma, a=F/m. The acceleration term is numerically integrated with a fixed timestep (dt=0.004 seconds, by default) to generate velocity and position. Rotation is similar. The numerical integration is the first-order euler method. I attempted to convert the integration to use the second-order verlet integration method, but due to how Vamos is structured I believe it ends up mathematically reducing to the first-order euler method in most cases. Here is the way that vamos generates forces for each physics update: Code:```NOTE: particles can be suspension, suspension hinge, wheel, drag, contact_point, particle, engine, fuel tank car propagate (false) * chassis propagate (false) * * update center of mass * * propagate particles (false) * * * wheel propagate (false) * * * * tire propagate (false) * * * * * calculate rotational speed based on applied torque / inertia * * * * calculate ang pos using tire ang vel, tire torque, and tire inertial * * * engine propagate (false) * * * * if clutch engaged, set rotational speed to transmission speed * * * * else set rotational speed to velocity verlet of drive torque / inertia * * set [ang] accel, delta [ang] pos, and cm & ang velocity to velocity verlet of torque / inertia and force / mass * * set velocity using euler of this position & last position * drivetrain input * * set drivetrain speed to differential speed world interact * car chassis contact * * wheel contact * * * updates wheel posn/vel, adds wheel force to suspension force car propagate (true) * drivetrain findforces * * find drag based on engine rotational speed * * if in gear * * * if clutch engaged, engine input, set torque to drive torque * * * else set torque to drag, engine input * * * * engine input just sets transmission speed to value passed in * * else * * * engine input * * set differential left & right wheel torques based on drivetrain torque * set wheel drive torque to drivetrain torque * chassis findforces * * particle findforces * * * suspension findforces * * * * calculate force based on constants, displacement, and compression velocity * * * wheel findforces * * * * tire input ... based on wheel velocity, suspenison force, etc * * * * * sets velocity, normal force, etc * * * * tire findforces * * * * * set force based on pacejka of velocity, normal force, etc * * * * set wheel force & torque to tire force & torque * * * drag findforces * * * * set force based on velocity, etc * * * contact_point findforces * * * * if no contact, set force to zero * * * engine findforces * * * * set drive torque based on gas & rotational speed & drag * * add particle force to chassis force * * add particle torque to chassis torque * * add gravity to chassis force * chassis propagate (true) * * propagate particles (true) * * * wheel propagate (true) * * * * tire propagate (true) * * * * * calculate rotational speed based on applied torque / inertia * * * engine propagate (true) * * * * if clutch engaged, set rotational speed to transmission speed * * * * else set rotational speed to velocity verlet of drive torque / inertia * * set cm & ang velocity to velocity verlet of torque / inertia and force / mass * set distance traveled using euler of velocity```