问:
Instantaneous velocity calculation from accelerometer?
I am trying derive velocity from accelerometer (MPU9250 in sensor-tag board). I saw lot of blogs which talk about noise and exact estimation problems. I started seeing velocity derivation (integration of accelerometer data over time) yielding me towards ramp because of noise presence in MPU9250.

Is the velocity can be estimated only by accelerometer or we need assistance of another sensor such as GPS or gyroscope, etc..

Please let me know as I see my velocity calculations never converge at all.
Also I have limitation in compute power, so Kalman filter kind of estimation techniques is difficult to implement. Can you please suggest whether I am in right direction or not.

答:
The only way to get a velocity from an accelerometer is to numerically integrate the output of the accelerometer. That is,

$$
v = v_0 + a*dT \\
$$

where $dT$ is the elapsed time between accelerometer readings. This means that you need to find the initial velocity $v_0$, and that an accelerometer cannot give an absolute velocity reading, only relative.

Further, all accelerometers have some sensor bias. If we call this term $a_{\mbox{bias}}$, then the accelerometer-based velocity "measurement" is actually:

$$
v = v_0 + (a + a_{\mbox{bias}})dT \\
$$

or

$$
v = v_0 + (a_{\mbox{bias}}*dT) + a*dT \\
$$

The bias term becomes a false speed reading. Further, the bias is prone to change over time, both with sensor age, orientation, temperature, etc. This means that it's not generally possible to (permanently) cancel that bias by simply measuring the accelerometer while it's known to be stationary, though this can be a technique you use to minimize the effect of the bias.

So, when you say the sensor is "noisy", that is technically true - there will always be some noise, but it is the fact that the noise is not zero-mean that introduces the trouble you're having. If the only issue were noise, then you could use filtering to remove it, but the fact that the bias exists means that no amount of filtering or averaging will ever give you the correct velocity.

The only way to get an absolute velocity is to incorporate an absolute velocity sensor. This could be done with GPS, a wheel speed sensor (assuming no tire slip), radar, etc. Generally you can combine (fuse) a sensor that is noisy in the short-term and accurate in the long-term (like GPS) with a sensor that is accurate short-term but drifts in the long-term, like an accelerometer, and get quality readings in both the short- and long-term.


问:
Is there an algorithm using the Kinect depth image (not the point cloud) for registration?
I know given the intrinsics fx, fy, cx, cy (where fx, fy are the horizontal and vertical focal length, and (cx, cy) is the location of principal point of the camera if pinhole camera model assumed) of an Kinect depth camera(or other range sensor?), a depth pixel px=(u, v, d) ((u, v) is the pixel coordinate, d is the depth value) can be converted to a 3D point p:

p=(x, y, z)
x=(u-cx)/fx*d
y=(v-cy)/fy*d
z=d

so that a depth image can be converted to a point cloud, and indeed, a depth Image represents a unique point cloud physically.

SLAM systems e.g. KinectFusion use such point clouds for ICP based registration to obtain camera pose at each time and then fuse new point cloud to the previously reconstructed model.

However, my mentor told me that depth Image cannot be inveribly converted to a point cloud since it's 2D->3D mapping with ambiguity (which I disagree), and he claims that I should use the depth Image at time (i-1) and (i) for registration, not the derived point cloud.

（If I have to obey my mentor's order) I've been reading papers and found one using Gradient Descent to solve camera pose (tx, ty, tz, qw, qx, qy, qz):

Prisacariu V A, Reid I D. PWP3D: Real-time segmentation and tracking
  of 3D objects[J]. International journal of computer vision, 2012,
  98(3): 335-354.

which uses RGB Images and a known model for pose estimation. However, I've NEVER found a paper (e.g., KinectFusion and other later RGB-D SLAM algorithms) deals with depth data just as plane image but not point cloud for registration. So could someone give me some hint (papers or opensource code) about:

How to do depth image registration without converting them to point clouds?

答:
Consider this - what is the process of doing SLAM? First, get some sensor data, then move in the world, get some more sensor data, then try to do feature identification and matching to build up a map.

You could, theoretically, still build a map in "depth" units instead of in meters or feet or whatever units your camera model spits out. After all, what is a coordinate frame but some arbitrary choice?

However, all the algorithms you read about do use the camera models to convert to Cartesian "world" coordinates because that's a "common language" that is "spoken" by most other sensors.

To that point, if you are going to attempt SLAM, maybe a wheel encoder would help determine how much distance has been traveled. BUT, if you (or your advisor) is insisting on using "native" depth units instead of converting those back to world coordinates via the camera transform, then that means that you instead need to convert your wheel encoder into depth units.

That is, you can either convert maps in depth units to Cartesian units, or you can convert every other sensor from Cartesian to depth units. GPS, magnetometers, wheel encoders, etc.

You could, of course, do SLAM without any external input, but then what? Well, then you get your entire map of the world and the localization of the sensor in terms of depth units. So what does it mean to be 1.5 depth units from a wall? Can you do anything useful with that?

In conclusion I would argue that, if you are insisting on not converting to proper world coordinates, then you are doing SLAM for the sole purpose of a SLAM exercise and not because you intend on doing anything useful, because the resulting map and localization doesn't have any external meaning.

