答:
I know this is an old question but I will just add a bit to the currently existing answers. First, this is a very complex problem that everyone is trying to tackle, including google with their Tango project. In general, to localise indoor you either need to rely on your internal sensors, or get assistances from a indoor infrastructure deployed to assist you locating yourself.

Relying on onboard sensors:

Using sensors like LIDAR/Lasers, cameras, RGBD sensors, IMUs

Perform complex algorithmic sensor fusion to perform some sort of accurate iterative localisation. SLAM (Simultaneous Localisation and Map building) is commonly used. I previously developed a method called MRICP (Map Reference Iterative Closest Point) to perform a simple, but error prone localisation. Plenty of literature to look at on that front, including the recent monocular and stereoscopic visual odometry which is quite promising (check vi sensor from skybotix or svo).

Rely on infrastructure:

Beacons (bluetooth, ultraband, Wireless ...)

Mocap (motion capture cameras: vicon, visualeyez ...)

Encoded positioning in light bulbs (philips is recently experimenting with this)

In general it really depends on what accuracy you are trying to achieve. In mobile robotics, from my experience, you really need to focus on globally consistent maps, and locally accurate positioning. This means you need to roughly know where you are from a high-level topological manner (this room is connected to the other room on the left, vs the next room on the left is 2.323m away), but locally you should have an accurate position estimation (lasers + IMUs can do this accurately).

Hope this helps.

Title: Absolute positioning without GPS


问:
Electric Motor Speed Control - PWM vs analog voltage?
I'm working on a 2-wheeled robot and have connected up a raspberry pi to an L298N motor driver.

I'm sending the enable pin of a particular motor a software-generated PWM signal at 100Hz with a 50% duty cycle.  I observe with an osciloscope:

a fairly clean square wave going into the enable pin as expected.

a fairly dirty square wave across the output motor terminals.

The motor turns at about 50% speed/torque as expected.

I find myself wondering if it would be better to control the speed of the motor by placing a flat lower constant voltage across its terminals, rather than oscillating a square wave.  ie to do 50% speed/torque - instead of oscilating between 0V and 5V - just put a constant 2.5V across the motor terminals.  I wonder if the oscillation is a waste of power/energy.

Is this true?  Or doesn't it make any difference?  Do high-end motor drivers use a variable flat analog voltage to control speed/torque, or do they use a PWM?  If a PWM, does the frequency make any difference?

答:
Decades ago I saw some modified robots at a University laboratory - the motors used analogue control.

Computers used regular DAC chips to output analogue voltages, these were then amplified using some DIY kit audio amplifiers - effectively DC amplifiers as the input capacitors were removed, replaced by links.  The output of the amplifiers fed the motors directly.

However I think this was done simply because the parts were readily available at the time. The amplifiers had failry small heatsinks but needed split/bipolar power supplies, and these days the common PWM method perhaps using microcontrollers would be easier and cheaper.

ContentLicense: CC BY-SA 3.0


问:
PTAM CameraCalibrator error
I am trying to run the cameracalibrator.launch using PTAM according to this Camera Calibration tutorial. However, when I do so, I get the following error:

```<code>ERROR: cannot launch node of type [ptam/cameracalibrator]: can't locate node [cameracalibrator] in package [ptam]
</code>```

I source my devel/setup.bash before I run the code as well and it still does not work. Here is my launch file:

```<code><launch>
    <node name="cameracalibrator" pkg="ptam" type="cameracalibrator" clear_params="true" output="screen">
        <remap from="image_raw" to usb_cam/image_raw" />
        <remap from="pose" to="pose"/>
        <rosparam file="$(find ptam)/PtamFixParams.yaml"/>
    </node>
</launch>
</code>```

Here is what I get for rostopic list:

```<code>/rosout
/rosout_agg
/svo/dense_input
/svo/image
/svo/image/compressed
/svo/image/compressed/parameter_descriptions
...
/tf
/usb_cam/camera_info
/usb_cam/image_raw
/usb_cam/image_raw/compressed
...
/usb_cam/image_raw/theora
/usb_cam/image_raw/parameter_descriptions
/usb_cam/image_raw/parameter_updates
</code>```

The path where the cameracalibration.launch file is catkin_ws/src/ethzasl_ptam/ptam/launch.

I am not sure why this error keeps coming up because when I run roslaunch ptam cameracalibrator.launch, it says:

```<code>NODES
  /
    cameracalibrator (ptam/cameracalibrator)
</code>```

So I'm thinking that PTAM does include cameracalibrator. If someone could please point out my error, that would be really helpful. I've been using this post as a guide, but it's not been helping me much: Ros Dynamic Config file.

As it says in the above link, I tried find . -executable and I could not find cameracalibrator. I could only find the below. How do I proceed?

```<code>./include
./include/ptam
./cfg
...
./launch
./src
./src/ptam
./src/ptam/cfg
...
</code>```

答: Try to find the node by typing "rosrun ptam" and then hitting the tab key. If it doesn't show up there, most likely there's something wrong with your package path. I am surprised it works with the other launch file. Did you check the difference between the two launch files? From where (which directories) are you launching them?</p>

Title: PTAM CameraCalibrator error


问:
Gyroscope - How can I remove low frequency component with a high pass filter only?
I'm using Matlab to suppress low frequency components with a high pass filter.

Objective

Filter angular velocity measurements affected by high frequency noise and bias in order to get the best estimate of the angular position.

The output when the gyroscope is still looks like this.

First Approach

The easiest way to remove baseline is to remove the average and can be achieved with Matlab using one line of code.

```<code>yFilt = y - mean(y)
</code>```

Second Approach

We can design a high pass filter to attenuate low frequency components. If we analyze the frequency components of the signal we will see one peak at low frequency and "infinite" small components in all frequencies due to Noise. With a second order ButterWorth filter with normalized cutoff freq Wn = 0.2 we will get what we are looking for.

Filtered data

Tilting the Gyro

When we tilt the gyroscope the situation changes. With a sampling frequency of 300Hz we get the following plot.

The first half of the dft is shown below in a normalized scale.

You can find the sample.mat file here

The first approach works great. I would like to apply the second one to this particular case but here there are other low frequency components that make to job harder.

How can I apply the second approach based on the High Pass filter to remove the bias?

EDIT 1
You can find more information here

EDIT 2
How can we filter this signal to remove bias while keeping the angular velocity information (from 110-th to 300-th sample) intact?

If gyroscopes have the bias problem only when they are not experiencing any rotation, then the offset is present only in the first ~110 samples.

If the above hypothesis is correct, maybe if we apply high pass filtering only in the first 110 samples and desactivate the filter during rotations of the gyro, the estimated angular position will be more accurate.

答:
:UPDATED:

This is the last update I'm going to make to this answer because I feel like you are repeatedly redefining your question.

You have already designed a Butterworth filter that removes the DC offset, but your question title is "How can I remove low frequency component with a high pass filter". What is the problem you are having??

You ask, in what was the 5th edit of your question, but you call "Edit 2", how you can remove the bias while retaining the signal intact. If you have to do it with a filter (which I DO NOT RECOMMEND), then set the cutoff frequency of your filter an order of magnitude (one decade) below your lowest frequency of interest. Refer to a Bode plot of your filter to see how your filter will modify your signal.

I don't recommend a filter because a bias is called "bias" and not "noise". This is because a bias is a systematic error - a DC bias will exist in all samples, so you cannot "turn on" a filter when you think you are stationary and then "turn off" the filter when you think you are moving - the DC bias will exist in all signals. This is why I have suggested you calibrate your sensor, which is what you should be doing with every sensor you connect to your system anyways.

You have not provided any information about your testing or application, but if what you say at the end of the current version of your question is correct - maybe if we apply high pass filtering only in the first 110 samples and desactivate the filter during rotations of the gyro, the estimated angular position will be more accurate - then this would imply that you know, in advance, when the the gyro is rotating and when it is not. If this is the case, you can remove all of the DC bias accurately, with very little computational cost, by calculating the signal mean during periods when the gyro is stationary and subtracting that mean from the signal when the gyro is in motion.

As BendingUnit22 pointed out in the comments, the sample data set you have provided is not representative of the scenario in which you intend to use the filter, which is making it needlessly difficult for everyone trying to contribute to this problem to divine what you're after.

I have to assume your insistence on using a filter is academic because it is more difficult to implement, more computationally expensive, and more likely to skew the data you want to use.

:Original Content Below:

I've moved from a comment to an answer in the hopes that I might clarify/point out some problems you might be having.

Regarding the topics you did ask about:

A DC offset in a sensor like an accelerometer or a gyroscope is called a bias - it's the output of the sensor when the input is zero.

For devices like this, you actually would do a calibration process where you would use your line of code yFilt = y - mean(y), but you could more appropriately call it biasOffset = y - mean(y). Once you've done the initial calibration you store biasOffset in nonvolatile memory and use that to adjust future input samples.

Regarding the topics you didn't ask about:

Be careful using a high pass filter when your frequencies of interest are low. In your Figure 3, you have a close approximation of 3/4 of a sine wave starting at 110 seconds and running to 150 seconds. That is, it looks like your signal has a period of about (150-110)/(3/4) = 53.3 seconds, corresponding to a frequency of (1/53.3) = 0.0188 Hz, or 0.118 rad/s. Bear in mind that a filter's "cutoff" frequency doesn't actually cut off all frequency content above or below the designate frequency, but rather the cutoff frequency is generally the half-power (-3dB) point. Here's a decent discussion of filters (page 9) from a signal processing/aliasing perspective, but still worth reading. What I'm trying to say is that you could wind up significantly skewing your desired signal if you choose a cutoff frequency that is anywhere near (within an order of magnitude) of your desired signal frequency.

Be careful with units. You caught it! You changed the units on Figure 2 from $m/s^2$ to deg/s - it makes a big difference! Where last night it looked like your sensor was accelerating up to 335km/hr, now it looks like it's turning at 1rpm. That's a big difference!

:EDIT:
You have since changed the units on Figure 2 (x-axis) from seconds to samples, which, at 300Hz, means you've changed the time scale from 5 minutes to 1 second. Again, a huge difference, but now this means that your 3/4 sine wave-looking section occurs in 40 samples, not 40 seconds, which at 300Hz means it happens in 0.1333 seconds. Then, a full sine wave happens in a period of 0.1777 seconds, for a frequency of 5.6257Hz.

Note, however, that you are using normalized frequency on your last figure, and your signal frequency, 5.6257Hz, divided by your sampling frequency, 300Hz, gives you 0.0188. This again shows that the low frequency signal I'm assuming you're trying to eliminate is, in fact, the signal you want.

