ANSWER: There are two "top level" routines for the existing "planner" (which doesn't really plan, just generates a trajectory between waypoints:
- Trajectory_update() updates the trajectory states
- Trajectory_copy() pulls the current position/velocity/attitude command into the controller
However, they are called right after each other, so the distinction is not important at this point. updateTrajCommand() and triggerNextManeuver() are called by trajectory_update(), the first updates the trajectory internal states, the second decides if the current maneuver (usually a waypoint) has been reached and triggers the next maneuver if it has.
ANSWER: Check out the trajectory_copy() routine in planner.cpp - that's all of them. It's North/East/Down position, velocity, acceleration along the body-z axis, and attitude (quaternion). I think there is also some takeoff and landing logic in that routine you can ignore for now.
ANSWER: There are two ground sensors (downward pointing sonar and radar), so anything more sophisticated would need to be simulated for now. For now, I suggest that you populate the obstacles within your own software. Once you are ready, we can add these obstacles to the graphics to make them easier to visualize.
ANSWER: Script files are certainly one way. There are also other ways. You could add a command (you can look in gcs.c to see many examples of commands: drOn, controlInit, navInit, etc.). Note that scripts can also include these commands. These are the two main ways we give commands. The primary way to interact with the existing "planner" is through the scene generator (scene.c) using the mouse and key-strokes which you probably want to avoid until we really get the interface defined.
ANSWER: The controller you have in that release is a feedback-inversion based neural network adaptive control system, that is designed to follow 3-D trajectories that can be aggressive and out-of-trim. It will still work without feedforward acceleration/attitude commands - but just not near as well.
ANSWER: One approach would be to replicate the functionality of our planner.cpp file. That is, where trajectory_update and trajectory_copy are called in onboard.cpp, you can add a switch that will call your software instead. In terms of the data structures (in the .db files), you could simply add a new directory after our "trajectory" called "draper_traj" or something (this is in onboard.db).
ANSWER: We do not have any other documentation on the equations we used. However, I
would add the following to the reference list:
- Johnson, "Helicopter Theory", Dover, 1980.
- Stepniewski & Keys, "Rotary-Wing Aerodynamics", Dover, 1984.
- http://www.ae.gatech.edu/~ejohnson/A97-3511.pdf
ANSWER: No
- I am trying to build a S-function that will call the nonlinear dynamics and kinematics of the helicopter from simulink. The outputs of this function are for example du/dt, dv/dt, dw/dt, dp/dt, dq/dt, dr/dt. We will integrate these outputs in simulink and the inputs to the function will be: 4-control inputs (coll., lat, long, pedal) coming from our controller (built in Simulink) and all necessary variables to run the model such as (u,v,w, p, q, r , euler angles etc..). Thus, we do not need to use your integration function "updateMotion" but only the acceleration outputs. What are the necessary functions from the GT-Max code that are used for the model? Are they the following c-functions: aero.c, motion.c, rotors.c, gears.c? What would be the easiest way to do this S-function using your GT-max code?
ANSWER: The most relevant functions are updateMotion() and f() in motion.c. It is really f() as in xdot = f(x,u) that does most of the work. Essentially you are asking if you can replace the updateMotion part with simulink. I think it can be done. I've generated a simple C file (untested) that shows how I think the dynamics may be called standalone. I've not tested it but might give you a good start towards an S-Function. Attached is the sample code (untested). All you need to to is link to the rmaxlib and esimlib libraries.
ANSWER: There is no plan to release the core sim code unfortunately. However it is a very small purely opengl implementation that displays all the variables in the system. The rmax directory however contains most of the relevant code and is something that I believe you already have.
If you look ahttp://www.ae.gatech.edu/~ejohnson/A97-3511.pdft our controller.cpp there is a chunk of code in controller_update which sends out the actuator commands (and also saves in one other place for monitoring purposes). Essentially, your code must generate those actuator commands.
- I'm currently pondering different ways to replace your controller with our own. The first controllers we try would be written in Matlab, and we have usually wrapped the helicopter models (from MIT, our own, and from Flightlab) into MEX files so that the Matlab scripts can call them. Here, that doesn't sound like the best approach. Have you had any experience with prototyping controllers in Matlab and having them hooked up with the ESim?
ANSWER: I've never prototyped in Matlab and hooked up to esim. However I have used RT-Workshop before. Since it generates purely ANSI C code and if I remember correctly it the DT (integration time step) is something you pass to the generated code. Hence, all one has to do is deactivate the existing controller and insert your genrated code.
/* send off actuator commands to actuator interface */
mat_copy( il->delcmdr, 3, 1, act->delm );
mat_copy( ol->delcmdr, 1, 1, act->delf );
In the onboard.cpp the controller is called from taskControl and I suppose that is where you would insert your call to the rtworkshop generated code or other code.
With regard to matlab, if you must use it, I believe that the approach you are taking, by inserting into esim is better than sucking the simulation into matlab as an S-function