I am testing SITL with DroneKit, and I cannot seem to make a plane take off. When I do arm throttle, the console says:
APM: PreArm: 3D accel cal needed
I tried to run accelcal, and it asks me to calibrate the plane like so:
APM: Place vehicle level and press any key.
APM: Place vehicle on its LEFT side and press any key.
APM: Place vehicle on its RIGHT side and press any key.
APM: Place vehicle nose DOWN and press any key.
APM: Place vehicle nose UP and press any key.
APM: Place vehicle on its BACK and press any key.
APM: AccelRange: 0.0 0.0 0.0
APM: Insufficient accel range
APM: AccelRange: 0.0 0.0 0.0
APM: Insufficient accel range
APM: Calibration FAILED
How can I calibrate my plane in SITL?
I found a solution here. I actually had to load parameters for the plane first:
param load ../Tools/autotest/ArduPlane.parm
I had to do it once, and now they are loaded automatically.
Related
I'm doing barcode detection using zbar library with opencv in C++. The barcode detection is working good and I'm getting results like that
Now I want to use cv::solvePnP to get the pose of my camera (already calibrated). As 3D points I'm using a template in which, at program start, I compute the same barcode detection and I take the top left corner and bottom right corner. I then compute the world coordinates of these two points with respect to the center of the barcode in this way:
(pt.x - imageSize.width / 2) * px_to_mm,
(pt.y - imageSize.height / 2) * px_to_mm,
0.
imageSize is the size of the barcode (in pixels), px_to_mm is the ratio "length in meters of the barcode height divided by the total number of pixel of the barcode height" and pt is the point (either top left or bottom right).
The template is
I checked that the resulting point of the barcode detection are correct. The world coordinates are top_left =[0.054160003, 0.025360001, 0], bottom_right = [0.085200004, 0.046080004, 0]. I assume that these are correct since the dimensions in pixels of the barcode are 388 x 200 and the height in meters is 0.016.
When I run cv::solvePnP I get these results
translation: [-nan, -nan, -nan]
rotation: [-nan, nan, -nan;
-nan, -nan, nan;
nan, -nan, -nan]
The input of the method are the two image points of the barcode detection and the two world points computed using the template. What is the problem?
As api55 said in his comment the problem was the number of points. Adding the other 2 corners worked.
I have a problem that I'm strugling to solve for a few days.
I'm trying to make a bowling game using bullet physics, but the pin shakes, jiggles and moves to the side after I position it and it falls to the floor.
Here is a GIF of what happens:
http://imgur.com/7Mg41sf
Here is how I create a Pin:
btCollisionShape* shape = createShape(pinVertices);
btScalar bodyMass = 1.6f;
btVector3 bodyInertia(0,0,0);
shape->calculateLocalInertia(bodyMass, bodyInertia);
btRigidBody::btRigidBodyConstructionInfo bodyCI = btRigidBody::btRigidBodyConstructionInfo(bodyMass, nullptr, shape, bodyInertia);
bodyCI.m_restitution = 0.7;
bodyCI.m_friction = 0.9f;
_physicsBody = std::unique_ptr<btRigidBody>(new btRigidBody(bodyCI));
_physicsBody->setUserPointer(this);
And here is how I create a floor:
btCollisionShape* shape = createShape(laneVertices);
btScalar bodyMass = 0.0f;
btVector3 bodyInertia(0,0,0);
shape->calculateLocalInertia(bodyMass, bodyInertia);
btRigidBody::btRigidBodyConstructionInfo bodyCI = btRigidBody::btRigidBodyConstructionInfo(bodyMass, nullptr, shape, bodyInertia);
bodyCI.m_restitution = 0.6;
bodyCI.m_friction = 0.5;
_physicsBody = std::unique_ptr<btRigidBody>(new btRigidBody(bodyCI));
_physicsBody->setUserPointer(this);
Right now the floor is a btBoxShape and a pin is a btConvexHullShape, but I've tried using cylinder or cone and they also slide.
Been struggling for few days especially taking into account Bullet Physics website and forum are down.
Looks entirely reasonable to me. A rigid body isn't exactly going to bounce back up, nor is it going to shatter.
You have further issues with the imperfect approximation of reality. The bottom of your pin is probably flat, which means it theoretically hits the floor instantly over multiple points. Furthermore, due to the limited FP accuracy, the pin won't be exactly round, but then that part is realistic.
So the horizontal movements are probably because the small bit of freefall introduced a minor deviation from pure vertical fall. When hitting the ground this component wasn't cancelled, but the friction on moving did eventually bring the pin to a halt. Since the pin had only a small horizontal speed, the friction was not enough to topple the pin.
Perhaps you should set the restitution (bounce) of the pin and floor to something lower (try first with 0.0) This should solve it if the pin is bouncing.
Another thing you could try is to deactivate the pin after creating it. I don't know in Bullet, but in JBullet it's done like this:
body.setActivationState( CollisionObject.WANTS_DEACTIVATION );
This will stop your pin until some other object like the ball or other pin hits it.
I have an image (let's say it's a simple rectangle) positioned on the left of my screen, which I can move up and down. When moving it upwards, I use some simple trigonometry to rotate it so that the rectangle "points" towards the upper right corner of the screen. When moving downwards, it points towards the lower left corner of the screen.
Given that my application uses the following coordinate system:
I use the following code to achieve the rotation:
// moving upwards
rotation = -atan2(position.y , res.x - position.x));
// moving downwards
rotation = atan2(res.y - position.y , res.x - position.x));
where res is the reference point and position is the position (upper left corner) of our rectangle image. (For information on atan2(): atan2() on cplusplus.com).
This works just fine: it rotates more when farther away from the reference point (res). However, let's say the image is all the way at the bottom of the screen. If we move it upwards, it will very suddenly rotate. I would like to 'inbetween' this rotation, so that it is smoothened out.
What I mean by suddenly rotating is this:
Let's say the rectangle is not moving in frame n: therefore its rotation is 0 degrees. I then press the up arrow, which makes it calculate the angle. In frame n+1, the angle is 30 degrees (for example). This is ofcourse not very smooth.
Is my question clear? How do I go about this?
You can incrementally change the angle on each frame. For a very "smooth" rotation effect, you can use
target_angle = ...
current_angle += (target_angle - current_angle) * smoothing_factor
where smoothing_factor gives the rate at which current_angle should converge to target_angle. For example, a value of 1 would be instantaneous, a value of 0.1 would probably give a smooth effect.
By doing this you may encounter the wraparound issue whereby something like going from 10 degrees to 350 degrees would go the wrong way. In such a case, use
target_angle = ...
current_angle += diff(target_angle, current_angle) * smoothing_factor
where
diff(a, b) {
return atan2(sin(a - b), cos(a - b))
}
This nice angle difference formula is taken from another question.
I'm working on stackfile export to JSON for use in a VCS system and I've found some bizarre results from exporting/importing gradients. The dictionary says the following about the properties:
fillGradient["from"] - A coordinate specifying the starting point of
the gradient
fillGradient["to"] - A coordinate specifying the end point of the
gradient
fillGradient["via"] - A coordinate specifying the intermediate point
of the gradient (affects scaling and shearing of the gradient)
As you can see the coordinate system isn't specified. From some tests it appears the coordinates are relative to the card however this does not make sense to me as the value would change with every move. Does anyone have any further documentation on these properties and/or reasons the properties don't follow the markerPoints convention being relative to the object points where it clearly could do so.
Points locations are relative to the card as you found.
You might want to see this stack for reference: http://www.tactilemedia.com/site_files/downloads/gradient_explorer.rev
Actually, these gradient properties are relative to the topleft of the card.
This is the way that I was able to import Gradients from Adobe Ilustrator
version 7 into LiveCode.
You could check the code in this stack:
http://andregarzia.on-rev.com/alejandro/stacks/Eps_Import_V05C.zip
Some time ago when I also got irritated over the strange coordinate system I added the following behavior to my graphics:
setProp relFillGradient[pKind] pPoint
put round(item 1 of pPoint*the width of me + item 1 of the topLeft of me) into tX
put round(item 2 of pPoint*the height of me + item 2 of the topLeft of me) into tY
set the fillGradient[pKind] of me to tX,tY
end relFillGradient
getProp relFillGradient[pKind]
put the fillGradient[pKind] of me into tPoint
put (item 1 of tPoint - item 1 of the topleft of me)/the width of me into tRelX
put (item 2 of tPoint - item 2 of the topleft of me)/the height of me into tRelY
return (tRelX,tRelY)
end relFillGradient
Then to set the fillGradient you can do:
set the relFillGradient["from"] of graphic "myGraphic" to 0.1,0.3
Where the relative points is 0,0 for top left and 1,1 for bottom right.
NOTE: As you need to set the values to a rounded value you might not get the exact same value back from getProp.
If you don't want a percentage value (as I did) it gets even simpler as you can remove the multiplication and you get the benefit of not having to round your values.
I am using OpenGL to create the 3D space.
I have a spaceship which can fire lasers.
Up until now I have had it so that the lasers will simply to deeper into the Z-axis once fired.
But I am attempting to make a proper aiming system with crosshairs so that you can aim and shoot in any direction, but I have not been successfull in trying to update the laser's path.
I have a directional vector based off the lasers end tip and start tip, which is gotten from the aiming.
How should I update the laser's X,Y,Z values (or vectors) properly so that it looks natural?
I think I see.
Let's say you start with the aiming direction as a 3D vector, call it "aimDir". Then in your update loop add all 3 (x, y and z) to the projectile "position". (OK, at the speed of light you wouldn't actually see any movement, but I think I see what you're going for here).
void OnUpdate( float deltaT )
{
// "move" the laser in the aiming direction, scaled by the amount of time elapsed
// since our last update (you probably want another scale factor here to control
// how "fast" the laser appears to move)
Vector3 deltaLaser = deltaT * aimDir; // calc 3d offset for this frame
laserEndpoint += deltaLaser; // add it to the end of the laser
}
then in the render routine draw the laser from the firing point to the new endpoint:
void OnRender()
{
glBegin(GL_LINES);
glVertex3f( gunPos.x, gunPos.Y, gunPos.z );
glVertex3f( laserEndPoint.x, laserEndPoint.y, laserEndPoint.z );
glEnd();
}
I'm taking some liberties because I don't know if you're using glut, sdl or what. But I'm sure you have at least an update function and a render function.
Warning, just drawing a line from the gun to the end of the laser might be disappointing visually, but it will be a critical reference for adding better effects (particle systems, bloom filter, etc.). A quick improvement might be to make the front of the laser (line) a bright color and the back black. And/or make multiple lines like a machine gun. Feel free to experiment ;-)
Also, if the source of the laser is directly in front of the viewer you will just see a dot! So you may want to cheat a bit and fire from just below or to the right of the viewer and then have in fire slightly up or in. Especially if you have one one each side (wing?) that appear to converge as in conventional machine guns.
Hope that's helpful.