10
The barometer carried on the pixhawk has an altitude resolution of 10 cm. If that isn't enough, you could write a kalman filter that uses the accelerometer data in the prediction step and the ultrasonic sensor and/or the barometer in the correction step.
But I don't see this solving your problem. An accurate measurement of altitude at 20hz should be plenty ...
7
They are exactly the same. Information matricies (aka precision matricies) are the inverse of covariance matricies. Follow this. The covariance update $$P_{+} = (I-KH)P$$ can be expanded by the definition of $K$ to be
$$ P_{+} = P - KHP $$
$$ P_{+} = P - PH^T (HPH^T+R)^{-1} HP $$
Now apply the matrix inversion lemma, and we have:
$$ P_{+} = P - PH^T (HPH^...
6
Localization under water was always a problem in ocean robotics as electromagnetic signals do not propagate very well in water. I think your best localization sensor in that case would be the good old sonar, which works much faster in water. You could have four of them and detect how far are the pool walls on each side then with a triangulation algorithm ...
6
Yes. The px4 software for the pixhawk autopilot has an extended kalman filter that uses an accelerometer, a gyroscope, gps, and mag.
A paper describing the a smaller ekf which only estimates attitude can be found on archive.org and code for the full ekf can be found on github with further information on archive.org.
5
How to estimate a robot's position depends on how well you'd like to estimate it. If you just need a rough guess, try odometry, it works OK. For better results, you have to incorporate more sensors. That's an incremental process that involves a lot of sensor fusion, and suddenly, you've built an Extended Kalman Filter.
The best way, in my opinion, is to use ...
5
The gyrometer gives you angular velocity about each axis. You simply integrate these values to get the roll, pitch and yaw of the robot. Since this is 2D, all you care about is yaw, and you'll integrate one value. Of course, there are many different ways of integrating the value you read from the gyrometer. The easiest way is to sample the gyro, timestamp ...
5
Generally, for indoor flight, commercial quadcopters do not measure position. Instead, they measure the change in position so as to prevent the quadrotor from moving when it should not. So while accelerometers are not great for maintaining an estimate of the quadrotors position they can be used to stabilize the system, i.e. to determine what commands needed ...
4
This is called "data association" in tracking literature. When you measure the position of an object, you need to know which object it was you measured. If you can estimate this probability, then you are free to choose the most likely association. This is a heavily researched topic, but boils down to Bayesian analysis.
Here's a simple way:
Assume we have ...
4
What you are describing is essentially a textbook case for using a Kalman filter. First you need a prediction step. Let's assume you are predicting the pose of the robot $(x,y,\theta)$, given the previous pose estimate and your high-frequency velocity measurements $(v,\omega)$, where $v$ is the linear velocity and $\omega$ is the angular velocity.
$P$ is ...
4
I am not allowed to comment, so I have to add a reply. By position, do you mean the location in space (so X, Y coordinates), or orientation (tilt, etc)?
If position, you can use the accelerometer values and integrate acceleration to get distance traveled, though this is fairly inaccurate. We have tried to do this for a quadcopter, and the drift due to error ...
4
If it's actually underwater, how about a webcam looking at the tile pattern on the floor? (Could be considered "cheating" as it will obviously fail in a natural lake, for example.)
You can find a paper using and demonstrating this method is this paper:
Carreras, Marc, et al. "Vision-based localization of an underwater robot in a structured environment." ...
4
One of the prime sensors for global localisation on land is GPS. This is not an option underwater because electromagnetic waves get absorbed quickly.
There are however alternatives, which provide navigation information which is not so easily available on land.
Large Baseline (LBL) - is a method based on sonar, which works very similar to GPS, just using ...
3
If you cannot use a camera the task is nearly impossible with your money limitations.
Professionals use a scanning sonar like the tritech micron and a particle based localization like [3] based on FastSLAM: [1].
However if you experienced with underwater acoustics you can try to build your own localization system based on the idea of a USBL idea [2] e but ...
3
There is an error in your posted equation for the Jacobian $F_J$, so that could be the source of the problem. It should look like this:
$F_J = \begin{bmatrix}
1 & 0 & -C \sin \theta \\
C \frac{\sin \theta \sin \lambda}{\cos^2 \lambda} & 1 & C \frac{\cos \theta}{\cos \lambda} \\
0 & 0 & 1 \\
\end{bmatrix}$
With that new Jacobian I ...
3
Is ... GPS data ... fused with the accelerometer data?
Yes, many aircraft use sensor-fusion techniques so both GPS data and accelerometer data effect the estimated X, Y, Z position.
Often they use a Kalman filter to do the data fusion.
( kalman-filter; Why do I need a Kalman filter? )
Measuring X,Y,Z accurately for each photo is important for assembling ...
3
The Hungarian Algorithm should be suitable for this case. You have already generated the cost matrix that describes the cost of each measurement to each object. The algorithm determines the assignments that yield the minimum total cost. It can handle cases with more measurements that objects (false positives) and more objects than measurements (when an ...
3
Using an IMU you can only measure: acceleration, rate of rotation, and direction of magnetic field. You cannot measure velocity, you can only integrate the acceleration to infer velocity. As you can imagine, this leads to velocity drift, which in turn leads to a lot of unbounded position drift.
There are three parts to your problem:
Infer the robot's ...
3
Basically it does not matter.
But you have to be carefull if the plate is rotating fast, because the rotation of the plate around its center point, with the IMU placed out of center, will cause the accelerometer to measure centrifugal forces.
If your task is to stabalize the platform, this won't be an issue for you.
3
I think your diagram is missing an angle for the laser angle with respect to the vehicle body -- I'm going to call that angle $\alpha$, see this diagram for clarity:
Since it seems you are tracking an object with your laser, I imagine the point of this is to predict the angular velocity of that object in the vehicle frame. So your laser is scanning in 2D, ...
3
ROS has a package called robot_localization that can be used to fuse IMU and GPS data. This package implements Extended and Unscented Kalman filter algorithms.
The package can be found here.
3
So, as I mentioned in an earlier comment, it looks like you're using a mashup of methods. You're not applying any one method correctly; instead you're mis-using part of one method, then using the results of that to another mis-applied half-method, and so on.
First, maybe a refresher on rotation matrices. You can rotate about each of the three primary axes - ...
3
Adding to the above, my favorite way to debug a misbehaving filter is to isolate each step.
Make sure your prediction step works before correcting it. Your bot should drive straight right with 0,0,0 as a starting state and constant vel. Otherwise, your measurements are correcting your model, not sensor noise
Remove the measurement step and feed residuals by ...
2
The most straightforward approach is to use a Kalman filter with a memory of recent state history. While waiting for measurements you do the standard time update. When a new measurement arrives, you restore the state and error covariance to the appropriate point in time, apply the measurement update, and then apply time updates to get to the current point in ...
2
So you have acceleration readings from your IMU (linear and angular), and you get velocity readings (linear only) from wheel encoders.
Get velocity from linear and angular accelerations with
$$
v = v + a*\mbox{dT}
$$
Get angular velocity from your wheel encoders by exploiting geometry of the vehicle
$$
\dot{\theta} = \mbox{atan2}((v_r - v_l) , \mbox{...
2
There are many GPS+INS fusion units available on the market. The price, weight and size of the units can vary dramatically depending on the GPS positioning accuracy and rate of drift from the INS. The choice of GPS+INS sensor really depends on the requirements of your application.
From my own experience, Xsens (https://www.xsens.com) make lightweight ...
2
Kalmnan filters are typically used for sensor fusion. You create a model for what you expect the process to look like, use your sensors as inputs, and the output is the filtered estimate. I'm not going to go over implementation in detail as there is plenty of information about these filters available online; I hope this points you in the right direction and ...
2
I was in exactly the same boat with my master's thesis; wave-based imaging (sonar and radar) seemed so common that all the papers I read assumed you knew the fundamental concept and they were going to show an advanced technique, or they set out deriving everything from Maxwell's equations! That said, I hope this helps.
Essentially, you have two ...
2
The quaternion only contains information about the rotation of the vehicle. It will not contain information about the location of you vehicle on a 2-d plane.
One method of converting quaternions to euler angles is to create the transformation matrix that is defined by the rotation and get the euler angles from that.
https://en.wikipedia.org/wiki/...
2
You should first validate your filter is working before second-guessing your modelling choices. But I agree both those filters look OK (although I did not double check all the maths) and both of your suggested changes should also work.
There's a process I used to find errors in KF's, which is in no way comprehensive:
Plot the measurement residuals at ...
2
my roll and pitch drifts are corrected with accelerometer inside IMU
You mean they're being correct by the IMU, or you're correcting the readings yourself using the accelerometer from the IMU?
i want the formulation to simply compensate my yaw angles from this H value.
If you're correcting the other angles yourself, just use the same method to correct ...
Only top voted, non community-wiki answers of a minimum length are eligible
