问:
Direct vs semi-direct methods for visual inertial odometry
I was reading these papers on visual inertial odometry from IROS 15:

Semi-Direct EKF-based Monocular Visual-Inertial Odometry

Robust Visual Inertial Odometry Using a Direct EKF-Based Approach

I would appreciate if someone could explain how semi-direct and direct methods vary exactly? As far as I understand, direct methods use pixel intensities in their framework. However, both these papers listed above use photometric intensities/pixel intensity values and yet one is semi direct and the other's direct.

答:
The answer to your question is explained clearly and well classified in the introduction of this paper Direct Sparse Odometry.

Also, I would recommend you to read another representative semi direct method SVO: Fast Semi-Direct Monocular Visual Odometry" (although the author of the first paper denies that it is a true semi direct method). The author's PhD dissertation describes his work in detail.


问:
Object Detection and Pose Estimaion
I am working on a robotics project for fun and can't really wrap my head around a solution to my perception problem.

Setup:
My robot will have a stereo vision setup and will have to detect certain objects and align itself to those objects in a certain pose.  The robot will know what the width and height of those objects are.  The robot will be using a tx1 for computation, so implementation needs to be pretty fast.  Also, the environment's lightning will change a lot so using color for detection isn't a great option.

My plan: To use convolutional neural networks to detect those objects of interest.  I have been able to program a network to detect those objects in 2D however, I am stuck on how to detect the pose of the objects in 3D.  My idea has been to detect the object with the neural network and once I have that region of interest, get the point cloud.  Then fit a 3D model using ICP.  Once the 3D model is fit I can get the pose of the object.

I have also seen people using 3D correspondence grouping for this but would that work on a non dense point cloud that stereo vision generates?

I am pretty novice in this area and would love to get advice on from some more advanced robotics practitioners.

Thanks for you time!

答:
There are a few things that will make ICP hard to work with here:

ICP is very sensitive to the initialization it is given and is very likely to converge to a poor solution if it is given a bad starting point. Your point cloud will probably not give you a good initial guess for the orientation of the object.

It can be thrown off by points in your point cloud that are not part of the object. There are versions of ICP that try to be more robust to this, but it's hard to do well. i.e., your CNN detections will probably just provide a bounding box detection of the object, but the object will not entirely fill that box. The point cloud you extract will therefore contain points that are not part of the object, which could pull the translation estimate from ICP pretty far off too. You will probably need to do some kind of 3D segmentation to try to isolate points on the object, which will be tricky to tune to work in all the cases you encounter.

It can also be pretty expensive...

I'd recommend starting with something like RANSAC on interest points on the object. You can compute a set of distinctive points (e.g., corner detections or other SIFT-like features) on your object model and on your image within the bounding box provided by your CNN's 2D detections. The success of this approach will depend largely on whether your objects have good, distinctive features to detect. Then you can estimate 3D locations for each of these points from disparities in the neighborhood. Applying RANSAC to these 3D points should give pretty accurate and robust 3D pose estimates. After that, you could try using ICP to refine them if needed.

ContentLicense: CC BY-SA 3.0

Title: Object Detection and Pose Estimaion


问:
loop closure detection in visual SLAM
A robotic system is moving a getting its current location using visual odometry (incremental estimation of rotation and translation). To correct its localization, a loop closure technique may be added. However, this technique based on image comparison is costly. I want to find a way to only use this technique of loop closure only when a potential loop closure is present.
Is there a way to use the $x$ and $y$ coordinates of the vehicle provided by visual odometry to say that based on their values a loop closure may have occured?</p>

答: Well, there is an old solution that finds a possible loop closure by a growing uncertainty of the current location which was popular in EKF based SLAMs. In such way, you can reduce the number of the candidates for the place recognition. But I guess trajectory only is probably not enough for a loop closure unless you assume a special situation.   </p>

Title: loop closure detection in visual SLAM


问:
Methods for odometry/IMU/Gyro free lidar pointcloud registration for pose estimation
I am currently trying to register a pointcloud in time to find my change in position and heading at each timestep (High speed application). So this is essentially an implementation of SLAM. I am currently using ICP with an SVD rotation solver to try to find rotation and translation. This solution works with simulated pointclouds.

The issue is that reobservation of previous points is non-deterministic for the type of scanner I am using. So this makes neighbor matching between frames difficult.

Is there any prepossessing I can do to get better matches in the neighbor finding step? or are there other methods for pointcloud registration that are more robust to noise than SVD based ICP?

答:
I'm not sure what sort of ICP did you used but a voxel based plane-to-point ICP is robust and works well even in an unstructured environment.

This or his previous paper describes the method.
http://ieeexplore.ieee.org/document/6220900/

Or this one might be helpful.
http://static.adrian-haarbach.de/mscthesis_adrian.pdf


问:
How to finely control a gear motor with encoder using Arduino/RPi?
I'm having trouble with getting this motor to work and could use some help/guidance, please.  I have a micro gear motor with encoder which I got from ServoCity (https://www.servocity.com/90-rpm-micro-gear-motor-w-encoder) and am trying to use it for a project which will require some fairly accurate movement.  I used a servo before, but it was too loud and too inaccurate for my needs, and burned out after a couple of years.

I haven't yet gotten to the encoder part of the my control (although I intend to use that to mark "top center", eventually) - so right now I'm using an Arduino and a voltage step-up board.  I can make the motor turn by setting the Enable pin on the step-up board to high - however I'm unable to fine-tune the control.  It seems to do a full-spin and stop, no matter how briefly I make the pin high.  Attempting to do this with PWM doesn't seem to help or produce anything.

In my research I haven't found any code specific to this motor, so I don't know if this is a complete limitation of this motor, or if I'm doing something wrong in my approach.

Any help/code/advice you could give would be much appreciated.

Thanks!

答:
Edit: please provide information on your step-up board. What you need is an H-bridge driver such as L293DNE, TB6612FNG, DRV8833, ...

This is a regular DC motor, the 6 pins of the connector are shown on the website you linked:

With Arduino, you should connect the Hall Sensor (the encoder) pins to supplies (GND, +5V) and to two interrupt pins (A, B). See the official attachInterrupt() function reference here because this depends on which Arduino you are using. Make sure you set the interrupts to trigger on change and not only on rising or falling signals.

The software processing consists of a) detecting rotation direction, and b) detecting rotation speed, which can be done by b1) counting pulses or b2) timing pulses.

a) to detect the rotation direction, one way to do it is to compare if the A and B signals are the same (HIGH/LOW) or different using digitalRead(...) on interrupt.

b1) detecting speed by counting pulses is then done by incrementing or decrementing a counter variable depending on direction (needs to be global, volatile). Calculating speed in the loop() is done by dividing the number of pulses by the time and multiplying it by a factor that takes into account the encoder cpr, gear ration, and scales this to preferred units (rad/s, rpm, ...).

b2) if your encoder does not have a lot of counts per revolution (cpr), you should consider timing the changes using micros() or using timer1 and timer3 capture modes (more difficult to set up, search for "arduino input capture"). It helps a lot with these encoders to do it as follows: for each change (interrupt), time the whole period of the encoder signal meaning that you need to remember the time stamps of the previous 3 changes. This reduces the variance in the measurement, because you cannot be sure that the encoder A and B signals are 50% of the time up and 50% down, and a quarter of the period apart (check them on an oscilloscope, they are not perfect!). The speed is in this case calculated by dividing a constant by the encoder signal period. The constant again depends on your counts per revolution, gear ratio, and preferred units.

When you have the speed information from the encoders, use e.g. PID control to make sure that the motor rotates at the desired speed.


问:
Using brushless motors for very high torque
I'm currently building an robotic arm and I want the elbow joint to be comparable to a human one
But here's the problem, electric linear actuators are too slow and have low torque, same goes with regular hobby servos and stepper motors

Ideally I would want a brushless motor with no gearbox that could hold a 10kg weight at an arm's distance (let's say 40 cm) and move freely at around 100rpm (about 10rad/s)

Holding force: 40 N.m

No load moving velocity: 100rpm / 10 rad/s

I was thinking sensored brushless motors could do the trick but surely that load would be too much for those...

If this cannot be achieved, would it be possible to use a 3D printed 100:1 planetary gearbox and a low kv motor to do it?

Thanks in advance, if you have other types of motors that would be more suitable please comment them, any help is appreciated.

答:
Your expectations are rather aggressive for a DC motor.

First - 40Nm (350in-lbs) is A LOT of torque!  Ex: A max rated torque for 1/4-20 bolt is only 75 in-lb (8.5Nm).

Second - The mechanical power of a motor results from RPM*Torque.  40Nm*100rpm is 0.56hp (420W at 100% efficiency).  That is A LOT, about 1/2 of what today's high end cordless drills can do.  Fortunately it looks like you aren't expecting high torque at the high RPM so actual power will be lower; but, those numbers are likely to affect your motor size (unless you are going to use a transmission).  You will probably need to start thinking about a torque curve.

Regarding DC motors: They rely on higher RPM to deliver higher power rather than higher Torque.  This has to do with the physics of the motor.  High Torque with a DC motor is going to require some sort of a "mechanical advantage".

Here are some design options to consider.

(Metal) Gears/Gearbox.  Planetary gearbox could do.  Plastic gears (at least for the load end) are likely going to fail at high torque.  They simply can't handle the sheer.  You can get some that are pretty small.  Here is gear motor from Motion Dynamics that can to 40Nm.  Here is one from Midwest Motion that can also do 40Nm (Note: Both use Planetary gearboxes and are pretty slow and no where close to the power you are looking for).

A slight variation of the gearbox (but work mentioning separately) is a worm gear/drive.  This can get you a lot of mechanical advantage; but, it will turn the axis or rotation by 90deg.

Use a cord-and-spindle and pulleys if needed to gain additional mechanical advantage (this does great for pulling; but, you are going to need a spring for return).  Think garage door opener (sort of).  Also think human arm (muscles only pull).  Other linear-motion leverage options are leadscrews and rack-and-pinion gears.

Hydraulics (as mentioned).  This is how car brakes, clutches, and power steering do it.  It allows you to move the motor off the arm.  This is pretty common for large walking robots like Boston Dynamics Atlas.

Note: AC motors are more efficient than DC motors if you don't need positional control.  That is likely why Tesla uses them in their cars.


问:
How to increase the traction of tyres/wheels
I’ve developed a basic robot that navigates around my son’s Duplo train track.  It works find on the flat parts, but once it reached an incline at the start of a bridge, the wheels just spin and the robot stays at the bottom of the incline.

I’ve 3D printed most of the parts using PLA for everything, but printed tyres using TPU.  The tyres definitely help, as the wheels were originally spinning even on the flat.  Moving the batteries (2xAA) to sit over the drive axle also helped.