As a correction, I had previously stated that you didn't provide time data, but in fact you had provided sampling frequency, which means that you have indirectly provided time data, given the number of samples in the test data you provided.


问:
What are the reasons for not having autonomous robots in our daily activities?
The fact is that the more I search the less I find autonomous (real) robots in use. The companion robots are all toys with limited useless functionality. Whenever there is a natural disaster you don’t see operational search and rescue robots in the news. Even military robots in service are all remotely controlled machines. They are not intelligent machines. Industrial robotic arms are deterministic machines. The only robots with some levels of autonomous functionality are cleaning bots, warehouse operations bots and farming robots.

On the other hand, today:

the artificial intelligence algorithms are very good in making decisions

the sensing technologies are very sophisticated

the communication technologies are very fast

we can manufacture cheap parts

people are extremely gadget savvy

So, why there is no real robot in our day to day life? No investment in the domain? No market yet? Not enough knowledge in the domain? A missing technology? Any idea?

答:
First of all, everything is not as perfect as you think. A lot of algorithms (AI included) work well in theory, but in practice there are way too many ifs of unforeseen events. It happens so often that your algorithm works perfect in simulation and once you load it in a robot, it can't even go straight in a simple hallway.

That aside, I believe there are two main reasons:

Robots are expensive. You may have some cheap parts, but really, robots are expensive. In my lab, we took part in making robotic skins, and just that, for a human-sized robot is not cheap at all. It's cheap for an industrial robot, but I doubt you would want to pay thousands of dollars/euros for not-useless robot.

Robots are not safe. Not yet at least. If a small vacuum cleaner robot hits your leg, it won't hurt much. But if a humanoid robot crushes your hand during a hand-shake, well, no one likes to be responsible for that. Note that shortcomings of algorithms (for example sensor data processing, feature extraction and reasoning) are the main reason for this lack of safety.

So I believe, even though we are not too far from having robot friends among us, it's still too early for it.

Just to give you examples from real world:

The Nao robot, designed to be a companion (from Wikipedia) but actually mostly used for soccer games, costs about 16000$:

(source: about-robots.com)

The Enon robot, built to be a personal assistant, costs about 60000$:

The iCub humanoid costs 200000$:

(source: physorg.com)

ContentLicense: CC BY-SA 4.0


问:
EKF-SLAM initialize new landmark in covariance matrix
I am trying to implement an EKF-SLAM using the algorithm for unknown correspondences proposed in the book "Probalistic Robotics" by Sebastian Thrun in Table 10.2 .

By now I understand actually all of the algorithm except of the initialization of new landmarks in the covariance matrix $ P_{new} $.

In that algorithm when a new landmark is detected the procedure is just the same as if a normal measurment update for an already observed landmark is done: the Kalman gain $ K $ is calculated for the new landmark and then the covariance is updated with that Kalman gain and the jacobian $ H $ of that new landmark like this $ P_{new}=  (I  -  K * H) * P$ .

In my understanding a just new observed landmark would not have any effect on the rows and columns that correspond to already mapped landmarks or the robot pose in the covariance matrix. Instead I think that just two rows and columns for x and y should be created with some uncertainity like proposed here: the uncertainty of initializing new landmark in EKF-SLAM .

I tried to split down the calculation of $ P_{new}$ via claculating it blockwise to see if I could somehow come to the same initialization as shown in the link above. But I end up having a different covariance matrix where apparently the new landmark is effecting the rows and columns of the parts of the old covariance, which in my view can't be right.

I hope I don't understand the pseudo code of the book wrong or I did a mistake in my try to come to the same initialization. Any advice how the initialization of new lnndmarks work in that code or if it actually is the same as in the link will be appreciated.

Edit

So basically what I am asking is: why would they do a normal Kalman update of the covariance matrix in line 24 of table 10.2 for a new observed landmark? Why is there no explicit case for the initialization of new rows/columns of new observed landmarks in the covariance matrix? It seems to me like they just do a normal measurement update even for a just newly observed landmark.

答: Unfortunately, the aforementioned book doesn't address initializing the uncertainty of a new landmark, however, it does address initializing the mean of a new landmark though (i.e. by using the inverse measurement function). In this link, the author addresses the issue. See 2.3.4 Landmark initialization for full observations in the pdf. The bottom line is that you should never ever touch the elements of the uncertainty matrix. The proper way to augment the uncertainty of a new landmark is addressed in the aforementioned pdf.


问:
Robot structure kit or materials
I have an arduino, wires, resistors, all of that good stuff. However, I don't have materials to build the structure of the robot. What do you guys recommend? I don't have a place to solder yet so I can't solder but is there a kit or material that you guys recommend? Will it work well with motors and other stuff? Thanks!

P.S. I plan on building a standard driving robot, but I want to be able to make other robots with the same materials/kit. I don't want a kit that only makes one robot, I want a Lego-esque approach to building the structure where I can build whatever I want with it. (Bump2)

答:
The Vex robotics platform has many structural pieces you can use to build a robot.  It is basically the same as an old school erector set.  It also contains motors and sensors that you could interface with your Arduino.

The most important part is that it has motor controllers so that you can control the motor.  With a standard Arduino you can not drive a motor directly because it would not be able to handle the current.

http://www.vexrobotics.com/vex/products/

Title: Robot structure kit or materials


答: I explained exactly how you can add the new row/columns to the covariance matrix in this answer.</p>

Title: EKF-SLAM initialize new landmark in covariance matrix

Body:
I am trying to implement an EKF-SLAM using the algorithm for unknown correspondences proposed in the book "Probalistic Robotics" by Sebastian Thrun in Table 10.2 .

By now I understand actually all of the algorithm except of the initialization of new landmarks in the covariance matrix $ P_{new} $.

In that algorithm when a new landmark is detected the procedure is just the same as if a normal measurment update for an already observed landmark is done: the Kalman gain $ K $ is calculated for the new landmark and then the covariance is updated with that Kalman gain and the jacobian $ H $ of that new landmark like this $ P_{new}=  (I  -  K * H) * P$ .

In my understanding a just new observed landmark would not have any effect on the rows and columns that correspond to already mapped landmarks or the robot pose in the covariance matrix. Instead I think that just two rows and columns for x and y should be created with some uncertainity like proposed here: the uncertainty of initializing new landmark in EKF-SLAM .

I tried to split down the calculation of $ P_{new}$ via claculating it blockwise to see if I could somehow come to the same initialization as shown in the link above. But I end up having a different covariance matrix where apparently the new landmark is effecting the rows and columns of the parts of the old covariance, which in my view can't be right.

I hope I don't understand the pseudo code of the book wrong or I did a mistake in my try to come to the same initialization. Any advice how the initialization of new lnndmarks work in that code or if it actually is the same as in the link will be appreciated.

Edit

So basically what I am asking is: why would they do a normal Kalman update of the covariance matrix in line 24 of table 10.2 for a new observed landmark? Why is there no explicit case for the initialization of new rows/columns of new observed landmarks in the covariance matrix? It seems to me like they just do a normal measurement update even for a just newly observed landmark.


答:
You are partly right, in thinking that high end Motor drives use a better method. But those methods may not be suitable in your small robot application, just because, to get that ease of control with power, you would need more power electronics(- because the circuit necessarily need to have fine control over current/voltage characteristics, plus feedback of output speed and torque).

With PWM, you always have this control, as you can employ duty cycles varying from 1 to 99 to output varying drive behavior. If for instance, you were using an analogue control, (12Volts)
1. the circuit needs to have fine control over voltage, which increases circuit complexity.
2. the feedback needs be there to ensure the voltage fed is at par with poer needed.
...and I always prefer PWM, because, it gives finer control without adding much complex electronics, and keeping the fed voltage constant.
Hope this helps

Title: Electric Motor Speed Control - PWM vs analog voltage?

Body:
I'm working on a 2-wheeled robot and have connected up a raspberry pi to an L298N motor driver.

I'm sending the enable pin of a particular motor a software-generated PWM signal at 100Hz with a 50% duty cycle.  I observe with an osciloscope:

a fairly clean square wave going into the enable pin as expected.

a fairly dirty square wave across the output motor terminals.

The motor turns at about 50% speed/torque as expected.

I find myself wondering if it would be better to control the speed of the motor by placing a flat lower constant voltage across its terminals, rather than oscillating a square wave.  ie to do 50% speed/torque - instead of oscilating between 0V and 5V - just put a constant 2.5V across the motor terminals.  I wonder if the oscillation is a waste of power/energy.

Is this true?  Or doesn't it make any difference?  Do high-end motor drivers use a variable flat analog voltage to control speed/torque, or do they use a PWM?  If a PWM, does the frequency make any difference?


问:
Displacement with accelerometer
I want to use a sensor to find displacement with accelerometer.
How can I use accelerometer to find displacement? I want to use this for a quadcopter.</p>

答:
I want to use a sensor to find displacement with accelerometer

An accelerometer is a sensor.

How can I use accelerometer to find displacement?

By integrating twice, because acceleration is defined as the second derivative of position.

