in the Aerospace Blockset in Simulink, the example model:
asbSkyHogg
in this block (asbSkyHogg/Vehicle System Model/Vehicle/3DOF to 6DOF/3DOF to 6DOF/calc alpha_dot) which is used to calcualate the rate of change of of angle of attack
The rate of change of of angle of attack is calculated based on the equation:
So, the acceleration (input #3) in body axes should be transformed to wind axes using the DCM Body-to-Wind as shown in the picture... but why the transpose block is added here???!! In this case, it's actually transformed to body axes again!!
I tried to comment through the transpose block, but I need confirmation if I'm wrong or not, and why it's added.
Related
I am leveraging SimMechanics, SimElectronics, and Simulink to model a quadcopter system for an embedded system class project ( files here ). I have generated a 2nd Generation SimMechanics model of an F450 quadcopter frame, including the motors and propellers. We were hoping to develop a model of a quadcopter with only a single rotational degree of freedom around either the x or y axis. I was hoping to model this with a revolute joint connecting the quadcopter frame to the "world frame". However, the "revolute joint" block in SimMechanics only acts around the z-axis. How can I change the axis of rotation for a revolute joint?
It appears that another individual has asked the same question, but no one has yet responded to his question.
See Assembling Multibody Models in the SimMechanics documentation, in particular the section on "orienting joints":
To obtain the motion expected in a model, you must align its various
joint motion axes properly. This means aligning the joints themselves
as observed or anticipated in the real system. Misaligning the joint
axes may lead to unexpected motion but it often leads to something
more serious, such as a failure to assemble and simulate.
You can specify and change joint alignment by rotating the connection
frames local to the adjoining body subsystems. For this purpose, you
specify rotation transforms using Rigid Transform blocks, either by
adding new blocks to the body subsystems or, if appropriate, by
changing the rotation transforms in existing blocks within the
subsystems.
Why change the orientation of joints through body subsystem frames?
The primitives in a Joint block each have a predetermined motion axis,
such as x or z. The axis definition is fixed and cannot be changed.
Realigning the connection frames local to the adjoining body
subsystems provides a natural way to reorient joints while avoiding
confusion over which axis a particular joint uses.
For an example of how to rotate joint connection frames, see Model
Mount.
So the answer is to use a Rigid Transform block to change the orientation of the frames, you cannot change the axis of the revolute joint.
I think you should change it in your CAD file. Change your propeller axis to align with z axis. But you should only change the propeller axis, not the whole body.
I am trying to write a matlab code to model the projectile motion of a cannon shell including the effects of air drag and air density that changes with respect to temperature, however the code I have so far only computes a straight line for the shell trajectory which is incorrect. Can anyone point out where I have gone wrong and point me in the right direction to include the effect of air density and temperature? Thanks.
clear;
%input parameters
v0=input('Enter the muzzle velocity (m/s) ');
theta=input('Enter the quadrant elevation (degrees) ');
%T0=input('Enter the value for the ground temperature in degreees ');
%T0=T0+275.16;
b2bym0=4e-5;
g=9.8;
dt=1e-2;
%define initial conditions
x0=0;
y0=0;
vx0=v0*cosd(theta);
vy0=v0*sind(theta);
fdragx=-b2bym0*v0*vx0;
fdragy=-b2bym0*v0*vy0;
n=1000; %iterations
%Tratio=(T0/300)^(2.5);
%define data array
%t=zeros(1000);
x=zeros(1000); %x-position
y=zeros(1000); %y-position
vx=zeros(1000); %x-velocity
vy=zeros(1000); %y-velocity
for i=1:n
t(i)=i*dt;
vx(i)=vx0+fdragx*dt;
vy(i)=vy0+fdragy*dt;
x(i)=x0+vx(i)*dt;
y(i)=y0+vy(i)*dt;
x0=x(i);
y0=y(i);
vx0=vx(i);
vy0=vy(i);
end
plot(x,y,'g+')
it doesn't look like you are modeling the downward acceleration of g force for your y velocity
Looks like there were three issues.
First you missed gravity in updating vy. Fixed
Second drag force was not updating with the velocity. Fixed
Thirdly, your calculating the new position/velocities using the initial values and not the previous ones. In the loop try changing these lines. You might have to update your for loop to go from 2:n if matlab indexes at 1.
vx(i)=vx(i-1)+fdragx*dt;
vy(i)=vy(i-1)+(-g+fdragy)*dt;
x(i)=x(i-1)+vx(i)*dt;
y(i)=y(i-1)+vy(i)*dt;
Edit:
Didnt see the update of the initial conditions, disregard the third comment.
I have N 3D observations taken from an optical motion capture system in XYZ form.
The motion that was captured was just a simple circle arc, derived from a rigid body with fixed axis of rotation.
I used the princomp function in matlab to get all marker points on the same plane i.e. the plane on which the motion has been done.
(See a pic representing 3D data on the plane that was found, below)
What i want to do after the previous step is to look the fitted data on the plane that was found and get the curve of the captured motion in 2D.
In the princomp how to, it is said that
The first two coordinates of the principal component scores give the
projection of each point onto the plane, in the coordinate system of
the plane.
(from "Fitting an Orthogonal Regression Using Principal Components Analysis" article on mathworks help site)
So i thought that if i just plot those pc scores -plot(score(:,1),score(:,2))- i'll get the motion curve. Instead what i got is this.
(See a pic representing curve data in 2D derived from pc scores, below)
The 2d curve seems stretched and nonlinear (different y values for same x values) when it shouldn't be. The curve that i am looking for, should be interpolated by just using simple polynomial (polyfit) or circle fit in matlab.
Is this happening because the plane that was found looks like rhombus relative to the original coordinate system and the pc axes are rotated with respect to the basis of plane in such way that produce this stretch?
Then i thought that, this is happening because of the different coordinate systems of optical system and Matlab. Optical system's (ie cameras) co.sys. is XZY oriented and Matlab's default (i think) co.sys is XYZ oriented. I transformed my data to correspond to Matlab's co.sys through a rotation matrix, run again princomp but i got the same stretch in the 2D curve (the new curve just had different orientation now).
Somewhere else i read that
Principal Components Analysis chooses the first PCA axis as that line
that goes through the centroid, but also minimizes the square of the
distance of each point to that line. Thus, in some sense, the line is
as close to all of the data as possible. Equivalently, the line goes
through the maximum variation in the data. The second PCA axis also
must go through the centroid, and also goes through the maximum
variation in the data, but with a certain constraint: It must be
completely uncorrelated (i.e. at right angles, or "orthogonal") to PCA
axis 1.
I know that i am missing something but i have a problem understanding why i get a stretched curve. What i have to do so i can get the curve right?
Thanks in advance.
EDIT: Here is a sample data file (3 columns XYZ coords for 2 markers)
w w w.sendspace.com/file/2hiezc
I am simulating a system where I need Direction Cosine Matrix to quaternion conversion. I use the default DCM to Quaternion conversion block available in simulink. However at some points of the simulation, the output quaternion components reverse sign.
Unfortunately I cannot attach the plot image.
Though this is mathematically correct I desire a smooth change. Any idea on how to avoid this and have a smooth curve for the quaternion?
Update 1:
http://tinypic.com/view.php?pic=33dayap&s=6
Above is the simulated plot. The first plot is of the output quaternion. Second plot is of the Direction Cosine Matrix. As you see that even though the dcm components change smoothly, the quaternion changes sign abruptly.
The problem arises because of the double covering property of quaternions: Two unit quaternions correspond to every rotation. At some point, according to some rule, the Matlab implementation switched from one quaternion to the other. There is not much you can do about it.
A messy workaround would be to write your own rotation matrix to quaternion conversion, and pick that representation of the two possibilities that is closer to the previous one, hence avoiding the sudden jumps. It's messy.
Plotting the quaternions is typically not needed in practical applications. Most likely you are rotating an object / vector. If you plot that object / vector (or some projections of it) you won't get any sudden jumps even if there are jumps in the representation of the rotation. Another benefit of plotting the projections of the rotated object is that it is usually much easier to interpret these plots than the quaternions. I don't know whether it makes sense in your application; it worked beautifully in mine.
I am trying to convert an array of velocity values to acceleration values. I understand that acceleration is the integral of velocity, but don't know how to acheive this. I am using MATLAB, so if anyone can offer a solution in this language, I would be very grateful! See the graph below:
The yellow line plots the velocity and the vertical dotted lines show the peaks and troughs of that waveform (peaks and troughs found using peakdet). The green horizontal stuff in the middle is unrelated to this question.
What I am trying to isolate is the steepest part of the large downward slopes on the curve above. Can anyone offer any advice on how to calculate this?
P.S. I am aware that quad() is the function used to integrate in MATLAB but don't know how to implement it in this situation.
Acceleration is a derivative of velocity.
If your velocity values are stored in v, you can get a quick numerical derivative of v with
a = diff(v)
Be aware that if v is a real rather than synthetic signal, a is likely to be pretty noisy, so some smoothing may be in order, depending on how you're going to use it.