What else can I do to increase the traction and give my robot a chance of making it up the hill?

答:
Quickest solution is to just roughen the surface of the track using sand paper.

But if you are talking about a modification to the robot itself, you can use different type of material for the tyre.  PU has many grades.


问:
Single power source for electronics and actuators
It seems popular to build robotic systems with separate supplies for the electronics and motors/servos, but what would be involved in a circuit that powers both from one source?

If it helps, here is my particular situation. I want to use a single 7.4V Li-Po pack to power an embedded system (2.5-6V operating voltage input, max 1A current draw) and up to 18 standard-sized servos (HS-645, 4.8-6V operating voltage). This would be a hexapod, so it is unlikely that all servos would be stalling at once with normal gait patterns.

答:
There are a variety of reasons to separate the motor power from the "hotel load", including:

Reducing the number of wires running between high-power and low-power electronics

Redundancy (your homing beacon shouldn't run out of power when the rest of the system does)

Preventing heavy current loads from browning out the control system

Making the system more modular

Being able to have an emergency kill switch for the actuator power that won't hard-shutdown your onboard PC (risking data loss in the filesystem).

However, there's nothing fancy about doing it all from one battery: use a DC-DC converter to get the voltage you need for your electronics, and watch out for ground faults.


问:
Confusion about Jacobians stemming from class notes
So I thought I understood well enough what a Jacobian was (in the context of an $n$-DOF robot) -- a function that takes a vector of n joint positions and returns an $n \times n$ matrix that can be multiplied with a vector of $n$ joint velocities to return a velocity vector for the end effector.

I'm using ROS and MoveIt, so I actually already have a function to calculate the Jacobian for my robot from the URDF.

However, I'm reading lecture notes from the 2005 MIT Intro to Robotics course, and in one (mission-critical, it seems) portion of chapter 7 (between pages 11 and 12), he refers to "$3 \times n$ Jacobian matrices relating the centroid linear velocity and the angular velocity of the $i^\text{th}$ link to joint" as $J^L$ and $J^A$.

He introduces Jacobians in Chapter 5, and indeed I looked through all the rest of the course material, and I don't think he ever explains what these matrices are or how to compute them.

Could someone enlighten me as to what he's talking about?

答:
Short answer

Robot Dynamics and Control by Spong et al. (especially Chapter 5) can definitely help you on this matter.

Long answer

First of all, you are partially correct about a Jacobian. It is indeed a function of joint values (say $q \in \mathbf{R}^n$). However, as a Jacobian maps a joint velocity to an end-effector velocity, its dimension is not generally $n \times n$, but rather $m \times n$, where $n$ is the number of DOFs your robot has and $m$ is the dimension of the velocity vector you want to map a joint velocity vector to.

Let's consider the following equation
$$\dot{x} = J(q)\dot{q},$$
where $\dot{x}$ is an end-effector velocity vector. The vector $\dot{x}$ is generally a 6-vector that is (generally) a vertical stack of linear and angular velocity, i.e.
$$\dot{x} = \begin{bmatrix}v\\ \omega\end{bmatrix}.$$

Looking closely, one can see that the first three rows of $J(q)$ are mapping the joint values $q$ to the linear end-effector velocity $v \in \mathbf{R}^{3}$. Similarly, the last three rows are mapping $\dot{q}$ to the angular end-effector velocity $\omega \in \mathbf{R}^{3}$. Therefore, one can actually writes
$$J = \begin{bmatrix}J^L\\J^A\end{bmatrix},$$
where $J^L$ and $J^A$ are such that $v = J^L \dot{q}$ and $\omega = J^A \dot{q}.$ Computing $J^L$ and $J^A$ can then be done accordingly by analyzing the relationship between the joint velocity and the end-effector velocity.

For detailed analysis (and also how $J^L$ and $J^A$ can be computed), you can consult Spong's book I mentioned above.


答:
Two seemingly contradictory approaches come to mind.  One is to increase the friction between the wheels and the track.  You can do this by coating the tires with a soft material, such as a gasket or brush-on rubber compound.  This approach also benefits if you can increase the surface area of the tire that touches the track.  Increasing the radius of the tires can help with this, as can widening them up to the width of the track.  Adding weight to the robot will also linearly increase the force of friction between the tires and the track.

A second approach is to attempt to get positive engagement between the tire and the track instead of relying on friction.  This would work if you can add teeth to your track and corresponding teeth to the wheels.  The downside of this approach is that the tires will not roll as smoothly on flat tracks.

Title: How to increase the traction of tyres/wheels

Body:
I’ve developed a basic robot that navigates around my son’s Duplo train track.  It works find on the flat parts, but once it reached an incline at the start of a bridge, the wheels just spin and the robot stays at the bottom of the incline.

I’ve 3D printed most of the parts using PLA for everything, but printed tyres using TPU.  The tyres definitely help, as the wheels were originally spinning even on the flat.  Moving the batteries (2xAA) to sit over the drive axle also helped.

What else can I do to increase the traction and give my robot a chance of making it up the hill?


问:
Laser Scanner for localization in particle filter
I'm working on a particle filter implementation in Matlab and I found one very good in the Robotics Toolbox (available here https://github.com/petercorke/robotics-toolbox-matlab). My problem is that I really don't know how to modify it in order to use it with a Laser scanner, I know that with a know map the laser beam will give the distance and angle (kind o like RangeAndBearing) but I haven't understood well how the likelihood field of the map fits into this.

In the end my question is how can I get the RangeAndBearing Measurement from a Laser scanner in order to use it in the particle filter?

Thanks in advance

答:
The RangeBearing "sensor" is used to "find" landmarks given a map of landmarks. I looked at the source code a bit and it doesn't seem to be an especially useful or realistic "sensor."

Consider:

Map creates a set of features - map.map = dim * (2*rand(2, nfeatures)-1);.

RangeBearingSensor gets those set of features - jf = 1:numcols(s.map.map); and then picks a random one to return - jf = jf(i);, or you can pick a particular feature - xf = s.map.map(:,jf); and get the range and heading to that feature - dx = xf(1,:) - xv(:,1); dy = xf(2,:) - xv(:,2); and z = [sqrt(dx.^2 + dy.^2) atan2(dy, dx)-xv(:,3) ];.

The point is, the code completely glosses over how you reconcile a feature on a map to the vehicle. You can say, "where is feature XX?" and the RangeBearingSensor simply returns a range and heading. There's no code in there that really explains how you determine which feature in a set of scan data is feature XX.

For your case, in order to create the same functionality as RangeBearingSensor, you need to know roughly where feature XX is in order to locate it in the scan data, and then you use the scan data for that feature to return where it is. Your scan data might include a bunch of features, or none, and it's up to you to:

Estimate where the features are, so you can

Use the scan data to measure where the features are, so you can

Supply the particle filter with measurements, so you can

Estimate where the features are.

My point is that you're not going to (easily) replicate the functionality of RangeBearingSensor with your own lidar sensor code because RangeBearingSensor uses knowledge that is not directly obtainable - i.e., where all the landmarks are.

You might have two landmarks that are (statistically) in the same location or otherwise close enough that they are indistinguishable from your sensor's point of view. Your sensor can't tell them apart, but RangeBearingSensor uses its knowledge to generate a reading anyways because it generates measurements by taking a perfect measurement to an exact landmark and then adding noise.

Your scenario is trying to take noisy data and first identify the landmark, then use the landmark plus the measurement to eliminate the noise.


问:
Cannot see ground plane patterns with LiDAR
I mounted VLP-16 on the roof of my car while driving, I was expecting the lidar to detect the lanes on the ground since the white lines should have higher reflectivity.

But in fact I cannot see any patterns on the ground.   This is  my rviz screenshot, I can get some higher intensity value on vertical objects, but cannot detect the lanes on the ground.

Is this normal? Do I need to calibrate my lidar for lane detection?

答:
It might work but you need an intensity calibration, to get rid of the false positive. Although, Velodyne calibrates the intensity before they ship the product it is usually not that accurate.

You need to change the color coding to gray to see the lanes with bare eyes or adjust histogram curve to observe the road marks clearly. But definitely, my vlp16 is not that sensitive and very difficult to recognize road marks. I guess a post processing is required to do that.


问:
Shield IMU from magnetic interferences
I experienced some drifting when coming near to magnetic fields with my IMU, so I wondered if it is possible to completely shield the IMU from external influences. Would this be theoretically possible or does the IMU rely on external fields like the earth magnetic field? Are there maybe alternatives to IMUs that are less susceptible to magnetic interferences? I only need the rotational data of the sensor and don't use translational output.</p>

答:
Yes, this person, who experimented with the BNO055 IMU and reported a lot of problems getting reliable readings from the magnetometer, said these problems were partially fixed by:

surrounding the sensor in a Faraday cage (i.e. metal shielding)

shortening the wires connecting the sensor to the other electronics

Title: Shield IMU from magnetic interferences


问:
DC Motors for a ROV?
I am planning to build a homemade ROV, and I wanted to know a couple of things about the motors.  First is: Will it be Ok, if I use a brushed DC motor,  instead of a brushless motor, and is there any major disadvantages ? Second : What RPM DC motor should I aim for ? High RPM or low RPM ? Will 600rpm be enough ? The specific motor that I am talking about is    http://www.ebay.ca/itm/37mm-12V-DC-600RPM-Replacement-Torque-Gear-Box-Motor-New-/320984491847?hash=item4abc2aa747:m:mEBEQXXpqmNg4-vxmFaZP5w

Will this be a good motor for the propellers of the ROV.  I am planning to have 4 motors / propellers. Two for upward and downward thrusting,  and 2 for forward and side thrusting. The propellers that I plan to use, are basic plastic 3 blade propellers,  with diameter,  between 40mm and 50mm.

My main question is, what RPM and torque should I aim for when choosing the DC motor ?

答: For any underwater thrusters you should use a motor with as low rpm as you can (at the same time that means a bigger torgue). And as big propeller as... you should test how big it can. For very low rpm (lets to say 300-500 rpm) it can 3-4 blades).</p>

Title: DC Motors for a ROV?


答:
In addition to SteveO's approaches you could try to change the center of gravity in a way, that the mass of the robot is pushing more downwards onto the wheels when it goes uphill instead of more and more draging it in vertical direction.
This means: Adding some more mass directly above  driving wheels and/or using the rear wheels for driving the robot, might help. Also implementing an all-wheel-drive might be beneficial.

Another idea is to use a tire profile, instead of "slicks". But, this is intuitive and might even worse the issues if the track itself is flat and even.


问:
How much weight can DC Motor carry?
How much weight can following Brushed Motors carry together?

4X 12 Volt 100rpm supplied voltage => (5/17)*12