In a numerical calculation, in every step add the new value from the accelerometer to a sum (that's velocity) and add that sum to another sum, which will be the position. Also, the acceleration and velocity must both be multiplied by the change in time before summing.

```<code>velocity += acceleration*dt
position += velocity*dt
</code>```

Title: Displacement with accelerometer

Body:
I want to use a sensor to find displacement with accelerometer

An accelerometer is a sensor.

How can I use accelerometer to find displacement?

By integrating twice, because acceleration is defined as the second derivative of position.

In a numerical calculation, in every step add the new value from the accelerometer to a sum (that's velocity) and add that sum to another sum, which will be the position. Also, the acceleration and velocity must both be multiplied by the change in time before summing.

velocity += acceleration*dt
position += velocity*dt


问:
The relationship between point cloud maps and graph maps
I am most familiar with SLAM maps that are point clouds, usually in the form of a vector like $<x,y,\theta,f_{1x},f_{1y},...,f_{nx},f_{ny}>$.  I also understand how to create a map like this using an EKF.

Today I came across a .graph file format, which as you would expect consists of vertices and edges in the format:

VERTEX2 id x y orientation

EDGE2 observed_vertex_id observing_vertex_id forward sideward rotate inf_ff inf_fs inf_ss inf_rr inf_fr inf_sr

I know that there's a connection between matrices and graphs (an adjacency matrix for example).  But it's not clear to me how this graph format of a map is equivalent to a point cloud map that I'm familiar with.

What is the relationship?  Are the vertices both poses and landmarks? Are they in a global reference frame? How is this created from say velocity information and a range/bearing sensor?  Is there a transformation between a graph map and a point cloud?

答:
There's a forum post with some more clarifying information on the format. It looks like the graph node values are initial estimates of self-poses, and edges encode pose constraints as represented by the information filter, the dual of the Kalman filter.

From what I can tell, this map format includes only self-pose information and not landmarks, so there would not be a direct conversion from a point cloud map.


答:
This will depend on what you mean by "displacement" and for how long you want to do this.  Can you supply more details on what your trying to accomplish and why?

As Bending Unit 22 mentioned, you integrate acceleration to get velocity, and then integrate velocity to get position.  The problem with this though that any drift/error/noise on the accelerometer gets doubled integrated and your positional error will grow quadratically, so there is a good chance you'll need additional sensors to correct for this error.  Whether this error matters to you or how you want to compensate for this error will depend on what you're trying to do, providing more information would be helpful!

Title: Displacement with accelerometer

Body:
I want to use a sensor to find displacement with accelerometer.
How can I use accelerometer to find displacement? I want to use this for a quadcopter.</p>


问:
Deciding length of quadcopter arms
How quadcopter's arm length affect stability?

As per my view I'll have better control on copter with longer arms but with stresses in arms and also it doesn't affect lift capabilities.

答:
For the most part, it will increase the gain of the controller.

doesn't affect lift capabilities.

Adding weight to something that flies always decreases lift capabilities. However, this influence is likely very small.

So here's your quadrocopter with 1 DOF rotating around an axis:

$$a\ddot r + b\dot r + c r$$

The general differential equation1 for a mechanical system. $r$ is the angle of rotation and $a$, $b$ and $c$ are coefficients describing the system.

You have probably concluded by now that 1this was a blatant lie, for the obvious lack of the other side of the equal sign. that missing side is the load that you apply. This is usually in the form of rotors, producing thrust. For simplicities sake let's assume that this can be modelled as a force $f$. This force is applied at a distance from the center of rotation and that's where the arm length $l$ comes into play:

$$a\ddot r + b\dot r + c r = l f$$

Transforming into...

$$as^2 R + bsR + cR = l F$$

getting the transfer function of the system that we are interested in:
$$\frac{R}{F}= \frac{l}{as^2 + bs + c}$$

$\frac{R}{F}$ can be understood as "if I add this much $f$, how much $r$ do I get back?" $l$ is basically the gain. It is a constant factor, written a little differently, this becomes more obvious:

$$\frac{R}{F}= l\cdot\frac{1}{as^2 + bs + c}$$

How much $r$ do I get back? Can be answered as "$l$ times something". With a bigger $l$ you get more bang for your buck (or more rotation for your force respectively). Which means your motors don't have to go to 11 all the time.

But what about stability? Stability can be determined from the roots of the denominator, called poles. The question essentially is how does $l$ influence
$a$, $b$ and $c$ and how does that affect stability?

a - moment of inertia: While it's unclear how the mass is distributed in the system, one can assume that, based on the general formula, $l$ has a quadratic influence on a, that is $a = a(l^2)$ That means increasing $l$ will increase $a$ a lot

b - damping: This is hard to estimate. I guess most of the damping in the system comes from wind resistance. Increasing $l$ will only add little surface to the copter, hence wind resistance will not increase much (if at all). I conclude that $l$ has little to no influence on $b$

c - spring coefficient: there's certainly an influence, but you want to keep that as minimal as possible by design, because you want to make the arms as stiff as possible. Nobody likes wobbly structures.

Now where are the poles?

$$s_{1/2} = -\frac{b}{2a} \pm\frac{\sqrt{b^2-4ac}}{2a}$$

The important part for stability is that $s_{1/2}$ has a negative real part. Increasing $a$ due to increasing $l$ certainly reduces the negativity of the term, but it will not change it to be positive.

The conclusion of this very rough estimation is that the system will not become unstable when the arm length is increased.

Of course, this is a very handwavy estimate without knowing any of the actual values. If you want more, go right ahead (<- 3 links)

Quadrocopters are a popular topic not just by enthusiast but also academia, so you find a lot of papers about it, giving more insights on more detailed models of the system.

I think the rough estimate given in this answer is sufficient to explain the influences of the length of the arm.

Title: Deciding length of quadcopter arms


问:
Implementing a boustrophedon algorithm in a given room with obstacles
I have a mobile robot which is navigating around a room, I already have the map of the room. I am using the navigation_stack of ROS. I am using rotary encoders for odometry. I am fusing the data from Rotary encoders and IMU using robot_pose_ekf. I am using amcl for localization and move_base for planning.

Now, I have to write a Complete coverage Path planning algorithm and I am following this paper and I would like to ask what is the best way to generate the Boustrophedon path (simple forward and backward motions) in a cell (can be rectangular, trapezium, etc.) with no obstacles? I read a paper where they use different templates and combine them in a certain way to come up with the Boustrophedon path. Is there any other way by which we can generate the boustrophedon path? If someone can suggest how to implement it in ROS, that will be great.

Please let me know if you need more information from me. Any help will be appreciated.

答:
I implemented something like this in College:

https://github.com/Auburn-Automow/au_automow_common/tree/master/automow_planning

Basically we just passed the vertices of the boustrophedon path as goals to move_base. Here's a video of a bag file being played back:

https://www.youtube.com/watch?v=R7nLgYquECg

Here's the class paper we did for the planner:

https://github.com/ashgti/elect6350/tree/master/final_project

Maybe something in there will give you some ideas. In our case we didn't need to do much cell decomposition in the competition, and instead we relied on the obstacle avoidance of move_base, but in our paper we did show our implementation working with more complex scenarios:

https://github.com/ashgti/elect6350/blob/master/final_project/images/obstacle.pdf

The thing I took away from the experience was that move_base is great for eventually getting from point A to point B and avoiding obstacles along the way, but it was very hard to tune it to follow the path our planner had come up with. As you can imagine when mowing grass you want to follow the path as closely as possible, diverging only when absolutely necessary to avoid obstacles. This was hard to accomplish with move_base.

So YMMV, but move_base is at least a starting place. Hopefully some of the stuff I linked will be useful. Good luck!


问:
Which sensor type most accurately measures position?
We're building an 6dof joystick, and we need to accurately measure the displacement of our central device. We can easily use a mechanical connection to the edges, but there has been some discussion about what the best way to achieve this is. The range of motion will be fairly small, but accuracy is incredibly important for us.

Which sensors are most easily and accurately measured?

My impulse response is that rotational and linear potentiometers are the most reliable, but others have been arguing for using gyros/accelerometers. I've also heard that hall effect sensors can be used to great effect.

答:
I have experience with potentiometers and hall effect sensors. Both are easy to use. I am not sure which one is more precise.

I have a robot hand using hall effect sensors to measure finger position. The advantage, compared with potentiometers, is compacter size and non-contact measurement.


问:
What device do I need to project a laser to point at a specific location?
I'm searching for a (commercial) projector that just projects a single laser point into the world (e.g. using two moving mirrors). However, I'm struggling because I'm not sure what such a thing is called. I either find area projectors that use lasers, party equipment or laser pointers. </p>

<p>What is the name for such a device? </p>

答:
The underlying mechanism used by high performance laser painting devices is usually a galvo (Galvanometer scanner, Laser Galvanometer or Mirror Galvanometer).

High performance galvos, like this one from scanlab are essential to the  laser micro-machining (drilling, cutting, marking) industries:

Their cost and performance may significantly exceed your requirements however. These are designed to position themselves in microseconds, to sub-micron (near field) accuracy.

I have no association with Scanlab, but I worked for many years in the laser micro-machining industry and they are the products I'm most familiar with.


答:
I would use linear or rotary encoders - the difference in terminology, encoder vs. potentiometer, is in the fact that any linear potentiometer could be used as a linear encoder, but not all linear encoders are potentiometers. From the Wikipedia article on linear encoders: Optical linear encoders, "following interpolation, can provide resolutions as fine as a nanometre."

I've worked on full-scale vehicle autonomy projects before, and I can say that, for the same cost, sealed (IP-67) linear potentiometers are far less expensive and easier to attach than are other forms of linear encoders, but you haven't commented on your application so I don't know if water resistance (or cost for that matter) makes a difference for you.

As a final note, there is typically a degree of temperature dependence in resistive elements, so again, be sure to take your expected operating conditions into account when making this selection. A resistive element can provide absolute position but will require a range calibration to correlate readings to position, but other forms of absolute linear position indicators typically do not. You may or may not need absolute position, but again, this all depends on your application.

Title: Which sensor type most accurately measures position?

Body:
We're building an 6dof joystick, and we need to accurately measure the displacement of our central device. We can easily use a mechanical connection to the edges, but there has been some discussion about what the best way to achieve this is. The range of motion will be fairly small, but accuracy is incredibly important for us.

Which sensors are most easily and accurately measured?

My impulse response is that rotational and linear potentiometers are the most reliable, but others have been arguing for using gyros/accelerometers. I've also heard that hall effect sensors can be used to great effect.


问:
How to detect when a stepper motor has stalled?
How can I detect when a stepper motor has stalled?

A google search led me to some people who say that
when the stepper motor stalls, the current spikes up,
which is easily detectable with a Hall sensor.
(Or, I suppose, by any of the other current sensors mentioned at
"How can I sense the motor's current?"
).

However, I measured the current through (one of the 4 wires of) my stepper motor,
and it's always within a few percent of 0.5 A, whether my stepper driver is holding one position, moving it normally (which in my application is very slowly), or the stepper driver thinks it is telling the stepper to move normally, but the motor has pegged out against the hard limit.
Measuring the current in the +12V power supply going to the stepper motor driver, also seemed to give a fairly constant current.
This may be because I turned down the current limit to that amount on my "chopper" stepper motor driver.

Am I missing some key detail in the "measure the current" approach?

A google search led me to some other people that measure the back-EMF (BEMF) in one coil of the stepper during the time the stepper driver is only driving the other coil.
But that only seems to distinguish between "a motor moving quickly" vs "a motor stopped", and doesn't seem to distinguish between my case of "a motor moving slowly" vs "a motor stopped".

Is there some way to apply the BEMF approach even in a system where I always drive the stepper slowly, and never spin it quickly?

I'm currently using a stepper driver board with the TI DRV8825 chip on it, and I hoped the "fault" pin would tell me when the stepper motor has stalled against my hard stop.
But it doesn't seem to be doing anything -- is it supposed to tell me about a stall, but I just have it wired up wrong?

Is there some other chip or drive technique that detects when the stepper has stalled out against the hard stop?

Is there some other technique for detecting a hard stall that I can "add on" to a system using an off-the-shelf stepper motor driver?

(Is there some other StackExchange site that is more appropriate for questions about motors and motor drivers?)

答: I found that the FFT of the current waveform of the stepper often shows the natural frequency harmonics of the motor+driver system AND that during a stall extra frequency harmonics appear!!! all you need is a fast, bidirectional current to voltage conversion IC and a narrow band pass filter to detect if the extra harmonics are present.</p>


问:
How to program a three wheel Omni?
I have created a three wheeled omni robot like the diagram below. Now I am unsure of how to program it. I want to use a single joystick so one x and one y value. The values for x and y are between -1 and 1, also the motors can be set anywhere from -1 to 1. How do I use this data to make the robot move based on the joystick without changing orientations? After doing some initial research this seems like a complex problem, but I am hoping there is a formula that I can.

答:
The math involved for controlling a holonomic robot is really not too bad.  It is basically just high-school trigonometry and knowing how to set up the problem.

First, lets start with the joystick.  I think the easiest way to deal with joysticks is to convert it's cartesian $(x,y)$ readings into polar $(r,\phi)$ coordinates.  This will allow us to control the holomonic robot much more naturally.

The polar coordinates are simply:
$$
\phi_{joy} = atan2(Y_{joy}, X_{joy})
$$
$$
r_{joy} = \sqrt{Y_{joy}^2 + X_{joy}^2}
$$

Now we can think of this as a vector, where the angle indicates the direction to move, and the length of the vector is the desired speed.

If we want full speed to be when the joystick is pushed straight forward, we have a little bit of a problem.  If the joystick is pushed diagonally, $r$ will be greater than when it is forward.  Basically $\sqrt{Y_{max}^2 + X_{max}^2} > Y_{max}$. This is because the joystick space is square, whereas we want a circular space.

There are a number of ways to compensate for this.  Some simple ways are to make diagonal full speed, but this isn't great because straight forward is not full speed anymore.  You could also simply cap the speed, but now your joystick has a large dead zone.  My preferred method is to adaptively scale $r$ depending on where it is in joystick space.  You need to extend the line of where the joystick is currently $(r,\phi)$, to the boundary of the space.  Let's call this $b$.

Computation of this length is simply a matter of a few conditionals (to determine which side of the square you intersect) and some more trigonometry.  This is left as an exercise for the reader.  Now the translational speed is:

$$
speed_t = maxspeed * r_{joy} / b
$$

Where $maxspeed$ is what ever you want the max translational velocity of your robot to be.  Note that your joystick units cancel out here.

Now to figure out the individual wheel speeds.  This procedure will work for any type of robot with omni-wheels.  (But not mecanum wheels.  Those are different).  3 wheels, 4 wheels, and even odd combinations with different radii from the robot center and wheel diameters.  As long as all the wheel axes converge at a single point.  But lets focus on 3 wheels as in your question.

First, number the wheels.

Then create a coordinate system.  (i.e. designate the front of your robot).  Now lets call the angle to each wheel axis.  $\alpha_1$, $\alpha_2$, and $\alpha_3$.

And lets set our convention to be positive motor speeds will make the robot spin clockwise.

Now we overlay our joystick vector on our robot.  We create a right triangle between the motor axis and the joystick vector.  For wheel 1, it will look like this:

Now wheel 1's speed ($M_1$) is simply the length of the line.  To get this quantity, we subtract the angles, then use $sin$.

$$
\theta_1 = \alpha_1 - \phi
$$
$$
M_1 = speed_t * sin(\theta_1)
$$

Note that this is actually the ground speed that the wheel should have.  So you will probably want to convert it into rotational velocity (rpm for example).  Use the equation for circle circumference, and keep your units straight.

And that's it.  Believe it or not, but the same equation works for all wheels.  This entire procedure is only for translating the robot.  If you want the robot to rotate too then you can simply add some rotation to all 3 motors.

Title: How to program a three wheel Omni?


问:
Kalman filter for estimating position with “direction” measurements
I am currently working on a pose estimation problem for which I would like to use filtering. To explain the system briefly, it consists of two cameras and each has its own GPS/IMU module. The main assumption is that Camera1 is fixed and stable, whereas camera2 has a noisy pose in 3D. I am using computer vision to obtain the pose (metric translation and rotation) of camera2 w.r.t. camera1, so that I can improve upon the inherent noise of GPS/IMU modules.

The problem here is that the translation obtained through the vision method is only up to an arbitrary scale, i.e. at any given instant, I can only obtain a unit vector that specifies the "direction" of the translation and not absolute metric translation. The camera based estimation, although accurate, has no idea about how much actual distance is between the cameras, which is why I have the GPS, which gives me position data with some noise.

Example: camera 2 is 5 m to the east of camera 1, the pose from my vision algorithm would say [1, 0, 0] ; 1 m north-east to camera 1, it would be something like [0.7, 0.7, 0]

Hence, would it be possible to consider the GPS estimate of the metric translation as well as its covariance ellipse, and somehow link it with the normalized camera measurements to obtain a final, more accurate estimate of metric translation? I am not sure what kind of filters would be happy to use a measurement that has no absolute value in it.

Thanks!

答:
First, a point of terminology - I believe when you say "direction" what you mean is what is commonly called a heading. That is, when you say "direction" what you mean is the angle between an arbitrary line from camera 1 (usually straight forward) and the line between camera 1 and camera 2.

Assume camera 2 starts at a known distance from camera 1 (sufficiently long for a good filtered GPS location, hand placed, etc.) and assume you know the initial heading.

Call the initial distance between camera 1 and camera 2 $a$.

Now camera 2 moves. Your IMU reports the distance traveled. Call this distance $b$.

Camera 1 reports the change in heading between the initial and second location, this is an angle (from the arc tangent of your camera 1 output). Call this angle $B$.

Now you have an $a$, a $b$, and a $B$. Use the Law of Sines to calculate the distance between camera 1 and camera 2 - this will be $c$.

You can now use a basic Kalman filter to filter the IMU distance output to get a better $b$, and thus a better $c$, and you can use another to combine this reading with your noisy GPS position. The method I've described should give you better short term results than the GPS, and the GPS should correct any drift caused by long term error accumulation.


问:
Complementary and Kalman filter don't work for Y angle
I'm working on a Python script which reads the data from the MPU6050 IMU and returns the angles using sensor fusion algorithms: Kalman and Complementary filter. Here is the implementation:
Class MPU6050 reads the data from the sensor, processes it. Class Kalman is the implementation of the Kalman filter. The problem is the next: None of the Kalman, neither the Complementary filter returns appropriate angle values from the Y angle. The filters work fine on the X angle, but the Y angle values make no sense. See the graphs below. I've checked the code million times, but still can't figure out where the problem is.

```<code>class MPU6050():
    def __init__(self):
        self.bus = smbus.SMBus(1)
        self.address = 0x68

        self.gyro_scale = 131.072 # 65535 / full scale range (2*250deg/s)
        self.accel_scale = 16384.0 #65535 / full scale range (2*2g)

        self.iterations = 2000

        self.data_list = array('B', [0,0,0,0,0,0,0,0,0,0,0,0,0,0])
        self.result_list = array('h', [0,0,0,0,0,0,0])

        self.gyro_x_angle = 0.0
        self.gyro_y_angle = 0.0
        self.gyro_z_angle = 0.0

        self.kalman_x = Kalman()
        self.kalman_y = Kalman()

    def init_sensor()...

    def calculate_angles(self):
        dt = 0.01

        comp_y = 0.0
        comp_x = 0.0
        print("Reading data...")

        while True:
            self.read_sensor_raw()

            gyro_x_scaled = (self.result_list[4] / self.gyro_scale)
            gyro_y_scaled = (self.result_list[5] / self.gyro_scale)
            gyro_z_scaled = (self.result_list[6] / self.gyro_scale)

            acc_x_scaled = (self.result_list[0] / self.accel_scale)
            acc_y_scaled = (self.result_list[1] / self.accel_scale)
            acc_z_scaled = (self.result_list[2] / self.accel_scale)

            acc_x_angle = math.degrees(math.atan2(acc_y_scaled, self.dist(acc_x_scaled,acc_z_scaled)))
            acc_y_angle = math.degrees(math.atan2(acc_x_scaled, self.dist(acc_y_scaled,acc_z_scaled)))

            comp_x = 0.95 * (comp_x + (gyro_x_scaled * dt)) + 0.05 * acc_x_angle
            comp_y = 0.95 * (comp_y + (gyro_y_scaled * dt)) + 0.05 * acc_y_angle

            kalman_y_angle = self.kalman_y.filter(acc_y_angle, gyro_y_scaled, dt)
            kalman_x_angle = self.kalman_x.filter(acc_x_angle, gyro_x_scaled, dt)

            self.gyro_x_angle += gyro_x_scaled * dt
            self.gyro_y_angle -= gyro_y_scaled * dt
            self.gyro_z_angle -= gyro_z_scaled * dt

            time.sleep(dt)

    def read_sensor_raw(self):
        self.data_list = self.bus.read_i2c_block_data(self.address, 0x3B, 14)

        for i in range(0, 14, 2):
            if(self.data_list[i] > 127):
                self.data_list[i] -= 256

            self.result_list[int(i/2)] = (self.data_list[i] << 8) + self.data_list[i+1]

    def dist(self, a,b):
        return math.sqrt((a*a)+(b*b))

class Kalman():
    def __init__(self):
     self.Q_angle = float(0.001)
     self.Q_bias = float(0.003)
    self.R_measure = float(0.03)

    self.angle = float(0.0)
    self.bias = float(0.0)
    self.rate = float(0.0)

    self.P00 = float(0.0)
    self.P01 = float(0.0)
    self.P10 = float(0.0)
    self.P11 = float(0.0)

def filter(self, angle, rate, dt):
    self.rate = rate - self.bias
    self.angle += dt * self.rate

    self.P00 += dt * (dt * self.P11 - self.P01 - self.P10 + self.Q_angle)
    self.P01 -= dt * self.P11
    self.P10 -= dt * self.P11
    self.P11 += self.Q_bias * dt

    S = float(self.P00 + self.R_measure)

    K0 = float(0.0)
    K1 = float(0.0)
    K0 = self.P00 / S
    K1 = self.P10 / S

    y = float(angle - self.angle)

    self.angle += K0 * y
    self.bias += K1 * y

    P00_temp = self.P00
    P01_temp = self.P01

    self.P00 -= K0 * P00_temp
    self.P01 -= K0 * P01_temp
    self.P10 -= K1 * P00_temp
    self.P11 -= K1 * P01_temp

    return self.angle
</code>```

EDIT:
I've added some information based on @Chuck's answer:

self.result_list[3] contains the temperature

In my opinion the compl. filter is implemented correctly: gyro_x_scaled and gyro_y_scaled are angular velocities, but they are multiplied by dt, so they give angle. acc_?_scaled are accelerations, but acc_x_angle and acc_x_angle are angles. Check my comment, where the Complementary filter tutorial is.

Yes, there was something missing in the Kalman filer, I've corrected it.

I totally agree with you, sleep(dt) is not the best solution. I've measured how much time the calculation takes, and it is about 0.003 seconds. The Y angle filters return incorrect values, even if sleep(0.007) or sleep(calculatedTimeDifference) is used.

The Y angle filters still return incorrect values.

答:
I've never used Python before in my life, but I'm a Matlab wizard and an engineer, so I'll just go through point-by-point and highlight things that look questionable to me.

What is self.result_list[3]? The linear accelerations are 0-2, are you sure you meant to skip 3? Gyro accelerations are 4-6.

I see what you're doing using linear accelerations to generate a rotational acceleration,  but keep in mind that technique will only generate valid output if there is no true linear acceleration.

Your comp_ calculation leaves off a dt at the end. I'm assuming you want that to be angular velocity, but you are multiplying sample time to only the gyro acceleration and not the accel term - you are adding a velocity and an acceleration and using that as one term.

Your Kalman filter doesn't update its covariance matrix correctly. The code to which you linked uses tempP00 and tempP01 to update P00, P01, P10, and P11. You do not, so you are changing P00 and P01 first, then using those new values to update P10 and P11. Refer to step 7 on the site you linked.

I would caution against using a dedicated sample time variable like your dt in conjuction with sleep. Your loop polls the sensor and does some calculations, all of which requires time. Say that time is 1ms, and your sample time variable is 10ms (0.01s). Because you pause/sleep for 0.01s and THEN do 1ms of communication and processing, your ACTUAL sample time (time between samples) is 11ms, so the sample time you're using for filtering and numeric integration is off by 10%. It's much better to use an interrupt to time sampling than a sleep command. Here it may not be such an issue, but in the future, with longer code or code with logic that has a variable execution time on a per-sample basis, it could have a bigger impact.

As mentioned I'm no Python user so I can't comment regarding your syntax or execution otherwise.


答:
I've found the answer: a minus sign is needed here: gyro_y_scaled = - (self.result_list[5] / self.gyro_scale).

Explanation: gyro_y_scaled is the velocity in rad/sec. If you check the code, especially lines 29-31 on this page, you can see, there is a minus sign before math.degrees(radians), but my implementation has no minus sign before math.degrees(math.atan2(acc_x_scaled, self.dist(acc_y_scaled,acc_z_scaled))). In addition, self.gyro_y_angle -= gyro_y_scaled * dt, there is also minus sign instead of plus. To sum up, the velocity and the angles, mentioned above, had "opposite" values and this is why the filters didn't work.

Title: Complementary and Kalman filter don't work for Y angle

Body:
I'm working on a Python script which reads the data from the MPU6050 IMU and returns the angles using sensor fusion algorithms: Kalman and Complementary filter. Here is the implementation:
Class MPU6050 reads the data from the sensor, processes it. Class Kalman is the implementation of the Kalman filter. The problem is the next: None of the Kalman, neither the Complementary filter returns appropriate angle values from the Y angle. The filters work fine on the X angle, but the Y angle values make no sense. See the graphs below. I've checked the code million times, but still can't figure out where the problem is.

```<code>class MPU6050():
    def __init__(self):
        self.bus = smbus.SMBus(1)
        self.address = 0x68

        self.gyro_scale = 131.072 # 65535 / full scale range (2*250deg/s)
        self.accel_scale = 16384.0 #65535 / full scale range (2*2g)

        self.iterations = 2000

        self.data_list = array('B', [0,0,0,0,0,0,0,0,0,0,0,0,0,0])
        self.result_list = array('h', [0,0,0,0,0,0,0])

        self.gyro_x_angle = 0.0
        self.gyro_y_angle = 0.0
        self.gyro_z_angle = 0.0

        self.kalman_x = Kalman()
        self.kalman_y = Kalman()

    def init_sensor()...

    def calculate_angles(self):
        dt = 0.01

        comp_y = 0.0
        comp_x = 0.0
        print("Reading data...")

        while True:
            self.read_sensor_raw()

            gyro_x_scaled = (self.result_list[4] / self.gyro_scale)
            gyro_y_scaled = (self.result_list[5] / self.gyro_scale)
            gyro_z_scaled = (self.result_list[6] / self.gyro_scale)

            acc_x_scaled = (self.result_list[0] / self.accel_scale)
            acc_y_scaled = (self.result_list[1] / self.accel_scale)
            acc_z_scaled = (self.result_list[2] / self.accel_scale)

            acc_x_angle = math.degrees(math.atan2(acc_y_scaled, self.dist(acc_x_scaled,acc_z_scaled)))
            acc_y_angle = math.degrees(math.atan2(acc_x_scaled, self.dist(acc_y_scaled,acc_z_scaled)))

            comp_x = 0.95 * (comp_x + (gyro_x_scaled * dt)) + 0.05 * acc_x_angle
            comp_y = 0.95 * (comp_y + (gyro_y_scaled * dt)) + 0.05 * acc_y_angle

            kalman_y_angle = self.kalman_y.filter(acc_y_angle, gyro_y_scaled, dt)
            kalman_x_angle = self.kalman_x.filter(acc_x_angle, gyro_x_scaled, dt)

            self.gyro_x_angle += gyro_x_scaled * dt
            self.gyro_y_angle -= gyro_y_scaled * dt
            self.gyro_z_angle -= gyro_z_scaled * dt

            time.sleep(dt)

    def read_sensor_raw(self):
        self.data_list = self.bus.read_i2c_block_data(self.address, 0x3B, 14)

        for i in range(0, 14, 2):
            if(self.data_list[i] > 127):
                self.data_list[i] -= 256

            self.result_list[int(i/2)] = (self.data_list[i] << 8) + self.data_list[i+1]

    def dist(self, a,b):
        return math.sqrt((a*a)+(b*b))

class Kalman():
    def __init__(self):
     self.Q_angle = float(0.001)
     self.Q_bias = float(0.003)
    self.R_measure = float(0.03)

    self.angle = float(0.0)
    self.bias = float(0.0)
    self.rate = float(0.0)

    self.P00 = float(0.0)
    self.P01 = float(0.0)
    self.P10 = float(0.0)
    self.P11 = float(0.0)

def filter(self, angle, rate, dt):
    self.rate = rate - self.bias
    self.angle += dt * self.rate

    self.P00 += dt * (dt * self.P11 - self.P01 - self.P10 + self.Q_angle)
    self.P01 -= dt * self.P11
    self.P10 -= dt * self.P11
    self.P11 += self.Q_bias * dt

    S = float(self.P00 + self.R_measure)

    K0 = float(0.0)
    K1 = float(0.0)
    K0 = self.P00 / S
    K1 = self.P10 / S

    y = float(angle - self.angle)

    self.angle += K0 * y
    self.bias += K1 * y

    P00_temp = self.P00
    P01_temp = self.P01

    self.P00 -= K0 * P00_temp
    self.P01 -= K0 * P01_temp
    self.P10 -= K1 * P00_temp
    self.P11 -= K1 * P01_temp

    return self.angle
</code>```

EDIT:
I've added some information based on @Chuck's answer:

self.result_list[3] contains the temperature

In my opinion the compl. filter is implemented correctly: gyro_x_scaled and gyro_y_scaled are angular velocities, but they are multiplied by dt, so they give angle. acc_?_scaled are accelerations, but acc_x_angle and acc_x_angle are angles. Check my comment, where the Complementary filter tutorial is.

Yes, there was something missing in the Kalman filer, I've corrected it.

I totally agree with you, sleep(dt) is not the best solution. I've measured how much time the calculation takes, and it is about 0.003 seconds. The Y angle filters return incorrect values, even if sleep(0.007) or sleep(calculatedTimeDifference) is used.

The Y angle filters still return incorrect values.


问:
Would ROS benefit from a multicore processor like Epiphany or XMOS?
I am looking for a good embedded PC to run ROS on. I recently came across a couple of little machines using new very multi-core processors, such as the Epiphany and the XMOS.

Since the one thing that ROS really seems to want is cores, would ROS be able to take advantage of all of these cores? Or are they all just too feeble with too little RAM to be of any use?

Would it make more sense to focus on machines with fewer, more powerful cores?

答:
Short answer; it depends.

ROS is a framework that can support multiple cores, but it is up to the ROS modules themselves to thrive in a multi-core environment. You can NOT expect ROS to automatically use all the cores, but if your software is written in a way that they can be used, then ROS will accommodate them.

A little generic history; There was a way that program processes used to talk to each other within a computer. Soon that grew into a method where those process could communicate within the same computer or on to a physically separate computer. And then high efficiency versions of that became the basis for ROS and Microsoft RDS. Microsoft found the project so successful they merged it with an existing technology SOAP, and developed WCF. The part you probably do not know is that WCF is being implemented as a processor to processor and/or sub-processor communication protocol on the hardware bus (with strong focus on robotic potential). The point is, that the message switching architectures pioneered by ROS and MRDS are super robust to the point where something similar will probably power hardware a generation or 2 from now.

Yes, by all means, use multi-core as much as possible. If you write code today that doesn't consider async and multi-core you might as well choose a different career path. There is little difference to writing well for 4 heavy cores, or 2000 small ones. Some difference, but if you know how to do one, you probably understand how to do the other as well.


问:
Are there off the shelf solutions for GPS+INS (accelerometer,gyro,magneto) sensor fusion for getting filtered/fused location and speed output?
I am working on a project that needs tracking location and speed of pedestrians/runners/athletes (so not really robotics, but I see a lot of related usage and posts in the robotics domain, and an answer to this question could help with follower robots). I'm interested in just the 2D location (latitude-longitude).

Using just the GPS position has noisy/jump samples and also the degradation due to multi-path near trees etc. From reading about filtering solutions, I understand that sensor fusion that fuses GPS with the data from inertial sensors (INS) helps improve a lot of these issues. Also, this kind of sensor fusion seems to be used in a lot of places -- robotics, wearables, drones etc. Hence I think there might be off the shelf chips/modules/solutions for this, but I couldn't find any.

I found a sensor hub from Invensense that integrates the 9 dof inertial sensors and comes with the fusion firmware, but it doesn't seem to have hookups and firmware for fusing GPS and providing filtered latitude-logitude.

So, what should I be looking for? Are there any off the shelf chips/modules/solutions that come with the built in sensor fusion Software/firmware for doing GPS+INS fusion?

I understand that it will still need tuning some params as well as some calibration.

答:
There are many GPS+INS fusion units available on the market. The price, weight and size of the units can vary dramatically depending on the GPS positioning accuracy and rate of drift from the INS. The choice of GPS+INS sensor really depends on the requirements of your application.

From my own experience, Xsens (https://www.xsens.com) make lightweight version that is the size of a matchbox. This is suitable for lightweight robotics applications or human tracking. Their units can also contain barometers and magnetometers for improved position accuracy. However without a good GPS signal, the INS will quickly drift away from the true location so can be problematic when used indoors or in built-up areas.

For a low cost option, it might also be worth looking at what cellphones can provide for your application as as they already contain  GPS, INS, Magnetometers, Barometers, Wifi positioning and cellphone positioning.


问:
GraphSLAM: why are constraints imposed twice in the information matrix?
I was watching Sebastian Thrun's video course on AI for robotics (freely available on udacity.com).  In his final chapter on GraphSLAM, he illustrates how to setup the system of equations for the mean path locations $x_i$ and landmark locations $L_j$.

To setup the matrix system, he imposes each robot motion and landmark measurement constraint twice.  For example, if a robot motion command is to move from x1 by 5 units to the right (reaching x2), i understand this constraint as

$$-x_2+x_1= -5$$

However, he also imposes the negative of this equation
$$x_2-x_1=5$$
as a constraint and superimposes it onto a different equation and i'm not sure why.  In his video course, he briefly mentions that the matrix we're assembling is known as the "information matrix", but i have no why the information matrix is assembled in this specific way.

So, I tried to read his book Probabilistic Robotics, and all i can gather is that these equations come from obtaining the minimizer of the negative log posterior probability incorporating the motion commands, measurements, and map correspondences, which results in a quadratic function of the unknown variables $L_j$ and $x_i$.  Since it is quadratic (and the motion / measurement models are also linear), the minimum is obviously obtained by solving a linear system of equations.

But why are each of the constraints imposed twice, with once as a positive quantity and again as the negative of the same equation?  Its not immediately obvious to me from the form of the negative log posterior probability (i.e. the quadratic function) that the constraints must be imposed twice.  Why is the "information matrix assembled this way?  Does it also hold true when the motion and measurement models are nonlinear?

Any help would be greatly appreciated.

答:
After painstakingly trying to find someone on the internet with more experience on this subject to help me out (to no avail), I finally gave up and decided to take matters into my own hands and figure it out myself!   As it turns out, the constraints are imposed twice as a direct result of applying the chain rule for derivatives when obtaining the gradient of the negative log posterior belief function equal to zero (which is equivalent to finding the maximum of the belief).

Unfortunately, there's no easy way to demonstrate this other than going through the math one step at a time.

Problem Setup

To help explain, let me setup an example to work with.  For simplicity, lets assume that the robot moves in only on direction (in this case, the x-direction).  In one dimension, the covariance matrices for motion and sensor data are simply the variances $\sigma^2_{motion}$ and $\sigma^2_{sensor}$.  Again, for simplicity, let's assume that $\sigma^2_{motion}=\sigma^2_{sensor}=1$.

Now, let's assume that the robot starts at the point $x_0=0$ and then executes two motion commands in this following order:

Move forward by 10 units ($x_1 = x_0 + 10$)

Move forward by 14 units ($x_2 = x_1 + 14$)

Let's also assume that the robot world only contains one landmark $L_0$ which lies somewhere in the 1D world of the robot's motion.  Suppose that the robot senses the following distances to the landmark from each of the three positions $x_0, x_1, x_2$:

At $x_0$:  The robot sensed Landmark $L_0$ at a distance of 9 units ($L_0-x_0=9$)

At $x_1$:  The robot sensed Landmark $L_0$ at a distance of 8 units ($L_0-x_1=8$)

At $x_2$:  The robot sensed Landmark $L_0$ at a distance of 21 units ($L_0-x_1=8$)

(These numbers may look a little strange, but just take them as a given for this exercise).

Belief Function

So, each of the relative motion and measurement constraints contributes a Gaussian function to the "posterior belief" function.  So, with the information assumed above, we can write the belief function as the product of gaussians as follows:

$$Belief = C e^{-\frac{(x_0-0)^2}{2\sigma^2}}e^{-\frac{(x_1-x_0-10)^2}{2\sigma^2}}e^{-\frac{(x_2-x_1-14)^2}{2\sigma^2}} * e^{-\frac{(L_0-x_0-9)^2}{2\sigma^2}}e^{-\frac{(L_0-x_1-8)^2}{2\sigma^2}}e^{-\frac{(L_0-x_2-21)^2}{2\sigma^2}}$$

Note that $C$ is a constant, but we won't really need to know the exact value of $C$.  Recall that we assume all the variances $\sigma^2=1$, so we obtain

$$Belief = C e^{-\frac{(x_0-0)^2}{2}}e^{-\frac{(x_1-x_0-10)^2}{2}}e^{-\frac{(x_2-x_1-14)^2}{2}} * e^{-\frac{(L_0-x_0-9)^2}{2}}e^{-\frac{(L_0-x_1-8)^2}{2}}e^{-\frac{(L_0-x_2-21)^2}{2}}$$

Negative Log Posterior

Our main goal is to find the values of $x_0,x_1,x_2,L_0$ that maximize this function.  However, we can make some transformations to the "belief" function that enable us to find the maximum very easily.  First, finding the maximum of the $Belief$ is equivalent to finding the maximum of $log(Belief)$, which allows us to exploit the properties of logarithms which gives us:

$$log(Belief)= log(C) - \frac{1}{2}(x_0-0)^2-\frac{1}{2}(x_1-x_0-10)^2-\frac{1}{2}(x_2-x_1-14)^2 -\frac{1}{2}(L_0-x_0-9)^2-\frac{1}{2}(L_0-x_1-8)^2-\frac{1}{2}(L_0-x_2-21)^2$$

Also, finding the maximum of a function $f(x)$ is equivalent to finding the minimum of the function $-f(x)$.  So we can restate this problem as finding the minimum of

$$F\equiv-log(Belief)= -log(C) + \frac{1}{2}(x_0-0)^2+\frac{1}{2}(x_1-x_0-10)^2+\frac{1}{2}(x_2-x_1-14)^2 +\frac{1}{2}(L_0-x_0-9)^2+\frac{1}{2}(L_0-x_1-8)^2+\frac{1}{2}(L_0-x_2-21)^2$$

Optimization

To find the minimum, we take the partial derivative of the $F$ function with respect to each of the variables: $x_0, x_1, x_2,$ and $L_0$:

$F_{x_0}= (x_0 - 0) - (x_1 - x_0 - 10) - (L_0-x_0-9) = 0$

$F_{x_1}= (x_1 - x_0 - 10) - (x_2-x_1-14)- (L_0-x_1-8) = 0$
$F_{x_2}= (x_2 - x_1 - 14) - (L_0-x_2-21) = 0$

$F_{L_0}= (L_0-x_0-9) + (L_0-x_1-8)+ (L_0-x_2-21) = 0$

Notice that the 1st and second equations impose the first relative motion constraint $x_1=x_0+10$ twice: the first equation with a negative sign as a result of the chain rule for derivatives and the second equation with a positive sign (also as a result of the chain rule).  Similarly, the second and third equation contain the second relative motion constraint, with opposite signs as a result of applying the chain rule for derivatives.  A similar argument can be said for the measurement constraints in their corresponding equations.  There's no inherent explanation for why it MUST necessarily work out this way... It just happens to have this structure in the end after working out the math.  You may notice that only the initial position constraint $(x_0-0)$ is imposed only once because its quadratic term $\frac{1}{2}(x_0-0)^2$ only features a single variable inside the parentheses, so it is impossible for this term to appear in the gradient of $F$ with respect to any other variable other than $x_0$.

Conclusion

It was not apparent to me just by looking at the structure of the belief function that the gradient takes on this form without working through the details explicitly.  Of course, I've made a number of simplifying assumptions along the way, including avoiding the problem of "data association" and assuming linear expressions for the motion constraints and measurement constraints.  In the more general version of GraphSLAM, we do not necessarily assume this and the algorithm becomes more complicated.  But in the linear case (that is, with linear motion and measurement constraints), the gradients of the negative log posterior belief function leads to imposing the motion and measurement constraints twice (once with a positive sign, once with a negative sign), each of which is also weighted by the corresponding covariance.  There appears to be no inherent or more fundamental reason why it must necessarily work out this way based upon higher principles... It's just a bunch of trivial calculus that happens to work out this structured way.


问:
Can ROS run on a Raspberry Pi?
Can ROS run on a Raspberry Pi?

ROS is resigned to run on a network of machines, with different machines, even different cores on the same machine doing different jobs. Can one of those machines be a Raspberry Pi?

I am considering using an R-Pi as the EtherCAT master on a mobile robot, communicating with the main PC over WiFi, using a dongle.

Can an R-Pi even run ROS at all?

Would an R-Pi have enough processing power to do some 1kHz servoing?

Would it be possible to run some servoing on the host through the WiFi connecion?

答:
In contrast to what has been said in the other (rather outdated) answers, I've successfully tried running ROS on either Raspbian or Ubuntu with a Raspberry Pi 2 Model B.

After some back and forth, I'll stick with Ubuntu:
While I didn't managed to access the Raspberry camera module with Ubuntu, I see major advantages in its superior package management and compatibility with ROS. You need some odd new ROS feature? Just sudo aptitude install the package and you're all set.

Title: Can ROS run on a Raspberry Pi?


问:
How to find out how far a motor has taken a vehicle?
I have a small motorized vehicle with gears as wheels running up and down a track made of gear racks. How can this robot know when it has run half the track? And what's the best method to keep it from running off its track at the end and then return to start.

The robot is carrying water, not exactly the same amount each time, so it will not weigh the same. Therefore it might not be the same amount of steps in the stepper-motor each time.

Here I have some ideas that might work, though I am a beginner, and don't know what's the best solution.

GPS tracking it (overkill on such a small scale?)

Some kind of distance measurer

Have a knob it will hit at the middle of the track, telling program to delay for a given time

Track amount of steps the motor has performed (won't be as accurate?)

答:
I would suggest you to check the HC-SR04 Ultrasonic Sensor that could easily wired and programmed into your robo vehicle. By adjusting the sensor to correctly emit ultrasound on a fixed object and measuring echo/ping from the object, you can judge the distance quite accurately.

Another option would be to lay encoder track(alternate black and white zebra-striped track, so you can use an optical eye -an LDR or LED opto sensor to count the contrast changes while traversing through the track).

(I am not so good with photoshop, HTH :) )


问:
Wiring & driving TowerPro SG90 servos
I got my hands on a few Tower Pro SG90 9G servos but cannot find their schematics or datasheet anywhere (besides that link).

I have the following concerns:

Looks like they're rated for 4.8V, but will they tolerate a 5V supply?

How do I determine the current they require, in amps, mA, etc.?

There's 3 wires: brown, red & yellow-orange, what do each of these guys do?

If I had to guess I'd say that red is power, another one is direction, and another one is the position to rotate to

答: There are datasheets out there, but none seem to be manufacturers' original, which make them no more worth than toilet paper. What signal protocol(s) does it accept, does it hold presets, for example.</p>

Title: Wiring & driving TowerPro SG90 servos


问:
Real-time camera localisation in known environment
I am young researcher/developer coming from different (non-robotic) background and I did some research on camera localisation and I came to the point, where I can say that I am lost and I would need some of your help.

I have discovered that there is a lot of SLAM algorithms which are used for robots etc. As far as I know they are all in unknown environments. But my situation is different.

My problems and idea at the same time is:

I will be placed in an known room/indoor environment (dimensions would be known)

I would like to use handheld camera

I can use predefined landmarks if they would help. In my case, I can put some " unique stickers" on the walls at predefined positions if that would help in any way for faster localisation.

I would like to get my camera position (with its orientation etc) in realtime(30 Hz or faster).

For beginning I would like to ask which SLAM algorithm is the right one for my situation or where to start. Or do you have any other suggestions how to get real time camera positions inside of the known room/environment. It must be really fast and must allow fast camera movements. Camera would be on person and not on robot.

thank you in advance.

答: As a matter of fact, if the environment is known a priori, then you don't need SLAM. It is a matter of localization problem which is simpler than SLAM in the sense that the map is given, therefore you don't need to estimate the map. In  Probabilistic Robotics book chapter 7, the localization problem is addressed and they use probabilistic methods for the estimation process. They use 2D laser sensor. In your case, the heavy load is the vision part (i.e. extracting meaningful information from frames), other than that, you need an algorithm for the estimation process (e.g. EKF or Partical Filter) and data association algorithm for the process of matching between the observed features and the features in the given map (i.e. assuming your map is of feature-based type).  </p>


问:
Programming a line following robot with reinforcement learning
I am considering programming a line following robot using reinforcement learning algorithms. The question I am pondering over is how can I get the algorithm to learn navigating through any arbitrary path?

Having followed the Sutton & Barto Book for reinforcement learning, I did solve an exercise problem involving a racetrack where in the car agent learnt not to go off the track and regulate its speed. However, that exercise problem got the agent to learn how to navigate the track it trained on.

Is it in the scope of reinforcement learning to get a robot to navigate arbitrary paths? Does the agent absolutely have to have a map of the race circuit or path? What parameters could I possibly use for my state space?

答:
I am not sure what type of robot you have but i have been doing robocup rescue line for a few years now. I have come to realise that if you want to follow a line well using PID is a good option. Let me expand on this. If you imagine two light sensors on either side of the line you would want them to be of equal value so that the line is in the middle. You can then use the difference between the value of the two sensors to change the turning percentage of the robot. With this technique it is possible to get a robot to follow a line at extraordinary speeds.

In terms of making the robot learn to improve its line tracking abilities. What i came up with is start with your initial PID values higher than you want them to be and use a gyroscopic sensor to measure the frequency of oscillation of the robot as it tracks the line. You can from there create your own function to determine how much to lower your values which acts as an automated reinforcement learning parameter.  So if the oscillations are too high or become unstable then you state this set of parameters are bad.


答:
I can't comment on Epiphany, but you can absolutely connect additional RAM to an XMOS to be able to run ROS if the onboard 64KB/core RAM isn't sufficient. Check out the libraries on the XCore Github page:

SDRAM

SDRAM burst mode

SPI FRAM

SRAM

The XK-XMP-64 reference design has onboard SDRAM and the PDF schematics are in the Git repository if you want to go that route.

I'm picturing a lot of wrapper functions to call ROS functions and pass/stream data between threads with the XMOS inter-thread communication channels. There's a lot of design decisions you would have to make with respect to what threads to run on which cores -- if you run multiple threads on the same core, the 400-500 MIPS per core is split among them.

Title: Would ROS benefit from a multicore processor like Epiphany or XMOS?

Body:
I am looking for a good embedded PC to run ROS on. I recently came across a couple of little machines using new very multi-core processors, such as the Epiphany and the XMOS.

Since the one thing that ROS really seems to want is cores, would ROS be able to take advantage of all of these cores? Or are they all just too feeble with too little RAM to be of any use?

Would it make more sense to focus on machines with fewer, more powerful cores?


问:
Why do we generally prefer DH parameters over other kinematic representations of robot arms?
I am specifically interested in DH parameters versus other representations in terms of kinematic calibration.  The best (clearest) source of information I could find on kinematic calibration is in the book "Robotics: Modelling, Planning and Control" by Bruno Siciliano, Lorenzo Sciavicco, Luigi Villani, Giuseppe Oriolo, chapter 2.11.  Which requires a description of the arm in DH parameters, multiplying out the kinematics equation, partial differentiation w.r.t. each DH parameter, then a least-squares fit (with the left pseudo-inverse), then iterate.

Is there some fundamental reason why DH parameters are used instead of a different representation (like xyz + euler angles).  I understand that there are fewer parameters (4 versus 6 or more), but for a calibration procedure like this I will be taking much more data than unknowns anyway.  All the robotics textbooks i have read just present DH parameters and say "this is what you should use", but don't really go into why.  Presumably this argument can be found in the original paper by Denavit, but I can't track it down.

答:
The link, What are the advantages of using the Denavit-Hartenberg representation?, in Paul's comment provides a correct synopsis.

Additional, practical benefits are:

DH provides a guaranteed minimal representation. Very good for linear algebra computations, as you want to use the most compact form that's available.

DH matrices are very straight-forward to solve. Fast computations are often needed for velocities, accelerations, rotations, translations, center of gravity, all variations of Jacobian derivations, essentially all kinematics.

Using DH with a least-squares technique will help in the reduction of error faster, i.e. faster convergence of the estimated states.

If you keep reading "Robotics: M P C," you'll see the same style of linear algebra derivations popping up.  The authors derived these equations to all work with the simple DH matrices.  You can use any other representation, but you'll have to re-derive the kinematics.


问:
How to tune PID for a Y(t) = k*X(t) system?
Could I have your opinions on PID type selection?

System description

Here comes a very simple system: $\mbox{Output}(t) = k * (\mbox{Input}(t) + \mbox{systemVariable}(t))$. $k$ is constant and $\mbox{systemVariable}(t)$ is a system variable which may change according to time.

The goal of the whole system is to maintain system output at $0$. It has to be as close to zero as possible. The controller has to compensate the $\mbox{systemVariable}$.

The change ($\mbox{systemVariable}$ ) is modeled by a very slow ramp.

Controller description

The controller's input is the output of the system. However, the measurements are always noisy, and I modeled Band-Limited White Noise into the measurements.

After PID controller, the output goes into an integrator, since the PID controller always calculates the "change" of the plant input.

Questions

My original thoughts: Add a PID controller with P=1/k is enough. Since every time the controller gets an error $e$, it can be calculated back that the compensation on controller output shall be $e/k$. However, Matlab auto-tuning always give me a PID. Why is that?

What is the relation between P of PID and measurement noises? If P is large, the system will tend to be rambling largely, due to the noises. If P is small, the system will tend not to converge to the correct value or very slow. How to make the trade-offs? Or how to prevent system from rambling largely and get quick system responses?

Thanks a lot!

答:
I just re-read your question again, and I realized that you are mistaken about the output of the PID controller. The PID controller, like most controllers, provide exactly the signal that should be sent to the plant. You should NOT be integrating the output of the controller. The PID controller does look at the output error (input - output), but it acts on that output error to provide the appropriate plant input to drive that output error to zero (to get the output to equal the input). Again, DO NOT integrate the output.

If your only issue with this system is the noise coming off of your feedback, then why not just use a filter and be done with it? You haven't stated what your plant is, so I don't know why your system variable would be a (unbounded?) ramp.  Even if you are going to decide you need a PID controller, you should still use a filter if you are expecting noisy feedback.

Regarding measurement noise and PID, typically in industry the controllers are only PI, not PID, because a noise spike causes a big derivative term to be erroneously added. That is, all other things in equilibrium, $D = (noise/dT)$, where $P = noise$ and $I = noise*dT$. So, assuming you have a small sample time, noise causes usually no problems on the $I$ term, some on the $P$ term, and a lot on the $D$ term. The best way to mitigate noise is to not introduce it. Use a filter!

Matlab auto-tuning is always going to give you PID because it is stupid in that it does not understand how to exploit specific information about your plant. It provides a system capable of controlling any (SISO) plant.


答:
The red one is Vcc+ (positive) generally 5-6V, brown is ground and yellow-orange is the signal, usually a pulse-width modulated signal (PWM). The current depends on the load driven. For no load conditions its usually as low as 500mA when fully loaded may require up to 1A.
Good Luck and cheers</p>

Title: Wiring & driving TowerPro SG90 servos

Body:
I got my hands on a few Tower Pro SG90 9G servos but cannot find their schematics or datasheet anywhere (besides that link).

I have the following concerns:

Looks like they're rated for 4.8V, but will they tolerate a 5V supply?

How do I determine the current they require, in amps, mA, etc.?

There's 3 wires: brown, red & yellow-orange, what do each of these guys do?

If I had to guess I'd say that red is power, another one is direction, and another one is the position to rotate to


答:
I had problems understanding the diagram and the question. It might be because you didn't explain every step to keep the question short or just because I use some terminology differently so I'd like to go through this slowly. This is not to say that this is the right way to do it, but so that everybody is on the same page. The comments imply that others are also confused. Essentially, I would identify things differently and in control theory giving something a different name can be a major part of the solution.

I was pretty much in WTF? mode until I saw this in the comments: r+PID_output, which gave me a hint on how this came to be. Well, at least I think.

The ramp is not part of the plant

No, not even if it is part of the plant. The reason is that adding the ramp makes the plant nonlinear. An LTI system is a Linear Time Invariant system. That means (among other things) shifting the input by some amount of time, should only result in a time shifted output, without changing the input value. The ramp breaks that rule.

For the sake of some more confusion, $y = mx + n$ is also nonlinear1.

I could come up with some gruesome simile about how you'd want to rather choke on your own innards than doing nonlinear control theory, but instead I'd say let's try to do this with linear control theory. It is able to handle the situation.

The plant is just $k$, it's transfer function (which can be calculated now, just another benefit of kicking the ramp out) is simply:

$$ output (t) = input(t) \cdot k \\ Output(s) = Input(s)\cdot k \\ \frac{Output(s)}{Input(s)} = k$$

Neither noise nor integrator are part of the controller

As you say, the noise isn't created in the controller, so why model it there?
And the mysterious integrator is removed in a coincidently similar way to the ramp. * cough *

We are left with the bog standard control loop without a sensor. (a sensor will never be present in this answer, the sensor in the image simply has a transfer function of 1)

Finding a suitable controller for the system

$P=\frac{1}{k}$ is enough. Since every time the controller gets an error e, it can be calculated back that the compensation on controller output shall be $\frac{e}{k}$. However, Matlab auto-tuning always give me a PID. Why is that?

It's tempting to use the inverse of the transfer function of the system as a controller.

That would compensate the system exactly, if you are a glas-half-full kind of person. On the other hand, if you are a glas-already-empty-again-damnit-gotta-order-another-one kind of person, it only compensates the system exactly. The subtle difference is that a model is never exact. With slight inaccuracies in the model due to real world stuff, compensating the system transfer function exactly is not a good idea.

Adding an integral part for good measure is usually a good idea, one reason is stated here:

The integral term accelerates the movement of the process towards setpoint and eliminates the residual steady-state error that occurs with a pure proportional controller.

For those about to ramp, we compensate you2

The existence of the ramp cannot be denied. Instead of modelling it as part of the system, let's model it as the disturbance variable as can be seen in the following image named $W$

hint: a click on the image leads you to the source of the image which is an article on how to simulate disturbance transfer functions with matlab

Two important properties of a system are:

how quickly it follows a change of the input, which is kinda moot, because that's constant $0$  in your case

how quickly it can compensate a disturbance

It's usually a trade-off between both. You can compare them by looking at their transfer functions.

There's a great image showing that on a non English Wikipedia article. This is optional, so feel free to just skip this.

Trouble is that the variables used there have different names. The block diagram with controller $G_R(s)$, system $G_S(s)$ and disturbance $D(s)$ looks like this:

The disturbance transfer function is thus given as:

$$\frac{Y(s)}{D(s)}=\frac{G_S(s)}{1+G_R(s)G_S(s)}$$

Ok, ready? Here it comes:

Don't worry if you don't have the Sauerkraut to read it, because I do.

There are 4 plots displaying unit jumps of disturbance and input and the output responses to these using two different controllers (both PID controllers but different parameters):

the $\color{blue}{\text{thin blue}}$ line is the plot of the input $w(t)$ jumping to $1$ at $t = 0$, it's basically just a horizontal line at 1

the $\color{green}{\text{thin green}}$ line is the plot of the disturbance $d(t)$ jumping to $1$ at $t = 10$

the $\color{blue}{\text{thick blue}}$ line is the response of the output controlled by a controller tuned for quickly adopting changes in the input. As you can see it takes the jump of the input rather well without overshooting much. The disturbance however is not compensated quickly. It causes a huge bump in the plot(up to 1.3) which never fully recovers back to 1 (where it should be) within the visible area of the diagram. You certainly don't want that.

the $\color{red}{\text{thick red}}$ line shows the response of the output controlled by a controller tuned to quickly compensate disturbances. The response to the input jump is a disaster, but the response to the disturbance jump at $t = 10$ is barely visible. The disturbance jumps from 0 to 1, but the output only climbs to roughly 1.05 because of that. This is what you want

The only difference between the two is what PID parameters were used:

$$\color{blue}{G_R(s) = \frac{0.8(2s+1)(s+1)}{s}}$$
$$\color{red}{G_R(s) = \frac{10(2s+1)(s+1)}{s}}$$

There's some factor that should be rather big (10 vs. 0.8) in order to compensate disturbance well, let's call this factor $a$:

$$G_R(s) = \frac{a(2s+1)(s+1)}{s}$$

The generic PID controller has the transfer function

$$G_{PID}(s) = K_p + K_i\frac{1}{s} + K_ds$$

I conclude that multiplying all 3 PID parameters by some factor improves how well the system can handle disturbance.

Your system is different and your disturbance is a ramp instead of a jump. But the example shows how to analyse a system, which should help you tune your controller.

The disturbance is also what I'd add the noise to.

The mysterious integrator

Now that's all nice, but what the heck is this integrator thingy supposed to be? And how is r+PID_output a hint?

It's a feed forward compensation of the disturbance. r+PID_output is a hint because it contains the +, which indicates that this is supposed to be a feed forward. The problem is that in the block diagram, it is a separate block after the PID controller, which means in the block diagram, it is actually $r \cdot PID_{output}$, which is not how feed forward should be.

The following image shows how a feed forward compensates disturbance: (with yet again differently named variables)

The compensation of the disturbance is indeed added after the controller. As can be seen in the image, it is added via a negative summation node.

As seen above, the controller itself should be able to handle disturbance, because it is tuned to do only that in your use case.

A feed forward can take some workload off the controller. If you really think this is neccessary, go ahead and add the feed forward. I would keep it separate from the controller, for better readability, although adding the feed forward will basically just change some parameters of the PID controller.

1 check this proof on electronics.SE

2 with apologies to AC/DC

Title: How to tune PID for a Y(t) = k*X(t) system?

Body:
Could I have your opinions on PID type selection?

System description

Here comes a very simple system: $\mbox{Output}(t) = k * (\mbox{Input}(t) + \mbox{systemVariable}(t))$. $k$ is constant and $\mbox{systemVariable}(t)$ is a system variable which may change according to time.

The goal of the whole system is to maintain system output at $0$. It has to be as close to zero as possible. The controller has to compensate the $\mbox{systemVariable}$.

The change ($\mbox{systemVariable}$ ) is modeled by a very slow ramp.

Controller description

The controller's input is the output of the system. However, the measurements are always noisy, and I modeled Band-Limited White Noise into the measurements.

After PID controller, the output goes into an integrator, since the PID controller always calculates the "change" of the plant input.

Questions

My original thoughts: Add a PID controller with P=1/k is enough. Since every time the controller gets an error $e$, it can be calculated back that the compensation on controller output shall be $e/k$. However, Matlab auto-tuning always give me a PID. Why is that?

What is the relation between P of PID and measurement noises? If P is large, the system will tend to be rambling largely, due to the noises. If P is small, the system will tend not to converge to the correct value or very slow. How to make the trade-offs? Or how to prevent system from rambling largely and get quick system responses?

Thanks a lot!


问:
What are the reasons for not having autonomous robots in our daily activities?
The fact is that the more I search the less I find autonomous (real) robots in use. The companion robots are all toys with limited useless functionality. Whenever there is a natural disaster you don’t see operational search and rescue robots in the news. Even military robots in service are all remotely controlled machines. They are not intelligent machines. Industrial robotic arms are deterministic machines. The only robots with some levels of autonomous functionality are cleaning bots, warehouse operations bots and farming robots.

On the other hand, today:

the artificial intelligence algorithms are very good in making decisions

the sensing technologies are very sophisticated

the communication technologies are very fast

we can manufacture cheap parts

people are extremely gadget savvy

So, why there is no real robot in our day to day life? No investment in the domain? No market yet? Not enough knowledge in the domain? A missing technology? Any idea?

答:
A major limiting factor to autonomous robots is intelligence. While AI has made great strides it has generally been unable to handle the complexity of the world. A common solution this problem has been to restrict autonomous robots to very simplified versions of the world.

The Roomba is a good example. It deals with the complexity of the world by essentially executing combinations of simple patterns (spirals, straight lines, etc.) where transitions between patterns are a function of obstacle presence and time. This has its benefits. For instance the Roomba only needs a hand full of bump and IR sensors to perceive its world which in turn limits the amount of processing power required.

The exception at the moment is autonomous vehicles. This comes predominantly from the large investments the military has been making over the years. Not only in Unmanned Aerial Vehicles (UAVs) but also ground based vehicles. Widely known examples of these investments include the DARPA Grand Challenge and DARPA Urban Challenge. Fortunately a lot of the techniques developed for these vehicles are more generally applicable. For instance the motion planning techniques are usually applicable to robots with other methods of locomotion.

Other types of autonomous robots are on the horizon because of similar investments. For instance DARPA recently announced a winner of the DARPA hand challenge and is actively promoting a contest for bipeds. Similarly companies like Boston Dynamics have done a lot to advance autonomous robots. Of course one might object that their robots (e.g. BigDog and Cheetah) are only semi-autonomous but such an objection fails to recognize just how much autonomy is still involved.


问:
Can RC servo motors continually rotate?
I know that RC servo motors are designed for precise movement, rather than a D.C. motor's continual rotation. Are most RC servo motors limited to movement within one rotation or can they actually be made to continually rotate? That is to say, is their movement limited to a specific arc? Or does it depend on the type of RC servo motor?

I have seen videos of industrial size steppers rotating constantly, but, more specifically, I was wondering whether a MG995 can.

I don't own any RC servo motors yet, so I can't actually test it myself. I just want to make sure before I make a purchase. I keep seeing conflicting information, for example the instructable, How to modify a RC servo motor for continuous rotation (One motor walker robot), implies that a RC servo motor will not continually rotate, else otherwise, why would there be a need to modify it?

Addendum

I have just realised, after further digging about on google, and as HighVoltage points out in their answer, that I have confused steppers and servos.

In addition, I found out how to hack the TowerPro MG995 Servo for continuous rotation.

答:
In a nutshell, servo motors and stepper motors are not technically the same things. The link you posted is only for servos and not stepper motors. A servo motor assembly does not rotate freely like a DC motor. The rotation angles are usually limited, and every servo has a "lock" position where it stays by default. A positive pulse makes it move clockwise, negative makes it move counterclockwise. Even if it needs to stay "locked", it needs a pulse at a high frequency telling it to stay there. Although the motor by itself is CAPABLE of running continuously, that's not how servos are meant to be used. Hence the need for modifications.

Stepper motors on the other hand, as the name states, move in steps. It moves from one electromagnet to the other, in a slow, precise fashion depending on which one is energized. So if you set a very high number of "steps", and if your driving waveform is smooth enough, the motor will exhibit a near continuous rotation. Because of all the energizing needed, it needs a special driving circuit as well.

Title: Can RC servo motors continually rotate?