14

Features like the sun and clouds and other things that are very far off would have a distance estimate of inf. This can cause a lot of problems. To get around it, the inverse of the distance is estimated. All of the infs become zeros which tend to cause fewer problems.


12

Deduced reckoning is figuring out where you are after starting from a known position, by using your speed, direction and time. (It's effectively integration of velocity, if you want the calculus/mathematical version). At sea you would know your direction from a compass, speed by any one of various means, and important complications like the wind speed and ...


10

The inverse depth parameterisation represents a landmark's distance, d, from the camera exactly as it says, as proportional to 1/d within the estimation algorithm. The rational behind the approach is that, filtering approaches such as the extended Kalman filter (EKF) make an assumption that the error associated with features is Gaussian. In a visual ...


8

Monocular vision is a difficult and very interesting, particularly in its application to the general navigation problem. I will make an attempt at answering your questions, but if you find anything lacking, you can read through Szeliski's book Computer Vision: Algorithms and Applications. What is the core principle of a monocular visual odometry algorithm? ...


5

Dead-reckoning systems are based on estimating position relative to sensors. These sensors can be accelerometers, gyroscopes, whell encoders, infrared sensors, cameras etc. which have to placed on body of robot. So we can calculate displacement or coordinates. Odometry is a sub topic of dead-reckoning and based on wheel displacement calculations.


5

I did a little step-by-step tutorial with images, but if my other answer regarding aligning frames didn't work well for you, or the definition of "Front Plane" or "Top Plane" is confusing in Solidworks (spoiler: it is), then consider making your own axes. From the assembly tab, go to reference geometry -> axis, then select the assembly planes to make an ...


4

Of course adding random particles will change the pose of the robot. That's the point: To add randomness to account for errors you can't compute yourself. You should add random particles every time the state of the robot may change, then adjust the weight of the particles based on which seem likely given sensor data. This is a very basic definition of ...


4

Dead reckoning is determining pose (position and rotation) using speed estimates from sensors. For example, you know your initial position and use sensors such as encoder, accelerometers, gyros, etc... to estimate your current position by integrating sensor measurements. Odometer is determining the pose using only the rotation of the wheels of a robot. ...


4

It is also often the case that the author lacks knowledge, makes mistakes, or is adding unnecessary statements to their work. Just because it is published does not make it true. In this case though, it might be that the conjuction "and" and commas are confusing you. such as object recognition and pose estimation, visual odometry, and SLAM could ...


3

Part 1. Use one or the other. Often odometery is used instead of kinematics or dynamics for prediction, at least in my work. Part 2. This is handled by the construction of the measurement equation jacobian. Every time a measurement comes in, construct a Jacobian for the whole state. You'll notice that some of the state elements are independent of the ...


3

It looks like most of your parts have no rotation, but some of them do, so I'm going to guess that you didn't mate your assembly to the origin planes in Solidworks. First, on your base plate, open the Solidworks part file and check that the origin planes run through what you want the origin of the part to be. If they don't and it's a pain to re-draw the ...


3

I would add a few lines after you check that theta is between +/- 2pi: meanDistance = (SL + SR)/2; posX = posX + meanDistance*cos (theta); posY = posY + meanDistance*sin(theta); This of course assumes theta is positive CCW starting from the +x-axis. This is similar but not the same as your code for X and Y, but your code appears to put the X origin on the ...


3

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{...


3

Davison's paper introducing the method is easy enough to understand: Inverse Depth Parametrization for Monocular SLAM by Javier Civera, Andrew J. Davison, and J. M. Martınez Montiel DOI: 10.1109/TRO.2008.2003276


3

http://vision.in.tum.de/data/datasets/rgbd-dataset This is a set of recordings for the Kinect and Asus Xtion pro, which are all indoors (in offices and a hangar). It comes with precise ground truth from a motion capturing system. The data is available as ROS bag files, but also as a tarball with png images with a text file for the trajectory. There are ...


3

This is another more recent one, based on the paper A Photometrically Calibrated Benchmark For Monocular Visual Odometry by Engel et al: http://vision.in.tum.de/data/datasets/mono-dataset This gives both indoor and outdoor scenes, with calibration (or the corresponding sequences so you can calibrate yourself). I haven't tested it fully myself but it seems ...


3

A few things: I took a look at your data set. Did you make sure you used the time column correctly? The first entry is "1429481388546050050" without the decimal. To make it in seconds, it should be 1429481388.546050050. Your motion model is fine (I've used it before, for people who want to see it derived, it is very similar to this one). However, to avoid ...


3

Pose estimation means determining position and orientation. Odometry is using a (any) sensor to determine how much distance has been traversed, so visual odometry is just clarification that the particular sensor to be used for odometry is visual (a camera, typically). Traversed distance, though, means that odometry is relative - your car odometer may ...


3

You could maybe use Matlab to plot the position of your vehicle? This is how I'm trying to do that: I have a 'logging'-program running on the Raspberry Pi that counts each sampling time the pulses from the encoders. This I log in a file. This file I upload in Matlab to calculate X and Y coordinate and the angle under which the vehicle is standing, assuming ...


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 ...


3

So SVO works a bit differently then other VO systems as it uses dense image alignment. You need to understand this concept first before understanding SVO. Look up Lucas and Kanade image alignment. The best paper on this topic can be found here. This is required understanding, so you can't skip it. Required Understanding: Lucas and Kanade(LK) How Sparse VO ...


2

In regards to your question about differential drive, it sounds as though your robot is using the kinematic model to estimate the position, but this is being done "internally" (i.e., in the embedded on-board software). Whether or not this is okay depends on whether the wheel radii and track width (distance between left and right wheels) it uses are correct. ...


2

Well, you can't estimate the covariance from the state. You need the equations used to find the state. This is because the covariance (along with the markov assumption) represents how the robot got to the state. A robot at location (10,5,1) does not always have the same covariance matrix, right? You need to know what actions brought it to that state. ...


2

I found a monocular dataset captured from a Micro Aerial Vehicle (MAV), and it has been been made available here: http://projects.asl.ethz.ch/sfly/org/doku.php?id=mav%20datasets In case the url stops worksing in the future, I am adding the name of the publication that came along with this dataset: "A Benchmarking Tool for MAV Visual Pose Estimation" Int. ...


2

Have a look at KITTI Visual Odometry Benchmark/Evaluation. Its a recent and nice evaluation of different stereo visual odometry algorithms on some large outdoor urban scenes. They compare it against ground truth (GPS). I would say Visual Odometry are quite accurate and elegant perception systems. And its much better option than the IMU/GPS alone (even the ...


2

So you need to find the rotation that gets you from the first coordinate system to the second, and then combine that with the translation to get the final transformation matrix. Since you have quaternions q1 and q2, you can write this rotation as: $q = q_2 * q_1^{-1}$ You can then convert from the quaternion form to a rotation matrix to make the final ...


2

Great question! Your intuition is correct. I would do this: Put the state $x$, and expected velocities at the current time $t$, $v $ as the vector to estimate. Use estimated velocities to predict next state $$\hat{x}(t+1)=f(x(t),v(t))$$ Use odometry measurements from $t$ to $t+1$ to form an estimate of the state. The difference between this and $x$ is ...


2

First, you can try adding encoders - you don't need to buy anything to do this. Only remember to perform UMBmark procedure first. It will allow you to get much more reliable odometry from encoders alone. If adding encoders is not enough, try to add magnetometer. It will get you absolute heading relative to magnetic north. Unfortunately, these devices are ...


2

You're robot must be moving pretty fast for this delay to cause problems. Use a circular buffer to store the odometry readings, so you'll have a record of the last 100ms of odometry readings. Use the IMU and odom combined at time $T_{-100ms}$ to estimate your last known 'accurate' state. Integrate the odom forward from $T_{-100ms}$ to $T_{0}$ to get your ...


2

I've performed 2D localization with just odometry and a gyroscope before, and to be honest, depending on (i) how good your encoders are; (ii) what type of environment you're in (is there a chance your wheels will slip a lot); (iii) how good your IMU is, there's a good chance that you don't lose much by just using odometry for translation, and only ...


Only top voted, non community-wiki answers of a minimum length are eligible