2X 12 Volt 100rpm supplied voltage => (7/17)*12

These motors are basically the wheels for my battle bot.

Here is the link to the Motor.

I am new to this so please tell me if I'm wrong somewhere.

答:
Well, to answer this question for your special case, one needs more information about the motors. Maybe, you can supply a product code. And one needs more details of the involved mechanics... is it a car-like application? Is it going up-hill or down-hill? How long needs the motion to last? How well is the cooling? And so on...

I'll try to give you an idea on what all these data means which you can find out about a motor...

You can approximately calculate some kind of upper limit for the "power" a motor can deliver for an infinite duration, due to thermal design limits at lets say 'standard conditions' (normal room temperature, normal ventilation, ...):

A Motor has one or multiple phases (coils that will induce a magnetic field), which have:

I_max - a maximum design current (in the unit: Ampere or milli-Ampere),

R- an electrical resistance (given in the unit Ohms)

U_max - a maximum design voltage (given in Volts)

At least two of the above must be known. The relation between them is: R = U_max / I_max, so you can calculate the third one. You can measure the current for a given voltage or the restance of the coil, if you need to. But, make sure the motor doesn't move while measuring (e.g. by fixing the axle).

If you have I_max and U_max you can calculate P_max = I_max * U_max [Unit: Watts]. This will be the maximum power the Motor will -consume- without destruction under normal conditions! It can stand more power, if you improve cooling. And you can overload a motor for a limited time, until it gets too hot and finally breaks...

Each motor has an efficiency which depends on the motor itself and how fast it is spinning (see datasheet). This means the ratio of energy in form of motion or acceleration that is produced relative to its consumed energy. At optimum speed this can be as low as 50% or even higher than 90%, this depends on the motor.

Each good motor datasheet has some kind of curve that gives you an value for efficiency (%), torque (typically in: Ncm, Nm, mN*m) and motor current. At speed=0 the motor current is the highest (I_max) and the torque (=holding torque) is also at its highest value. The torque is the value for the rotational force. The holding torque is achieved when applying the nominal/design voltage of your motor at stand-still (=very short period until it moves faster) and/or blocked motion (=until not blocked anymore, good for measurements). If you use a higher voltage (which is valid but might damage the motor), the holding torque will also be higher.
You can measure the holding torque, by mounting a little lever to the motor (e.g. r=10 cm=0.1m long) which the motor pushes onto e.g. a kittchen scale. The mass m (in Kilograms, e.g. m=34g=0.034kg) measured by the scale can then be used to calculate the force, which is F = m * g, where gis the earth gravity constant (approx. 9.81 m/s²). Then you can multiply the length of your lever by the measured force, you'll get the torque: M = F * r = m * g * r = 0.034kg * 9.81 m/s² * 0.1m = 0,033 Nm ... where "Nm" means "Newton-Meters" or if you use the lever length in cm it is: M = 0.034kg * 9.81 m/s² * 10cm = 3,33 Ncm (Newton-Centi-Meters).

Mechanical systems usually need to overcome the stiction first, which usually depends on the mass of it (which pushes it onto a surface), the materials of the material that has contact to the surface and the material of the surface itself.

What is Stiction? Here is a little experiment: You might have noticed that your smartphone will not slide downward an slightly inclined surface... the gravitational force is not strong enough, yet. But, if you push it a bit, it will overcome stiction ("sticking to the surface") and will slide on its own. As said, how strong the stiction is depends on the material of the thing... e.g. rubber on wood has an higher stiction than flat, polished plastic on polished glass. So also the roughness of the materials have an influence.
The force to overcome Stictions can be calculated by the formula: Fs = mu * Fg, were mu is the constant for the materials and Fg is the force that pushes the thing to the surface. In a simple case (e.g. a smartphone laying on a flat and horizontal surface, no inclination) this can be Fg = m * g, where m is the mass (e.g. of the phone) to be moved and g = 9.81 m/s² (earth gravity constant) again.

The needed torque depends on the mechanical system. In a simple case you just mount some wheels on the motor. Then the radius (half of the diameter) of your wheels are r. And your needed torque to overcome stiction will then be Ms = Fs * r. If you use larger wheels you need a higher torque. If you use gears you can also influence the needed torque (in both directions), but you'll decrease the efficiency of the system and - at the same time - introduce a now stiction torque of the gears (which might or might be significant).

As soon we've overcome stiction, you will have still friction that might stop things from moving... that means deaccelerating it until it finally stops again. But, theses forces are usually much smaller (for slow speeds only!). And remember you can - for a short period of time - drive your motor with a higher current/voltage than specified!

All those friction, which depends on a lot of other factors, limits how fast it can move (top speed)... and finally how fast it can accelerate to that speed (maximum acceleration). This all falls under the topic "dynamics" and there is lots of it to learn... but, the basics can be learned quite fast.

So your implicit questions actually are:

How much holding torque do my motors have? (needed: Motor Datasheet)

How much power can my motor controller provide (for a short [or infinite] period of time)?

How much torque do I need to overcome stiction? (needed: Info on mechanics, as kind of wheels, surface, style of movement)

I hope you got some information to start your further investigation on that topic. If you have more questions, just ask.

Useful Links:

https://en.wikipedia.org/wiki/Stiction

https://en.wikipedia.org/wiki/Friction

https://en.wikipedia.org/wiki/Analytical_dynamics

Edit

You provided a link to some technical data, which are:

```<code>   Weight: 100 gm(Approx.)
   RPM: 100
   Operating Voltage: 12V DC
   Gearbox: Attached Plastic (spur)Gearbox
   Shaft diameter: 6mm
   Shaft Length: 21 mm
   Torque: 1.2 Kg-cm.
   No-load current = 60 mA(Max)
   Load current = 300 mA(Max).
   Dimensions: Body Diameter: 38mm; Motor Length with shaft: 77 mm;
   Same size motor available in various RPMs.
</code>```

As we can see, the motor already has some gearbox attached to it, which reduces the maximum rotational to 100 rpm (=rotations per minute) and increases the available torque at the same time. The maximum torque is given as 1.2 kg*cm (which includes the gearbox-transition), which means having wheels with an radius of 1 cm (or 2cm in diameter) will give you a force that is equivalent to 1.2 kg in weight at nominal voltage, as long as your electronics can provide a current of 300 mA (load current).

However, 1.2 kg "weight" force doesn't mean, that you are limited to a weight of 1.2 kg for e.g. a robot, as 1.2 kg do not mean the weight of the "thing" which is moved but an equivalent force. It means a force that is equivalent to the force that gravity causes at 1.2 liters of water (in container which we asume to have no weight) to be pulled downwards. If you wanted to pull 1.2 kg in upwards direction, you would need a bit more than this force...

If you just need to drive a robot on a 100% horizontal surface you need to overcome Stiction (see formulae above), which for a robot with a weight of 1.2kg on wheels is much less than a force of 1.2kg "weight" (=1.2kg * 9.81m/s² = 11.8N). Anyhow, your robot will also need to climb slightly upwards.

Lets assume 20% inclination, which means you need a force equivalent to sin(20°) times the weight of the robot. And let us assume this force needed is much more than Stiction. In that case you can pull 1/sin(20°)=2.92 times 1.2 kg = ~3.5 kg upwards on a surface with an inclination below 20° with this motor using wheels with an radius of r=1cm. If your wheels are bigger, the maximum robot weight will be less (e.g. r=2cm ==> 3.5kg/2 = 1.75kg).

However, your speed will get near to zero if you inclination is near to 20%. So every weight that is less than this limit ensures you some reserve for accelerating your robot, even at 20% inclination. If our maximum robot weight is 3.5 kg according to the above calculation and the real robot has a weight of 2kg, then your acceleration force will be like 1.5kg "weight" pulling it forward on a horizontal surface. As stated above, 1.5 kg "weight" means in fact a force of 1.5 kg * 9.81 m/s² = 14.715 kg*m/s². Our example robot having a weight m=2kg will be accelerated by a force of F=14.716 kg*m/s². The formula that relates mass, force and acceleration is: F = m*a, where F is the force, m is the mass and a is the acceleration. So a = F/m would be 14.715 kg*m/s² divided by 2 kg and therefore: ~7.358 m/s². This means within 1 second your robot would reach a speed of 7.36 m/s (or 26.5 km/h) if there was no friction. Also the maximum speed is 100 rpm; so having the wheel radius of r=1cm the robot will move forward U=2*r*3.14=6.28 cm. Having 100 revolutions per minute gives us 628 cm = 6.28 m per minute or 0.1046 m/s as our top speed, if there is just the friction of the motor itself within its gearbox and so on... so it moves 10,46 cm forward per second. If you need more speed you need bigger wheels or some gears... but as said, your maximum weight will drop then.

IMPORTANT: Calculation of all the friction correct is even more complicated, so dont expect the full 10,46 cm per second! This is just an upper limit that is known for sure...

And of course having 4 motors will give you 4 times the torque, but will also increase the weight of the whole robot and the overall current needed to drive the motors.

Title: How much weight can DC Motor carry?

Body:
Well, to answer this question for your special case, one needs more information about the motors. Maybe, you can supply a product code. And one needs more details of the involved mechanics... is it a car-like application? Is it going up-hill or down-hill? How long needs the motion to last? How well is the cooling? And so on...

I'll try to give you an idea on what all these data means which you can find out about a motor...

You can approximately calculate some kind of upper limit for the "power" a motor can deliver for an infinite duration, due to thermal design limits at lets say 'standard conditions' (normal room temperature, normal ventilation, ...):

A Motor has one or multiple phases (coils that will induce a magnetic field), which have:

I_max - a maximum design current (in the unit: Ampere or milli-Ampere),

R- an electrical resistance (given in the unit Ohms)

U_max - a maximum design voltage (given in Volts)

At least two of the above must be known. The relation between them is: R = U_max / I_max, so you can calculate the third one. You can measure the current for a given voltage or the restance of the coil, if you need to. But, make sure the motor doesn't move while measuring (e.g. by fixing the axle).

If you have I_max and U_max you can calculate P_max = I_max * U_max [Unit: Watts]. This will be the maximum power the Motor will -consume- without destruction under normal conditions! It can stand more power, if you improve cooling. And you can overload a motor for a limited time, until it gets too hot and finally breaks...

Each motor has an efficiency which depends on the motor itself and how fast it is spinning (see datasheet). This means the ratio of energy in form of motion or acceleration that is produced relative to its consumed energy. At optimum speed this can be as low as 50% or even higher than 90%, this depends on the motor.