ContentLicense: CC BY-SA 3.0


问:
Can too much input current destroy my motor driver?
I have a 18 V rated driver I'm using to drive two 12 V DC gear motors using my Arduino. I bought a new battery pack which is rated 3300 mAh 25C, 11.1V making the total current input 82.5 A. My driver is rated for 7 V min and 18 V max, no current rating is given.

My motors are 12V max current under load is 9.5 A.

So just to be sure, can using this battery destroy my motor driver?

This is the datasheet.

答:
If I might add to the previous answers: I noticed in the referenced datasheet that the 20A maximum current rating for this driver is limited to less than 10 seconds and the maximum current is further limited to 10A for less than 60 seconds. Maximum continuous current ( >60 sec.) is then given as 5A without heatsinks but with, I'm assuming, decent cooling airflow. I don't see any maximum current ratings with heatsinks but I would guess they would be somewhat better with sufficient cooling air.

Given that the maximum load draw of 9.5A is close to the maximum 10A/10 second rating and almost double the 5A continuous current rating and if in the application that these motors are used they draw that much current for any significant amount of time it could be possible that the controller would be overloaded.

So no, as previously pointed out, your battery will not damage your driver. But your motors, or more specifically your application, might burn up your driver, depending on actual use.


问:
Why wouldn't my robot stop?
I am working on an Arduino based robot which engages a braking mechanism detecting anything in front. I was using an ultrasonic sensor, to detect obstacles which worked well while the robot was on my table (i.e under construction). But when I ran it on the ground, it doesn't stops and crashes.

The robot is programmed as if anything is detected 50 cm ahead if the robot, the braking mechanism stops the wheels. But when testing, the robot just wouldn't stop.

My robot is running at an average 7.5m/s . Thinking that doppler's effect might have rendered my sensor useless, I tried a little IR sensor I had lying around (range 25 cm approx), but that didn't work as well.

What am I doing wrong here?

答:
If the speed of the robot is 7.5 m/s. then it is very difficult to implement a braking. And yes doppler effect is being rendered.IR sensor will work, but implement braking by not just stopping the motors.

Your is having high moment of inertia while moving at speed you mentioned So you can rotate motors in opposite directions.
but what you can do to solve the problem is you can calibrate the the robot

Firstly at low speed and check if the braking is applicable at low speeds or not.
And If not we can work on that.

Secondly if the braking is working fine at low speeds say 50 cm/s. Then you can slowly increase the speed of the robot.
Now, you can decrease the speed of bot via PWM in motors.

Title: Why wouldn't my robot stop?


答:
The Datasheet which you gave on the very first page the current rating of the motor is given that is 20A.

It does not mean that you can run 20A all the time

Secondly There will be no problem of current unless there is high load on the motors.
I like to tell somethings about battery.
What I am trying to say is that when you use a battery of 3300 mAh it means that if you can draw 3300 mA current from that battery this battery will last for an hour. Similarly if you drawing 1650 mA current it will last for 2 hours.

Now about motors drivers, motor drivers may fail due to battery for two reasons

1- When you apply more voltage to motor driver than it mend to withhold.( Which in your case you are aware of and it is not a problem).

2- When you run a motor through driver and the load of the motor has exceeded and is drawing more current. For example when you try to stop a running motor manually then motor will try to draw more current. Now if it happens your motor driver will not blow instantaneously but it will take some time. That is mentioned in the second image.

Title: Can too much input current destroy my motor driver?

Body:
I have a 18 V rated driver I'm using to drive two 12 V DC gear motors using my Arduino. I bought a new battery pack which is rated 3300 mAh 25C, 11.1V making the total current input 82.5 A. My driver is rated for 7 V min and 18 V max, no current rating is given.

My motors are 12V max current under load is 9.5 A.

So just to be sure, can using this battery destroy my motor driver?

This is the datasheet.


答:
7.5m/s is pretty fast for a robot, but still not that much compared to speed of sound (approx. 330m/s), so Doppler effect may introduce some error to measurments, but not critical. The point is that if you set detection distance to only 50cm, your robot has only some 66ms to:

perform the measurment

communicate with the sensor, or make a AD conversion

run the algorithm

send a command to motor driver

stop motors and decelarate

Even if it starts braking immidately, its inertia may be to big to decelerate completely before cruching into the obstacle. Would a car driving 7.5m/s (27km/h) stop in a distance o 0,5m?

Suggested soultions:

Try increasing a detection distance

Try using a IR sensor with a digital interface - they measurment times are much lower than in US sensors

If you have to brake really quickly, think of using additional mechanical brakes

Title: Why wouldn't my robot stop?

Body:
I am working on an Arduino based robot which engages a braking mechanism detecting anything in front. I was using an ultrasonic sensor, to detect obstacles which worked well while the robot was on my table (i.e under construction). But when I ran it on the ground, it doesn't stops and crashes.

The robot is programmed as if anything is detected 50 cm ahead if the robot, the braking mechanism stops the wheels. But when testing, the robot just wouldn't stop.

My robot is running at an average 7.5m/s . Thinking that doppler's effect might have rendered my sensor useless, I tried a little IR sensor I had lying around (range 25 cm approx), but that didn't work as well.

What am I doing wrong here?