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.
Related
I want to compute the Euler angles from a rotation matrix in order to find out the orientation associated to that rotation. For that purpose, I am using MATLAB and the function rotm2eul that gives me the rotation first about x-axis, then about y-axis and finally the z-axis.
I am using a signal with 1000 frames and for each frame a rotation matrix is computed, as well, the three Euler angles. However, when I am going to see the Euler angles' curve, there is some "jumps" as I shown on the figures below.
On Technique 1, I think it jumps from -180º to 180º which should be the same. In fact, the upper portion of the plot seems a continuation of the lower portion. So in this case I thought I could subtract 360º to the upper portion to get the plot. But I am not sure if I do this I am falsifying the results.
On Technique 2, it makes a jump with a different reason of the previous one. I think it must be because the angle associated with the y-axis reaches 90º which should be a boundary case. But in this case I don't know how should I correct the data or , like previously, if I want to correct the plot is falsifying the euler angle result.
Technique 2: This is a Gimbal lock, known feature of Euler angles. You can't avoid it completely. You can change the rotation order, but it will appear in another position.
How can I create radial images like this (see images below)
My goal is to control the number of radial arms, thinkness, along with the angle they are created. I'm trying to create patterns that will show me different Moiré patterns when overlapped and turned / animated in octave / matlab.
PS: I'm using octave 3.8.1
I've tried the code here but it doesn't give me the fine tuning all of the following parameters, of radial arm amount, angle, and thickness. Also the image package is needed which I'm trying to avoid.
http://www.mathworks.com/matlabcentral/answers/uploaded_files/20287/moire_pattern.m
As I see it the two approaches which would be worth investigating first are equations and patches.
You could for instance generate a generic equation for an arm with parameters to control the rotation angle and the shape of the curve. You could then plot that at each of a given number of rotation angles, with varying linewidths (a plot property not an equation parameter). Your equation would probably not look pretty as you'd be best off specifying it parametrically (in terms of a third variable) or in polar coordinates, and then translating it to cartesian for the plot commands.
With patches you'd be computing the outline of the arm (as opposed to the centreline) and would probably find it convenient to generate the patch for one arm and then transform it for each rotation. This would be a one-liner with the appropriate rotational transform matrix, and the expression you use to generate the arm wouldn't need to be nearly so complex as it wouldn't need to handle the rotation. A quadratic might even do at a push.
Another advantage of patches is that, having generated an arm and rotated it around, you could also flip it and generate the figure with the opposite sense for very little extra code.
So, this is going to be pretty hard for me to explain, or try to detail out since I only think I know what I'm asking, but I could be asking it with bad wording, so please bear with me and ask questions if need-be.
Currently I have a 3D vector field that's being plotted which corresponds to 40 levels of wind vectors in a 3D space (obviously). These are plotted in 3D levels and then stacked on top of each other using a dummy altitude for now (we're debating how to go about pressure altitude conversion most accurately--not to worry here). The goal is to start at a point within the vector space, modeling that point as a particle that can experience physics, and iteratively go through the vector field reacting to the forces, thus creating a trajectory of sorts through the vector field.
Currently what I'm trying to do is whip up code that would allow me to to start a point within this field and calculate the forces that the particle would feel at that point and then establish a resultant force vector that would indicate the next path of movement throughout the vector space.
Right now I'm stuck in the theoretical aspects of the code, as I'm trying to think through how the particle would feel vectors at a distance.
Any suggestions on ways to attack this problem within MatLab or relevant equations to use?
In order to run my code, you'll need read_grib.r4 and to compile that mex file here is a link to a zip with the code and the required files.
https://www.dropbox.com/s/uodvixdff764frq/WindSim_StackOverflow_Files.zip
I would try to interpolate the wind vector from the adjecent ones. You seem to have a regular grid, that should be no problem. (You can use interp3 for this)
Afterwards, you can use any differential-equation solver for your problem, as you have basically a field of gradients and an initial value. Forward euler would be the simplest one but need a small step size. (N.B.: Your field should be a gradient field)
You may read about this in Wikipedia: http://en.wikipedia.org/wiki/Vector_field#Flow_curves
In response to comment #1:
Yes. In a regular grid, any (arbitrary chosen) point will have eight neighbors. interp3 will so a trilinear interpolation to determine an interpolated gradient vector.
If you use forward-euler, you will then move a small distance in that direction. There you interpolate a gradient and go a small step into this new direction and so on. What happens are two things:
You get a series of points that lie on a streamline and thus form the trajectory of a particle moving along the field
Get large errors, the further you move and the larger the step size is. Use a small step size or use a better solver (Runge-Kutta comes to my mind)
If all you want is plotting, then the streamline function might help.
When showing the extrinsic parameters of calibration (the 3D model including the camera position and the position of the calibration checkerboards), the toolbox does not include units for the axes. It seemed logical to assume that they are in mm, but the z values displayed can not possibly be correct if they are indeed in mm. I'm assuming that there is some transformation going on, perhaps having to do with optical coordinates and units, but I can't figure it out from the documentation. Has anyone solved this problem?
If you marked the side length of your squares in mm, then the z-distance shown would be in mm.
I know next to nothing about matlabs (not entirely true but i avoid matlab wherever I can, and that would be almost always possible) tracking utilities but here's some general info.
Pixel dimension on the sensor has nothing to do with the size of the pixel on screen, or in model space. For all purposes a camera produces a picture that has no meaningful units. A tracking process is unaware of the scale of the scene. (the perspective projection takes care of that). You can re insert a scale by taking 2 tracked points and measuring the distance between those points. This is the solver spaces distance is pretty much arbitrary. Now if you know the real distance between these points you can get a conversion factor. By doing:
real distance / solver space distance.
There's really now way to knowing this distance form the cameras settings as the camera is unable to differentiate between different scales of scenes. So a perfect 1:100 replica is no different for the solver than the real deal. So you must allays relate to something you can measure separately for each measuring session. The camera always produces something that's relative in nature.
I have two ellipsoids in R3 described in terms of their centre points (P), their axes lengths (a,b,c), and their rotation vector (R). I wish to interpolate a tubular structure between these two ellipsoids along a given centre line. This is done by creating an ellipsoid centred at each point along the centre line. Its axes lengths are interpolated linearly between those at the two endpoints, and the rotation is obtained as a quaternion using spherical linear interpolation, or SLERP.
I previously asked a similar question on this problem here. I have since isolated the issue a little further, and thought it warranted a new post. The difference here is that before doing SLERP, I first rotate the two reference ellipsoids by the inverse of the rotation matrix that describes one of them, such that one of them is now axis-aligned (i.e. has no rotation). Previously this appeared to solve the problem, but I have encountered an example where this fix does not work.
The source code to reproduce this issue is available here. The relevant function is ellipsoidSLERP and the functions it calls. Here is a screenshot of the output:
What you are seeing is an interpolation of ellipsoid volumes (blue) between two reference ellipsoid volumes at either end (green) along a centreline (cyan).
Problem Statement
The interpolation on the left works correctly, resulting in a smooth tubular structure. The interpolation on the right does not work correctly, and results in a twist.
What is causing this behaviour, and how can I correct it?
Please let me know if there's anything I can do to clarify.