Each good motor datasheet has some kind of curve that gives you an value for efficiency (%), torque (typically in: Ncm, Nm, mN*m) and motor current. At speed=0 the motor current is the highest (I_max) and the torque (=holding torque) is also at its highest value. The torque is the value for the rotational force. The holding torque is achieved when applying the nominal/design voltage of your motor at stand-still (=very short period until it moves faster) and/or blocked motion (=until not blocked anymore, good for measurements). If you use a higher voltage (which is valid but might damage the motor), the holding torque will also be higher.
You can measure the holding torque, by mounting a little lever to the motor (e.g. r=10 cm=0.1m long) which the motor pushes onto e.g. a kittchen scale. The mass m (in Kilograms, e.g. m=34g=0.034kg) measured by the scale can then be used to calculate the force, which is F = m * g, where gis the earth gravity constant (approx. 9.81 m/s²). Then you can multiply the length of your lever by the measured force, you'll get the torque: M = F * r = m * g * r = 0.034kg * 9.81 m/s² * 0.1m = 0,033 Nm ... where "Nm" means "Newton-Meters" or if you use the lever length in cm it is: M = 0.034kg * 9.81 m/s² * 10cm = 3,33 Ncm (Newton-Centi-Meters).

Mechanical systems usually need to overcome the stiction first, which usually depends on the mass of it (which pushes it onto a surface), the materials of the material that has contact to the surface and the material of the surface itself.

What is Stiction? Here is a little experiment: You might have noticed that your smartphone will not slide downward an slightly inclined surface... the gravitational force is not strong enough, yet. But, if you push it a bit, it will overcome stiction ("sticking to the surface") and will slide on its own. As said, how strong the stiction is depends on the material of the thing... e.g. rubber on wood has an higher stiction than flat, polished plastic on polished glass. So also the roughness of the materials have an influence.
The force to overcome Stictions can be calculated by the formula: Fs = mu * Fg, were mu is the constant for the materials and Fg is the force that pushes the thing to the surface. In a simple case (e.g. a smartphone laying on a flat and horizontal surface, no inclination) this can be Fg = m * g, where m is the mass (e.g. of the phone) to be moved and g = 9.81 m/s² (earth gravity constant) again.

The needed torque depends on the mechanical system. In a simple case you just mount some wheels on the motor. Then the radius (half of the diameter) of your wheels are r. And your needed torque to overcome stiction will then be Ms = Fs * r. If you use larger wheels you need a higher torque. If you use gears you can also influence the needed torque (in both directions), but you'll decrease the efficiency of the system and - at the same time - introduce a now stiction torque of the gears (which might or might be significant).

As soon we've overcome stiction, you will have still friction that might stop things from moving... that means deaccelerating it until it finally stops again. But, theses forces are usually much smaller (for slow speeds only!). And remember you can - for a short period of time - drive your motor with a higher current/voltage than specified!

All those friction, which depends on a lot of other factors, limits how fast it can move (top speed)... and finally how fast it can accelerate to that speed (maximum acceleration). This all falls under the topic "dynamics" and there is lots of it to learn... but, the basics can be learned quite fast.

So your implicit questions actually are:

How much holding torque do my motors have? (needed: Motor Datasheet)

How much power can my motor controller provide (for a short [or infinite] period of time)?

How much torque do I need to overcome stiction? (needed: Info on mechanics, as kind of wheels, surface, style of movement)

I hope you got some information to start your further investigation on that topic. If you have more questions, just ask.

Useful Links:

https://en.wikipedia.org/wiki/Stiction

https://en.wikipedia.org/wiki/Friction

https://en.wikipedia.org/wiki/Analytical_dynamics

Edit

You provided a link to some technical data, which are:

   Weight: 100 gm(Approx.)
   RPM: 100
   Operating Voltage: 12V DC
   Gearbox: Attached Plastic (spur)Gearbox
   Shaft diameter: 6mm
   Shaft Length: 21 mm
   Torque: 1.2 Kg-cm.
   No-load current = 60 mA(Max)
   Load current = 300 mA(Max).
   Dimensions: Body Diameter: 38mm; Motor Length with shaft: 77 mm;
   Same size motor available in various RPMs.

As we can see, the motor already has some gearbox attached to it, which reduces the maximum rotational to 100 rpm (=rotations per minute) and increases the available torque at the same time. The maximum torque is given as 1.2 kg*cm (which includes the gearbox-transition), which means having wheels with an radius of 1 cm (or 2cm in diameter) will give you a force that is equivalent to 1.2 kg in weight at nominal voltage, as long as your electronics can provide a current of 300 mA (load current).

However, 1.2 kg "weight" force doesn't mean, that you are limited to a weight of 1.2 kg for e.g. a robot, as 1.2 kg do not mean the weight of the "thing" which is moved but an equivalent force. It means a force that is equivalent to the force that gravity causes at 1.2 liters of water (in container which we asume to have no weight) to be pulled downwards. If you wanted to pull 1.2 kg in upwards direction, you would need a bit more than this force...

If you just need to drive a robot on a 100% horizontal surface you need to overcome Stiction (see formulae above), which for a robot with a weight of 1.2kg on wheels is much less than a force of 1.2kg "weight" (=1.2kg * 9.81m/s² = 11.8N). Anyhow, your robot will also need to climb slightly upwards.

Lets assume 20% inclination, which means you need a force equivalent to sin(20°) times the weight of the robot. And let us assume this force needed is much more than Stiction. In that case you can pull 1/sin(20°)=2.92 times 1.2 kg = ~3.5 kg upwards on a surface with an inclination below 20° with this motor using wheels with an radius of r=1cm. If your wheels are bigger, the maximum robot weight will be less (e.g. r=2cm ==> 3.5kg/2 = 1.75kg).

However, your speed will get near to zero if you inclination is near to 20%. So every weight that is less than this limit ensures you some reserve for accelerating your robot, even at 20% inclination. If our maximum robot weight is 3.5 kg according to the above calculation and the real robot has a weight of 2kg, then your acceleration force will be like 1.5kg "weight" pulling it forward on a horizontal surface. As stated above, 1.5 kg "weight" means in fact a force of 1.5 kg * 9.81 m/s² = 14.715 kg*m/s². Our example robot having a weight m=2kg will be accelerated by a force of F=14.716 kg*m/s². The formula that relates mass, force and acceleration is: F = m*a, where F is the force, m is the mass and a is the acceleration. So a = F/m would be 14.715 kg*m/s² divided by 2 kg and therefore: ~7.358 m/s². This means within 1 second your robot would reach a speed of 7.36 m/s (or 26.5 km/h) if there was no friction. Also the maximum speed is 100 rpm; so having the wheel radius of r=1cm the robot will move forward U=2*r*3.14=6.28 cm. Having 100 revolutions per minute gives us 628 cm = 6.28 m per minute or 0.1046 m/s as our top speed, if there is just the friction of the motor itself within its gearbox and so on... so it moves 10,46 cm forward per second. If you need more speed you need bigger wheels or some gears... but as said, your maximum weight will drop then.

IMPORTANT: Calculation of all the friction correct is even more complicated, so dont expect the full 10,46 cm per second! This is just an upper limit that is known for sure...

And of course having 4 motors will give you 4 times the torque, but will also increase the weight of the whole robot and the overall current needed to drive the motors.


问:
Using an IMU to build an INS
What's needed to utilize an IMU such as the ArduIMU+ V3 to be used in an INS. Is there any other hardware needed? </p>

答:
As you said you want to use it to detect, if your robot moves forward, I think it is good enough, if your robot is big enough.
But, you need to calibrate it! (Not once but continously... before and during operation). You need of course some power supply and there should be no huge metal parts, magnets or coils in nearby, so that the magnetometer isn't disturbed.

Within a controlled environment, a magnetometer will give you stable readings on the orientation (where is north as a 3D vector), which won't drift. However it is quite slow.

An gyroscope is faster and will give you information on rotation. However, you'll measure some "biased error". And to get your orientation, you'll sum up all measurements... that contain this biased error. And this will give you an orientation that slightly rotates, because the error isn't 0 on average but has a negative or positive offset value (for each axis!) that even changes over time (e.g. influenced by temperature, battery voltage). However, one can use the Magnetometer to detect this, as it is quite stable (if not disturbed by magnets and so on).

The accelerometer will give you the acceleration in each direction, but also with an biased error! If you integrate up the acceleration (including the error) over time, you will get the speed... which will increase more and more, due to the biased error. So even your robot doesn't move at all, it would actually give you more than the speed of light within a very short time span. Also it is biased by gravition. That means under normal conditions you measure a downwards acceleration (~9.81 m/s²) - except if the sensor is in free fall, where it measures ~0 m/s².
The only way to get around this, is to make assumptions in the motion model. For example, if you mount it to the foot/shoe of a robot (which works really good for humans). You can assume: if you only measure something near to 9.81 m² acceleration pointing downwards, the speed is 0. That means you reset your speed to 0 m/s, and only let it have different values if the accelerations differs more than a threshold value.
There are also some online-calibration algorithms for accelerometers. They assume that you either measure some acceleration close to 0 m/s² (free fall) that can be used to correct the bias. Or you measure something that is earth graviation in any direction +/- some unbiased error. You can imagine that your measurements are either assumed as a vector from the center to the sphere's surface which has a radius of approx. 9.81 [m/s²]. Note that the earth gravition isn't exact and slightly location dependent. And if your robot needs to work on other planets or in space, there will be different values, too! ;-)

An ATMega328 should be fast enough to do those calculations, but maybe not at the best possible accuracy that can be achieved by these sensors. I don't know what kind of software is delevered with this board... If nothing is provided you need to grasp the following topics: kalman filters and quaternions; or need to find some software that does it for you.

I think it is doable with this board, but it depends much on details of your application... needed accuracy and how big your dimensions are (is your robot 3 cm small or is it a meter in size)? Do you need motion and speed only?

Anyhow, for sake of simplicity, I would suggest you to use a vision based location tracking instead. You can record a video of the robots "vision" (or "eyes") and detect the size and location of one or multiple markers in real time. If you know where the marker is and how big it is in reality, you can estimate the robots position. This is much simpler and much more accurate, but might need a bit more processing power and a camera, but saves you a lot of time.

Title: Using an IMU to build an INS


问:
roslaunch mavros px4.launch not working properly
when I run roslaunch mavros px4.launch command process start and shut down.</p>

```<code>> ... logging to /home/yograj/.ros/log/77663396-f411-11e7-b93c-3c77e68de09b/roslaunch-yograj-Inspiron-5537-12518.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
>
> started roslaunch server http://yograj-Inspiron-5537:40223/
>
> SUMMARY
>
> ========
>
> CLEAR PARAMETERS
>
>  * /mavros/
> PARAMETERS
>
>  * /mavros/cmd/use_comp_id_system_control: False
>  * /mavros/conn/heartbeat_rate: 1.0
>  * /mavros/conn/system_time_rate: 1.0
>  * /mavros/conn/timeout: 10.0
>  * /mavros/conn/timesync_rate: 10.0
>  * /mavros/distance_sensor/hrlv_ez4_pub/field_of_view: 0.0
>  * /mavros/distance_sensor/hrlv_ez4_pub/frame_id: hrlv_ez4_sonar
>  * /mavros/distance_sensor/hrlv_ez4_pub/id: 0
>  * /mavros/distance_sensor/hrlv_ez4_pub/orientation: ROLL_180
>  * /mavros/distance_sensor/hrlv_ez4_pub/send_tf: True
>  * /mavros/distance_sensor/hrlv_ez4_pub/sensor_position/x: 0.0
>  * /mavros/distance_sensor/hrlv_ez4_pub/sensor_position/y: 0.0
>  * /mavros/distance_sensor/hrlv_ez4_pub/sensor_position/z: -0.1
>  * /mavros/distance_sensor/laser_1_sub/id: 3
>  * /mavros/distance_sensor/laser_1_sub/orientation: ROLL_180
>  * /mavros/distance_sensor/laser_1_sub/subscriber: True
>  * /mavros/distance_sensor/lidarlite_pub/field_of_view: 0.0
>  * /mavros/distance_sensor/lidarlite_pub/frame_id: lidarlite_laser
>  * /mavros/distance_sensor/lidarlite_pub/id: 1
>  * /mavros/distance_sensor/lidarlite_pub/orientation: ROLL_180
>  * /mavros/distance_sensor/lidarlite_pub/send_tf: True
>  * /mavros/distance_sensor/lidarlite_pub/sensor_position/x: 0.0
>  * /mavros/distance_sensor/lidarlite_pub/sensor_position/y: 0.0
>  * /mavros/distance_sensor/lidarlite_pub/sensor_position/z: -0.1
>  * /mavros/distance_sensor/sonar_1_sub/id: 2
>  * /mavros/distance_sensor/sonar_1_sub/orientation: ROLL_180
>  * /mavros/distance_sensor/sonar_1_sub/subscriber: True
>  * /mavros/fake_gps/eph: 2.0
>  * /mavros/fake_gps/epv: 2.0
>  * /mavros/fake_gps/fix_type: 3
>  * /mavros/fake_gps/geo_origin/alt: 408.0
>  * /mavros/fake_gps/geo_origin/lat: 47.3667
>  * /mavros/fake_gps/geo_origin/lon: 8.55
>  * /mavros/fake_gps/gps_rate: 5.0
>  * /mavros/fake_gps/mocap_transform: True
>  * /mavros/fake_gps/satellites_visible: 5
>  * /mavros/fake_gps/tf/child_frame_id: fix
>  * /mavros/fake_gps/tf/frame_id: map
>  * /mavros/fake_gps/tf/listen: False
>  * /mavros/fake_gps/tf/rate_limit: 10.0
>  * /mavros/fake_gps/tf/send: False
>  * /mavros/fake_gps/use_mocap: True
>  * /mavros/fake_gps/use_vision: False
>  * /mavros/fcu_url: udp://:14540@127....
>  * /mavros/gcs_url:
>  * /mavros/global_position/child_frame_id: base_link
>  * /mavros/global_position/frame_id: map
>  * /mavros/global_position/rot_covariance: 99999.0
>  * /mavros/global_position/tf/child_frame_id: base_link
>  * /mavros/global_position/tf/frame_id: map
>  * /mavros/global_position/tf/global_frame_id: earth
>  * /mavros/global_position/tf/send: False
>  * /mavros/global_position/use_relative_alt: True
>  * /mavros/image/frame_id: px4flow
>  * /mavros/imu/angular_velocity_stdev: 0.000349065850399
>  * /mavros/imu/frame_id: base_link
>  * /mavros/imu/linear_acceleration_stdev: 0.0003
>  * /mavros/imu/magnetic_stdev: 0.0
>  * /mavros/imu/orientation_stdev: 1.0
>  * /mavros/local_position/frame_id: map
>  * /mavros/local_position/tf/child_frame_id: base_link
>  * /mavros/local_position/tf/frame_id: map
>  * /mavros/local_position/tf/send: False
>  * /mavros/local_position/tf/send_fcu: False
>  * /mavros/mission/pull_after_gcs: True
>  * /mavros/mocap/use_pose: True
>  * /mavros/mocap/use_tf: False
>  * /mavros/odometry/estimator_type: 3
>  * /mavros/odometry/frame_tf/desired_frame: ned
>  * /mavros/plugin_blacklist: ['safety_area', '...
>  * /mavros/plugin_whitelist: []
>  * /mavros/px4flow/frame_id: px4flow
>  * /mavros/px4flow/ranger_fov: 0.118682389136
>  * /mavros/px4flow/ranger_max_range: 5.0
>  * /mavros/px4flow/ranger_min_range: 0.3
>  * /mavros/safety_area/p1/x: 1.0
>  * /mavros/safety_area/p1/y: 1.0
>  * /mavros/safety_area/p1/z: 1.0
>  * /mavros/safety_area/p2/x: -1.0
>  * /mavros/safety_area/p2/y: -1.0
>  * /mavros/safety_area/p2/z: -1.0
>  * /mavros/setpoint_accel/send_force: False
>  * /mavros/setpoint_attitude/reverse_thrust: False
>  * /mavros/setpoint_attitude/tf/child_frame_id: target_attitude
>  * /mavros/setpoint_attitude/tf/frame_id: map
>  * /mavros/setpoint_attitude/tf/listen: False
>  * /mavros/setpoint_attitude/tf/rate_limit: 50.0
>  * /mavros/setpoint_attitude/use_quaternion: False
>  * /mavros/setpoint_position/mav_frame: LOCAL_NED
>  * /mavros/setpoint_position/tf/child_frame_id: target_position
>  * /mavros/setpoint_position/tf/frame_id: map
>  * /mavros/setpoint_position/tf/listen: False
>  * /mavros/setpoint_position/tf/rate_limit: 50.0
>  * /mavros/setpoint_velocity/mav_frame: LOCAL_NED
>  * /mavros/startup_px4_usb_quirk: True
>  * /mavros/sys/disable_diag: False
>  * /mavros/sys/min_voltage: 10.0
>  * /mavros/target_component_id: 1
>  * /mavros/target_system_id: 1
>  * /mavros/tdr_radio/low_rssi: 40
>  * /mavros/time/time_ref_source: fcu
>  * /mavros/time/timesync_avg_alpha: 0.6
>  * /mavros/time/timesync_mode: MAVLINK
>  * /mavros/vibration/frame_id: base_link
>  * /mavros/vision_pose/tf/child_frame_id: vision_estimate
>  * /mavros/vision_pose/tf/frame_id: map
>  * /mavros/vision_pose/tf/listen: False
>  * /mavros/vision_pose/tf/rate_limit: 10.0
>  * /mavros/vision_speed/listen_twist: False
>  * /rosdistro: kinetic
>  * /rosversion: 1.12.12
>
> NODES
>   /
>     mavros (mavros/mavros_node)
>
> ROS_MASTER_URI=http://localhost:11311
>
> process[mavros-1]: started with pid [12536]
> [FATAL] [1515375213.809935923]: UAS: GeographicLib exception: File not readable /usr/share/GeographicLib/geoids/egm96-5.pgm | Run install_geographiclib_dataset.sh script in order to install Geoid Model dataset!
>
> ================================================================================
>
> REQUIRED process [mavros-1] has died!
> process has finished cleanly
> log file: /home/yograj/.ros/log/77663396-f411-11e7-b93c-3c77e68de09b/mavros-1*.log
> Initiating shutdown!
>
> ================================================================================
>
> [mavros-1] killing on exit
> shutting down processing monitor...
> ... shutting down processing monitor complete
> done
</code>```

答:
There's an error at the end of the wall of text you pasted in that states,

GeographicLib exception: File not readable /usr/share/GeographicLib/geoids/egm96-5.pgm

Run install_geographiclib_dataset.sh script in order to install Geoid Model dataset!

Did you run that script?


问:
catkin_make unable to build and throws "Makefile:138: recipe for target 'all' failed make: *** [all] Error 2 Invoking "make -j4 -l4" failed"
I have been trying to build my ROS workspace using catkin_make, where i have cloned a repo/PACKAGE. I tried many of the things mentioned in previous answers to questions similar to my issue but without any progress. I tried building another package and it worked well. I am new to ROS and Linux, and this issue has been impeding me for a 3 days now.

Many thanks in advance!

```abouseif@abouseif-ThinkCentre-M92p:~/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws$ catkin_make
Base path: /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws
Source space: /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src
Build space: /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/build
Devel space: /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/devel
Install space: /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/install
####
#### Running command: "cmake /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src -DCATKIN_DEVEL_PREFIX=/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/devel -DCMAKE_INSTALL_PREFIX=/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/install -G Unix Makefiles" in "/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/build"
####
-- Using CATKIN_DEVEL_PREFIX: /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/kinetic
-- This workspace overlays: /opt/ros/kinetic
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/build/test_results
-- Found gtest sources under '/usr/src/gtest': gtests will be built
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.8
-- BUILD_SHARED_LIBS is on
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~  traversing 3 packages in topological order:
-- ~~  - gazebo_grasp_plugin
-- ~~  - kuka_arm
-- ~~  - kr210_claw_moveit
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- +++ processing catkin package: 'gazebo_grasp_plugin'
-- ==> add_subdirectory(RoboND-Kinematics-Project/gazebo_grasp_plugin)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   thread
--   signals
--   system
--   filesystem
--   program_options
--   regex
--   iostreams
--   date_time
--   chrono
--   atomic
-- Found Protobuf: /usr/lib/x86_64-linux-gnu/libprotobuf.so
-- Boost version: 1.58.0
-- Looking for OGRE...
-- OGRE_PREFIX_WATCH changed.
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'OGRE'
--   Found OGRE, version 1.9.0
-- Found Ogre Ghadamon (1.9.0)
-- Found OGRE: optimized;/usr/lib/x86_64-linux-gnu/libOgreMain.so;debug;/usr/lib/x86_64-linux-gnu/libOgreMain.so
-- Looking for OGRE_Paging...
-- Found OGRE_Paging: optimized;/usr/lib/x86_64-linux-gnu/libOgrePaging.so;debug;/usr/lib/x86_64-linux-gnu/libOgrePaging.so
-- Looking for OGRE_Terrain...
-- Found OGRE_Terrain: optimized;/usr/lib/x86_64-linux-gnu/libOgreTerrain.so;debug;/usr/lib/x86_64-linux-gnu/libOgreTerrain.so
-- Looking for OGRE_Property...
-- Found OGRE_Property: optimized;/usr/lib/x86_64-linux-gnu/libOgreProperty.so;debug;/usr/lib/x86_64-linux-gnu/libOgreProperty.so
-- Looking for OGRE_RTShaderSystem...
-- Found OGRE_RTShaderSystem: optimized;/usr/lib/x86_64-linux-gnu/libOgreRTShaderSystem.so;debug;/usr/lib/x86_64-linux-gnu/libOgreRTShaderSystem.so
-- Looking for OGRE_Volume...
-- Found OGRE_Volume: optimized;/usr/lib/x86_64-linux-gnu/libOgreVolume.so;debug;/usr/lib/x86_64-linux-gnu/libOgreVolume.so
-- Looking for OGRE_Overlay...
-- Found OGRE_Overlay: optimized;/usr/lib/x86_64-linux-gnu/libOgreOverlay.so;debug;/usr/lib/x86_64-linux-gnu/libOgreOverlay.so
CMake Warning at /opt/ros/kinetic/share/catkin/cmake/catkin_package.cmake:166 (message):
  catkin_package() DEPENDS on 'gazebo' but neither 'gazebo_INCLUDE_DIRS' nor
  'gazebo_LIBRARIES' is defined.
Call Stack (most recent call first):
  /opt/ros/kinetic/share/catkin/cmake/catkin_package.cmake:102 (_catkin_package)
  RoboND-Kinematics-Project/gazebo_grasp_plugin/CMakeLists.txt:32 (catkin_package)

-- +++ processing catkin package: 'kuka_arm'
-- ==> add_subdirectory(RoboND-Kinematics-Project/kuka_arm)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- kuka_arm: 0 messages, 1 services
-- +++ processing catkin package: 'kr210_claw_moveit'
-- ==> add_subdirectory(RoboND-Kinematics-Project/kr210_claw_moveit)
-- Configuring done
WARNING: Target "trajectory_sampler" requests linking to directory "/opt/ros/kinetic/lib/roslib".  Targets may link only to libraries.  CMake is dropping the item.
-- Generating done
-- Build files have been written to: /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/build
####
#### Running command: "make -j4 -l4" in "/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/build"
####
Scanning dependencies of target trajectory_msgs_generate_messages_lisp
Scanning dependencies of target actionlib_msgs_generate_messages_lisp
Scanning dependencies of target trajectory_msgs_generate_messages_nodejs
Scanning dependencies of target trajectory_msgs_generate_messages_py
[  0%] Built target trajectory_msgs_generate_messages_nodejs
[  0%] Built target actionlib_msgs_generate_messages_lisp
[  0%] Built target trajectory_msgs_generate_messages_lisp
[  0%] Built target trajectory_msgs_generate_messages_py
Scanning dependencies of target trajectory_msgs_generate_messages_eus
Scanning dependencies of target gazebo_msgs_generate_messages_py
Scanning dependencies of target dynamic_reconfigure_gencfg
Scanning dependencies of target dynamic_reconfigure_generate_messages_py
[  0%] Built target trajectory_msgs_generate_messages_eus
[  0%] Built target dynamic_reconfigure_generate_messages_py
[  0%] Built target gazebo_msgs_generate_messages_py
[  0%] Built target dynamic_reconfigure_gencfg
Scanning dependencies of target dynamic_reconfigure_generate_messages_cpp
Scanning dependencies of target dynamic_reconfigure_generate_messages_eus
Scanning dependencies of target dynamic_reconfigure_generate_messages_lisp
Scanning dependencies of target tf2_msgs_generate_messages_nodejs
[  0%] Built target dynamic_reconfigure_generate_messages_cpp
[  0%] Built target dynamic_reconfigure_generate_messages_eus
[  0%] Built target dynamic_reconfigure_generate_messages_lisp
[  0%] Built target tf2_msgs_generate_messages_nodejs
Scanning dependencies of target tf2_msgs_generate_messages_lisp
Scanning dependencies of target tf2_msgs_generate_messages_eus
Scanning dependencies of target tf2_msgs_generate_messages_cpp
Scanning dependencies of target dynamic_reconfigure_generate_messages_nodejs
[  0%] Built target tf2_msgs_generate_messages_lisp
[  0%] Built target tf2_msgs_generate_messages_eus
[  0%] Built target tf2_msgs_generate_messages_cpp
[  0%] Built target dynamic_reconfigure_generate_messages_nodejs
Scanning dependencies of target std_srvs_generate_messages_cpp
Scanning dependencies of target _catkin_empty_exported_target
Scanning dependencies of target roscpp_generate_messages_nodejs
Scanning dependencies of target tf_generate_messages_eus
[  0%] Built target std_srvs_generate_messages_cpp
[  0%] Built target _catkin_empty_exported_target
[  0%] Built target roscpp_generate_messages_nodejs
[  0%] Built target tf_generate_messages_eus
Scanning dependencies of target geometry_msgs_generate_messages_nodejs
Scanning dependencies of target std_msgs_generate_messages_lisp
Scanning dependencies of target roscpp_generate_messages_lisp
[  0%] Built target geometry_msgs_generate_messages_nodejs
Scanning dependencies of target geometry_msgs_generate_messages_lisp
[  0%] Built target std_msgs_generate_messages_lisp
[  0%] Built target roscpp_generate_messages_lisp
Scanning dependencies of target std_srvs_generate_messages_lisp
Scanning dependencies of target geometry_msgs_generate_messages_eus
[  0%] Built target geometry_msgs_generate_messages_lisp
Scanning dependencies of target roscpp_generate_messages_cpp
[  0%] Built target std_srvs_generate_messages_lisp
[  0%] Built target geometry_msgs_generate_messages_eus
Scanning dependencies of target actionlib_msgs_generate_messages_py
Scanning dependencies of target std_msgs_generate_messages_py
[  0%] Built target roscpp_generate_messages_cpp
Scanning dependencies of target gazebo_msgs_generate_messages_nodejs
[  0%] Built target actionlib_msgs_generate_messages_py
[  0%] Built target std_msgs_generate_messages_py
Scanning dependencies of target gazebo_msgs_generate_messages_cpp
[  0%] Built target gazebo_msgs_generate_messages_nodejs
Scanning dependencies of target std_msgs_generate_messages_nodejs
Scanning dependencies of target geometry_msgs_generate_messages_py
[  0%] Built target gazebo_msgs_generate_messages_cpp
Scanning dependencies of target trajectory_msgs_generate_messages_cpp
[  0%] Built target std_msgs_generate_messages_nodejs
[  0%] Built target geometry_msgs_generate_messages_py
Scanning dependencies of target geometry_msgs_generate_messages_cpp
[  0%] Built target trajectory_msgs_generate_messages_cpp
Scanning dependencies of target sensor_msgs_generate_messages_nodejs
Scanning dependencies of target rosgraph_msgs_generate_messages_cpp
[  0%] Built target geometry_msgs_generate_messages_cpp
Scanning dependencies of target rosgraph_msgs_generate_messages_nodejs
[  0%] Built target sensor_msgs_generate_messages_nodejs
[  0%] Built target rosgraph_msgs_generate_messages_cpp
[  0%] Built target rosgraph_msgs_generate_messages_nodejs
Scanning dependencies of target roscpp_generate_messages_eus
Scanning dependencies of target std_msgs_generate_messages_eus
Scanning dependencies of target std_srvs_generate_messages_py
Scanning dependencies of target gazebo_msgs_generate_messages_eus
[  0%] Built target roscpp_generate_messages_eus
[  0%] Built target std_msgs_generate_messages_eus
[  0%] Built target std_srvs_generate_messages_py
[  0%] Built target gazebo_msgs_generate_messages_eus
Scanning dependencies of target rosgraph_msgs_generate_messages_eus
Scanning dependencies of target std_srvs_generate_messages_eus
Scanning dependencies of target tf_generate_messages_cpp
Scanning dependencies of target actionlib_generate_messages_eus
[  0%] Built target rosgraph_msgs_generate_messages_eus
[  0%] Built target tf_generate_messages_cpp
[  0%] Built target actionlib_generate_messages_eus
[  0%] Built target std_srvs_generate_messages_eus
Scanning dependencies of target rosgraph_msgs_generate_messages_lisp
Scanning dependencies of target std_srvs_generate_messages_nodejs
Scanning dependencies of target gazebo_ros_gencfg
Scanning dependencies of target rosgraph_msgs_generate_messages_py
[  0%] Built target rosgraph_msgs_generate_messages_lisp
[  0%] Built target gazebo_ros_gencfg
[  0%] Built target rosgraph_msgs_generate_messages_py
[  0%] Built target std_srvs_generate_messages_nodejs
Scanning dependencies of target tf_generate_messages_lisp
Scanning dependencies of target roscpp_generate_messages_py
Scanning dependencies of target tf_generate_messages_py
Scanning dependencies of target tf_generate_messages_nodejs
[  0%] Built target tf_generate_messages_lisp
[  0%] Built target roscpp_generate_messages_py
[  0%] Built target tf_generate_messages_py
[  0%] Built target tf_generate_messages_nodejs
Scanning dependencies of target sensor_msgs_generate_messages_cpp
Scanning dependencies of target gazebo_msgs_generate_messages_lisp
Scanning dependencies of target sensor_msgs_generate_messages_lisp
Scanning dependencies of target sensor_msgs_generate_messages_py
[  0%] Built target sensor_msgs_generate_messages_cpp
[  0%] Built target gazebo_msgs_generate_messages_lisp
[  0%] Built target sensor_msgs_generate_messages_lisp
[  0%] Built target sensor_msgs_generate_messages_py
Scanning dependencies of target tf2_msgs_generate_messages_py
Scanning dependencies of target actionlib_generate_messages_cpp
Scanning dependencies of target std_msgs_generate_messages_cpp
Scanning dependencies of target actionlib_msgs_generate_messages_nodejs
[  0%] Built target actionlib_generate_messages_cpp
[  0%] Built target tf2_msgs_generate_messages_py
[  0%] Built target actionlib_msgs_generate_messages_nodejs
[  0%] Built target std_msgs_generate_messages_cpp
Scanning dependencies of target actionlib_msgs_generate_messages_cpp
Scanning dependencies of target sensor_msgs_generate_messages_eus
Scanning dependencies of target actionlib_generate_messages_py
Scanning dependencies of target actionlib_generate_messages_nodejs
[  0%] Built target sensor_msgs_generate_messages_eus
[  0%] Built target actionlib_msgs_generate_messages_cpp
[  0%] Built target actionlib_generate_messages_py
[  0%] Built target actionlib_generate_messages_nodejs
Scanning dependencies of target actionlib_generate_messages_lisp
Scanning dependencies of target actionlib_msgs_generate_messages_eus
Scanning dependencies of target graph_msgs_generate_messages_lisp
Scanning dependencies of target octomap_msgs_generate_messages_cpp
[  0%] Built target actionlib_generate_messages_lisp
[  0%] Built target actionlib_msgs_generate_messages_eus
[  0%] Built target octomap_msgs_generate_messages_cpp
[  0%] Built target graph_msgs_generate_messages_lisp
Scanning dependencies of target object_recognition_msgs_generate_messages_nodejs
Scanning dependencies of target object_recognition_msgs_generate_messages_lisp
Scanning dependencies of target octomap_msgs_generate_messages_py
Scanning dependencies of target moveit_msgs_generate_messages_lisp
[  0%] Built target object_recognition_msgs_generate_messages_nodejs
[  0%] Built target object_recognition_msgs_generate_messages_lisp
[  0%] Built target octomap_msgs_generate_messages_py
[  0%] Built target moveit_msgs_generate_messages_lisp
Scanning dependencies of target moveit_msgs_generate_messages_eus
Scanning dependencies of target object_recognition_msgs_generate_messages_eus
Scanning dependencies of target visualization_msgs_generate_messages_lisp
Scanning dependencies of target moveit_msgs_generate_messages_cpp
[  0%] Built target object_recognition_msgs_generate_messages_eus
[  0%] Built target visualization_msgs_generate_messages_lisp
[  0%] Built target moveit_msgs_generate_messages_eus
Scanning dependencies of target object_recognition_msgs_generate_messages_py
[  0%] Built target moveit_msgs_generate_messages_cpp
Scanning dependencies of target graph_msgs_generate_messages_cpp
Scanning dependencies of target _kuka_arm_generate_messages_check_deps_CalculateIK
[  0%] Built target object_recognition_msgs_generate_messages_py
Scanning dependencies of target shape_msgs_generate_messages_cpp
[  0%] Built target graph_msgs_generate_messages_cpp
Scanning dependencies of target graph_msgs_generate_messages_py
[  0%] Built target shape_msgs_generate_messages_cpp
Scanning dependencies of target moveit_msgs_generate_messages_nodejs
Scanning dependencies of target shape_msgs_generate_messages_py
[  0%] Built target moveit_msgs_generate_messages_nodejs
[  0%] Built target graph_msgs_generate_messages_py
[  0%] Built target shape_msgs_generate_messages_py
Scanning dependencies of target visualization_msgs_generate_messages_cpp
Scanning dependencies of target visualization_msgs_generate_messages_py
[  0%] Built target _kuka_arm_generate_messages_check_deps_CalculateIK
[  0%] Built target visualization_msgs_generate_messages_cpp
Scanning dependencies of target visualization_msgs_generate_messages_eus
[  0%] Built target visualization_msgs_generate_messages_py
Scanning dependencies of target object_recognition_msgs_generate_messages_cpp
Scanning dependencies of target visualization_msgs_generate_messages_nodejs
[  0%] Built target visualization_msgs_generate_messages_eus
Scanning dependencies of target octomap_msgs_generate_messages_eus
[  0%] Built target object_recognition_msgs_generate_messages_cpp
[  0%] Built target visualization_msgs_generate_messages_nodejs
[  0%] Built target octomap_msgs_generate_messages_eus
Scanning dependencies of target moveit_msgs_generate_messages_py
Scanning dependencies of target octomap_msgs_generate_messages_lisp
Scanning dependencies of target graph_msgs_generate_messages_eus
Scanning dependencies of target shape_msgs_generate_messages_lisp
[  0%] Built target moveit_msgs_generate_messages_py
[  0%] Built target octomap_msgs_generate_messages_lisp
[  0%] Built target graph_msgs_generate_messages_eus
Scanning dependencies of target kuka_arm_generate_messages_py
[  0%] Built target shape_msgs_generate_messages_lisp
Scanning dependencies of target shape_msgs_generate_messages_eus
[  8%] Generating Python code from SRV kuka_arm/CalculateIK
Scanning dependencies of target octomap_msgs_generate_messages_nodejs
Scanning dependencies of target kuka_arm_generate_messages_eus
[  8%] Built target shape_msgs_generate_messages_eus
[ 16%] Built target octomap_msgs_generate_messages_nodejs
[ 16%] Generating EusLisp code from kuka_arm/CalculateIK.srv
Scanning dependencies of target moveit_ros_planning_gencfg
[ 25%] Generating EusLisp manifest code for kuka_arm
[ 25%] Built target moveit_ros_planning_gencfg
Scanning dependencies of target graph_msgs_generate_messages_nodejs
[ 25%] Built target graph_msgs_generate_messages_nodejs
Scanning dependencies of target moveit_ros_manipulation_gencfg
[ 25%] Built target moveit_ros_manipulation_gencfg
Scanning dependencies of target kuka_arm_generate_messages_cpp
[ 33%] Generating C++ code from kuka_arm/CalculateIK.srv
Scanning dependencies of target kuka_arm_generate_messages_nodejs
[ 41%] Generating Javascript code from kuka_arm/CalculateIK.srv
[ 50%] Generating Python srv __init__.py for kuka_arm
[ 50%] Built target kuka_arm_generate_messages_nodejs
Scanning dependencies of target shape_msgs_generate_messages_nodejs
[ 50%] Built target shape_msgs_generate_messages_nodejs
Scanning dependencies of target gazebo_grasp_fix
[ 50%] Built target kuka_arm_generate_messages_py
Scanning dependencies of target kuka_arm_generate_messages_lisp
[ 58%] Generating Lisp code from kuka_arm/CalculateIK.srv
[ 58%] Built target kuka_arm_generate_messages_cpp
[ 58%] Built target kuka_arm_generate_messages_lisp
[ 75%] Building CXX object RoboND-Kinematics-Project/gazebo_grasp_plugin/CMakeFiles/gazebo_grasp_fix.dir/src/GazeboGraspFix.cpp.o
[ 75%] Building CXX object RoboND-Kinematics-Project/gazebo_grasp_plugin/CMakeFiles/gazebo_grasp_fix.dir/src/GazeboGraspGripper.cpp.o
[ 75%] Built target kuka_arm_generate_messages_eus
Scanning dependencies of target kuka_arm_generate_messages
Scanning dependencies of target trajectory_sampler
[ 75%] Built target kuka_arm_generate_messages
[ 83%] Building CXX object RoboND-Kinematics-Project/kuka_arm/CMakeFiles/trajectory_sampler.dir/src/trajectory_sampler.cpp.o
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp: In constructor ‘TrajectorySampler::TrajectorySampler(ros::NodeHandle)’:
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:180:43: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in initialization
     bool success = move_group.plan(my_plan);
                                           ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:224:15: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in assignment
       success = move_group.execute(my_plan);
               ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:291:39: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in initialization
         bool worked = move_group.move();
                                       ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:313:13: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in assignment
     success = move_group.move();
             ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:339:13: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in assignment
     success = move_group.move();
             ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:351:13: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in assignment
     success = move_group.plan(my_plan);
             ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:375:15: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in assignment
       success = move_group.execute(my_plan);
               ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:452:39: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in initialization
         bool worked = move_group.move();
                                       ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:497:13: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in assignment
     success = move_group.move();
             ^
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp: In member function ‘bool TrajectorySampler::OperateGripper(const bool&)’:
/home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/src/RoboND-Kinematics-Project/kuka_arm/src/trajectory_sampler.cpp:543:33: error: cannot convert ‘moveit::planning_interface::MoveItErrorCode’ to ‘bool’ in initialization
   bool success = eef_group.move();
                                 ^
RoboND-Kinematics-Project/kuka_arm/CMakeFiles/trajectory_sampler.dir/build.make:62: recipe for target 'RoboND-Kinematics-Project/kuka_arm/CMakeFiles/trajectory_sampler.dir/src/trajectory_sampler.cpp.o' failed
make[2]: *** [RoboND-Kinematics-Project/kuka_arm/CMakeFiles/trajectory_sampler.dir/src/trajectory_sampler.cpp.o] Error 1
CMakeFiles/Makefile2:3178: recipe for target 'RoboND-Kinematics-Project/kuka_arm/CMakeFiles/trajectory_sampler.dir/all' failed
make[1]: *** [RoboND-Kinematics-Project/kuka_arm/CMakeFiles/trajectory_sampler.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 91%] Linking CXX shared library /home/abouseif/main/udacity/roboticsnd/robotics_term1/ROS/catkin_ws/devel/lib/libgazebo_grasp_fix.so
[ 91%] Built target gazebo_grasp_fix
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j4 -l4" failed
```

答:
This is the reason:
make operator bool() explicit in MoveItErrorCode
https://github.com/ros-planning/moveit/commit/4033e577b64ab7ef0e4473342168494f69ef9324</p>


问:
How to build a liquid filling machine using piston?
My team developed a filling machine for liquids which uses a piston to measure and deliver volumes 0.1 to 1 liters into bottles. It is built mostly with mechanical parts and we'd like to replace most of them with electronic ones.

How do I build a machine to pull liquid from a reservoir and fills a bottle using a piston, with electronic parts such as stepper motor, linear actuators and sensors?

I understand this is somewhat vague. Any aligned response is appreciated.

Update:

This machine should, at its max speed, fill a 1 litter bottle with water in 2 seconds (to deliver 30 bottles per minute). Higher viscosity liquids may take longer.

It should not spill so liquid needs some filling acceleration control.

You may assume two operation modes: with bubbles and without bubbles. The first is a plus.

I'd like to be able to change the volume electronically (via a LCD menu).

I thought of a single main valve that switches between the reservoir and the bottle. That should be controlled electronically too. I could use two valves too.

答:
Off the top of my head, the first thing I would try:
Attach a stepper motor to a positive-displacement pump.
(Gearing it down is often necessary).
Then hook the wires from the stepper motor one of the many off-the-shelf stepper motor drivers, perhaps Pololu stepper drivers or the many alternatives.
Then figure out how much volume came out for every revolution of the stepper motor.
Then program the Arduino (or one of many alternatives) to somehow detect when there is a bottle in position and how much volume it needs, pump the appropriate volume into the bottle, and stop.

A note near the bottom of
one filling machine vendor
points out that sometimes constant-volume filling doesn't work --
sometimes it's better to start filling when the bottle is in position,
then turn off the pump
when the liquid has reached the fill line.

My understanding is that a visible-light laser and a photo-sensor
is the easiest way to manually line up a non-contact sensor to the appropriate fill line.

Have you searched Google for "bottle filling" to see if maybe there's an off-the-shelf system that already does most of what you need to do?


问:
This script require root privileges! | what is going on ?
I run the following command to install GeographicLib datasets for mavros inside the catkin_ws directory (catkin workspace).

```<code>./src/mavros/mavros/scripts/install_geographiclib_datasets.sh
This script require root privileges!
</code>```

but I get that message in return. what does it mean and how to get the above mavros dependency(GeographicLib datasets) installed successfully?
Before this command, I followed the source installation process as mentioned here.

答:
Do it with sudo:

sudo ./src/mavros/mavros/scripts/install_geographiclib_datasets.sh


问:
Calculating C for a 6-DOF robotic arm
I've seen this equation for calculating the dynamics of a robotic arm a bunch:

$\boldsymbol{\tau} = \boldsymbol{M}(\boldsymbol{q})\ddot{\boldsymbol{q}} + \boldsymbol{C}(\boldsymbol{q},\dot{\boldsymbol{q}})\dot{\boldsymbol{q}} + \boldsymbol{G}(\boldsymbol{q})$

Now, I believe I have the ${M}$ and ${G}$ terms calculated properly (though not through single matrices, which perhaps is an error in itself) as well as a reasonably good PID controller, so I've been researching how to get ${C}$, which represents both centrifugal and Coriolis effects. My robot is pretty unstable without it, but I cannot figure out how to compute it. I don't have access to MATLAB; I'm using C++ with ROS and MoveIt!, so I can easily get the Jacobians and many other features of my robot.

Can anyone help me out? Everyone seems to just be saying along the lines of "Now calculate ${C}$..."

答: Chapter 4 of this Cal tech paper derives C based on partial derivatives of the inertia matrix M and joint velocities.  I think their explanation, which is based on Lagrangian dynamics, is pretty clear.  </p>

Title: Calculating C for a 6-DOF robotic arm


问:
Are there any big size open source robot project(servant like robot maybe)
I am trying to build a big size robot (150CM height) like this:

But I don't have mechanical engineering knowledge for that. Also it's only a prototype to show how the robot will act(it's more relies on image/voice recognizing and processing). So I am looking for an open source project to build a robot that it's easy and cheap to build.(I mean something like instructable projects)

答:
I would look at the Flash Robotics "Flash", http://flashrobotics.com/products/flash

If you follow the "documentation" link you will find complete documentation for the robot. Yes, it is open-source, and you can build the entire robot from their plans and BOM. There are YouTube videos if you search "emys flash robot."

Emys is the head alone. There is a pro model and a kids model. I much prefer the pro model. The entire robot including the head is called "Flash" or "Flash Robot."

I intend to build a version of the Emys head for a project I'm working on. The body would have been perfect at one time, but now I'm living in a motorhome which doesn't have enough room. :(


问:
Are there any Open-Source bricks projects for robotics?
I mean some bricks like Lego/Meccano with a community like Instructables site, those share their models and robots with others. Also the 3D models of bricks(in solidworks format for example) are free to use or the parts are available to buy at the market!</p>

答:
Dexter Industries has a board (the BrickPi) which attaches to the Raspberry Pi 3 and allows the Pi to control Lego Mindstorms devices. Dexter Industries hosts a site which has directions for building various robots using this device.

I did build a few robots with an earlier version of the BrickPi.


问:
Are there any open-source congnative planing frameworks for robotics?
I have seen a lot of academic papers, but no framework that I can download and use. There are even projects, such as OpenCog, which might be usable in a few years.

I would like to know of the existence of any open-source goal/cognitive/planning frameworks now.

There is a lot of software for motion planning, but I would like a way to determine where the robot wants to do before planning how to get there.

答: Have a look at ROS. They have motion planning packages. Sorry I can't provide more detail at this time, but I know ROS packages exist... and they are open source. This is a good question for their forum if you don't get a better answer here.</p>


答:
KnowRob is a knowledge processing system that combines knowledge representation and reasoning methods with techniques for acquiring knowledge and for grounding the knowledge in a physical system and can serve as a common semantic framework for integrating information from different sources. KnowRob combines static encyclopedic knowledge, common-sense knowledge, task descriptions, environment models, object information and information about observed actions that has been acquired from various sources (manually axiomatized, derived from observations, or imported from the web). It supports different deterministic and probabilistic reasoning mechanisms, clustering, classification and segmentation methods, and includes query interfaces as well as visualization tools.

http://www.knowrob.org/

Title: Are there any open-source congnative planing frameworks for robotics?

Body:
I have seen a lot of academic papers, but no framework that I can download and use. There are even projects, such as OpenCog, which might be usable in a few years.

I would like to know of the existence of any open-source goal/cognitive/planning frameworks now.

There is a lot of software for motion planning, but I would like a way to determine where the robot wants to do before planning how to get there.


答:
If you're calculating the moment of inertia for each link relative to each joint, then that's M! The only "tricky" thing to be aware of is that the moments of inertia compound - you must take into account the subsequent joints.

Consider your arm.

You have a hand, which has some moment of inertia. Your wrist joint must accelerate your hand to get motion from your hand. Use the parallel axis theorem to translate the moment of inertia from your hand center of mass to the wrist joint.

You have a forearm, which also has some moment of inertia. Your elbow must accelerate your forearm, BUT IT MUST ALSO ACCELERATE YOUR HAND. Your hand is attached to the forearm by the wrist. Now you need the parallel axis theorem to translate the moment of inertia of your forearm to your elbow, AND you need the parallel axis theorem to translate the moment of inertia from your hand to your elbow.

In step 1, the distance you used for the parallel axis theorem was the distance from its center of mass to the wrist, but in step 2 you need the distance from the hand to the elbow, which is a function of the wrist angle.

Everything compounds again when you go to the shoulder - upper arm is easy, center of mass to the shoulder, but now forearm (relative to shoulder) is a function of elbow angle and hand (relative to shoulder) is a function of wrist angle AND elbow angle.

The shoulder has to accelerate the upper arm AND the forearm AND the hand. The effective moment of inertia for the shoulder joint must include the transformed moments of inertia for all subsequent joints.

Title: Calculating C for a 6-DOF robotic arm

Body:
I've seen this equation for calculating the dynamics of a robotic arm a bunch:

$\boldsymbol{\tau} = \boldsymbol{M}(\boldsymbol{q})\ddot{\boldsymbol{q}} + \boldsymbol{C}(\boldsymbol{q},\dot{\boldsymbol{q}})\dot{\boldsymbol{q}} + \boldsymbol{G}(\boldsymbol{q})$

Now, I believe I have the ${M}$ and ${G}$ terms calculated properly (though not through single matrices, which perhaps is an error in itself) as well as a reasonably good PID controller, so I've been researching how to get ${C}$, which represents both centrifugal and Coriolis effects. My robot is pretty unstable without it, but I cannot figure out how to compute it. I don't have access to MATLAB; I'm using C++ with ROS and MoveIt!, so I can easily get the Jacobians and many other features of my robot.

Can anyone help me out? Everyone seems to just be saying along the lines of "Now calculate ${C}$..."


问:
Once matching features are computed between a stereo pair, how can they be tracked?
I am currently working on a SLAM-like application using a variable baseline stereo rig. Assuming I'm trying to perform visual SLAM using a stereo camera, my initialization routine would involve producing a point cloud of all 'good' features I detect in the first pair of images.

Once this map is created and the cameras start moving, how do I keep 'track' of the original features that were responsible for this map, as I need to estimate my pose? Along with feature matching between the stereo pair of cameras, do I also have to perform matching between the initial set of images and the second set to see how many features are still visible (and thereby get their coordinates)? Or is there a more efficient way of doing this, through for instance, locating the overlap in the two points clouds?

答:
This will depend a bit on how you are detecting your features and how you are estimating motion between frames. Classic approaches would start with detecting SIFT-like features in each image, which provide a descriptor for each detected feature as well as the point locations. These descriptors provide evidence of whether two detected features correspond to the same world point.

In these classical approaches, you will need to do a search for corresponding feature points between successive stereo image frames in order to estimate motion, as well as possibly within the stereo pair. Depending on how your frame rate compares to camera motion, you may be able to restrict the search area for these correspondences. Then this same correspondence information provides most of what's needed for tracking.
See this Stereo Visual Odometry Tutorial for a detailed overview of such an approach.

There may be benefit to keeping track of particular points over longer periods as well, since longer-lived features show evidence of being more stable and could be less prone to be spurious matches. To take advantage of that, you need to perform some bookkeeping of things like the quality of matching over time or its agreement with estimated motion, which you can then use to decide how much to trust the point.

Also see the KITTI odometry leaderboards for a list of algorithms that do very well at this task. The papers linked for those entries should give a good idea of the variation in how leading approaches go about this. Note that some of these use stereo vision, and others use laser data.


问:
What is inverse depth (in odometry) and why would I use it?
Reading some papers about visual odometry, many use inverse depth. Is it only the mathematical inverse of the depth (meaning 1/d) or does it represent something else. And what are the advantages of using it?</p>

答:
In addition to the reasons mentioned in other answers about the numerical conditioning of inverse depth, a major reason for this term to appear in specifically visual odometry literature is in the way that depths are computed from stereo vision: After rectification, 3D information is inferred from the distance in X between where a point appears in the two cameras' images.

Depth, $Z$, is then computed from disparity, $d$, as $Z=\frac{fB}{d}$, where $f$ and $B$ are focal length (in pixels) and camera baseline (in meters) respectively. So working in the space of inverse depths puts you also in the space of disparities, the quantity directly being estimated, and it becomes easier to work with distributions or errors in that quantity.


问:
How to obtain dense point clouds from stereo cameras?
I am trying to use a stereo camera for scene reconstruction, but I can usually only obtain sparse point clouds (i.e. over half the image does not have any proper depth information).

I realize that stereo processing algorithms rely on the presence of texture in the images and have a few parameters that can be tweaked to obtain better results, such as the disparity range or correlation window size. As much as I tune these parameters, though, I am never able to get results that are even remotely close to what can be obtained using an active sensor such as the Kinect.

The reason why I want that is because very often point clouds corresponding to adjacent regions don't have enough overlap for me to obtain a match, so reconstruction is severely impaired.

My question to the Computer Vision experts out there is the following: what can I do to obtain denser point clouds in general (without arbitrarily modifying my office environment)?

答:
Have a look at the KITTI Stereo Benchmark leaders. This benchmark penalizes algorithms for not producing a disparity at any given point, so the top performers produce dense outputs (even if they don't have much grounds for their estimate at many points). Some methods have publicly available code that is linked, which you can try out.

Note that they are not penalized for taking a long time, so many methods will take on the order of minutes per image to run and may not be suitable for your application. There have been many CNN-based methods introduced though that do very well, while still running in less than a second (on a GPU). At least one of these (CRL) has public code.

If you still don't get decent depth estimates with these on your images, then you may just be seeing the limits of what's feasible from a visible approach. There fundamentally needs to be distinctive texture in the area to be able to match points well, or you need a basis for making some strong assumptions (e.g.,  smoothness) in textureless regions.