问:
Need help calculating the thrust on quadcopter motors
I'm trying to calculate the lifting capability of my four quadcopter motors. I tried using eCalc but it doesn't have battery I'm using. Are there any equations to keep in mind for doing these calculations? Here are some relevant details:

Battery: 2200mAh 3S 25~50C LiPo

ESC: 25A

Motor: 1240kV Brushless

Propeller: 8x4

Any help would be much appreciated, thanks!

答:
You could probably calculate this value, but the sensible thing to do would be to just measure it directly.

Just turn it upside-down and put it on a kitchen scale as shown in this video.


问:
Device to roll a mat
I'm looking for some direction on how to create a device that does the following:
Imagine you have a yoga mat, I want a device that can roll it up and unroll it without a human intervening in the rolling process.
I reliable this is a robotics forums but there doesn't appear to be a section for mechanical engineering so I'm posting my question here.</p>

答:
Some inspiration from this leading robot

PR2 Autonomously Folding A Tshirt

PR2 Handling other tasks too

ContentLicense: CC BY-SA 3.0

Title: Device to roll a mat


问:
Natural frequency computation (for PID gains computations)
I am currently trying to parametrize the low-level gains of a robotic arm. This arm uses a classical PID for each joint.

I am trying to use a method based on computation rather than a trial-and-error/tweaking approach. The method I use considers each joint independently and assumes the system driven by the PID is linear. Hence I infer a transfer function, a characteristic polynomial, poles and this gives me gains $K_p$, $K_i$, and $K_d$ for each joint.

Now, computed as I did, these gains depend on the natural angular-frequency. For example:
$$
K_p = 3 a w^2
$$
where $a$ is the inertia and $w$ is the natural angular-frequency.

Hence my question: how shall I compute $w$, the natural angular-frequency for my system? Is this an enormous computation involving the geometry and other complex characteristics of the robot, and that only a computer can do or are there simple assumptions to be made which can already give a rough result for $w$?

I guess this is a complex computation and this is one of the reasons why PID gains are most often found by trial-and-error rather than from computation. Though I am looking for some more details on the subject to help me understand what is possible and what is not.

Kind regards,

Antoine

答:
For a rough calculation of natural frequency, you could create an bode plot.

Starting at low frequencies, command a sin wave and measure the amplitude of the output motion (which will be a phase-shifted sin wave). Plotting the output amplitude on a log-scale, if you're lucky the response will be flat for a while, turn relatively quickly, and then start decaying in a straight line (again, make sure it is a log-log plot). If you extend the 2 asymptotic lines, the early horizontal and the later decaying, the point at which they intersect is the natural frequency.

That said, I am doubtful that you will get a good result.

First, it assumes a second order linear system which is sometimes a good approximation and sometimes not.

Second, it can sometimes be hard and sometimes dangerous to measure the response especially at higher frequencies.

Lastly, mathematical tuning techniques like these only work well for simple, isolated systems. A robotic arm is anything but: movement at the wrist joint significantly affects the elbow joint creating a complex coupling. At best, the mathematical tuning will give you a starting point from which you will need to manually tune.


问:
Mechanical or electrical engineering for robotic and automation?
I have decided to pursue a career in automation and robotic. At the moment, I am being torn between Mechanical and Electrical Engineering. I know that both of them relate to my choices of career, and at the moment, I think that I like them equally. I hope you guys can help me solve my dilemma by using your insights/experiences to assist me with the following questions:

1/ From your experiences and opinions, which of the two engineering fields is generally more crucial and challenging, especially in an automation/robotics project?

2/ Which will see an increase in demand and importance in the near future? Which of them might become outdated/obsolete or at least develop at a slower rate compare to the other?(I have a feeling that EE has a slight edge over this matter; however, I am not so sure)
3/ Which of the fields is more versatile? Which is more physical demanding (I am actually quite frail)

4/ Which is generally easier to self-study? Robotics is obviously an incredibly broad and complex field and I have prepared to step outside of my comfort zone and do lots of studying by myself to achieve my goals and passion.

I could probably come up with a few more questions; however, I am sure that you guys got the gist of my puzzle. Thank you very much and I apologize if there is any grammatical error.

答:
How about make a self reflection on

a) which one you like from the heart, only yourself can answer this hard
    question

```<code>b) which earn more, this is easy. can check Government labor
department statistic and prediction

c) are you able and confident in learning it, try tasting from looking at MOOC
courses
</code>```

Hope this help, welcome and best wishes

Body:
How about make a self reflection on

a) which one you like from the heart, only yourself can answer this hard
    question

b) which earn more, this is easy. can check Government labor
department statistic and prediction

c) are you able and confident in learning it, try tasting from looking at MOOC
courses

Hope this help, welcome and best wishes


问:
How to machine aluminium on a low budget?
For my robotic projects I need some aluminium parts. Currently I am looking for a way to build a chassis including simple gear box. So I need relatively high precision. Which options do I have to machine aluminium without investing in expensive tools?

This is what I could think of so far.

Design parts in CAD and send them to a third party company for fabrication. The problem with this is that hobby projects almost never need large quantities and piece production can be still expensive.

Buy cheap tools to work aluminium by hand. I don't know which tools would fit this task best. Moreover, the results might be inaccurate, which is a problem for designs with moving parts.

Find someone with a CNC who let's me machine my parts. This would most likely result in very slow prototyping cycles though.

A method that I can do at home with not too expensive tools would be perfect, but I'm looking forward to every solution.

答:
Look for a makerspace in your area, in boston there is http://artisansasylum.com/site/
they have various CNC machines, laser cutters, Etc. which with some simple low cost training you are allowed to use. </p>


问:
Using vision for Monte-Carlo localization
From each step of my vision code I am able to get around 400 coordinates of where the robot thinks the walls are

I want to integrate this into Monte-Carlo observation step.

I'm storing the map of the maze as a set of Line segments. What would be a nice way to implement the sensor update, i.e. given the position (x,y) of the robot what is the probability that it is found there given the above described coordinates of the walls.

The main idea I currently have:

Transform points in polar coordinates. Then for each point (from vision output) compute a ray with this angle and find the first intersection with the maze. Now we have the predicted distance and real distance and we can compute the probability that this measurement is right.

The main drawback is that this is slow. For each point from vision output I have to iterate over all line segments to find the one with the closest intersection. The line segments number is around 50. So it gets to O(400*50*Particle number).

答:
Wow, walls, mazes, casting rays. Does anyone have Wolfenstein/Doom deja vu?

Back in the day, these games had to solve similar problems, calculating the intersection between lines (of fire or movement) and the walls of the map. For Wolfenstein, it was fairly easy because the map was arranged in a grid, and they used Ray Casting.

For Doom, it was a little harder, since there was no grid. So they used something called a Binary Space Partitioning Tree (BSP Tree):

This recursively divides the map in a way that makes it easy to perform geometrical queries on it. In computer graphics, this would usually mean rendering the surfaces in such a way that there was no overlap, but it could also mean performing efficient collision detection.

The BSP Tree works well if your walls are defined by nice large lines/planes. However, if your walls consist of thousands point cloud samples or something, then the tree will be inappropriate.

In the case of point cloud (or tiny line cloud) data, I would recommend a quadtree. Again, this divides space recursively in such a way that you can easily find the set of points that are close to your robot, or close to some line.


问:
Visual Odometry options?
What are the pros/cons of the different visual odometry options?

Stereo Camera

Optical Flow

SLAM

other?

Criteria:

how well it performs vs other odometry options/sensors (lidar, radar)

sensor fidelity

computation

accuracy

precision

drift

native resilience and repeadability in sensor noise or vehicle speed

ease of integrating with IMU/GPS

etc

In general, of course, because there are a lot of different ways the trade-offs go when we get into specifics about applications and hardware.  I'm asking out of curiosity, not for designing anything in particular.

答:
I'm not familiar with all visual odometry options, but you might find the following two articles that recently appeared in the IEEE Robotics and Automation Magazine relevant:

Scaramuzza, D., Fraundorfer, F., Visual Odometry: Part I - The First 30 Years and Fundamentals, IEEE Robotics and Automation Magazine, Volume 18, issue 4, 2011.

Fraundorfer, F., Scaramuzza, D., Visual Odometry: Part II - Matching, Robustness, and Applications, IEEE Robotics and Automation Magazine, Volume 19, issue 2, 2012.

Title: Visual Odometry options?


问:
rock/syskit: How to add multiple instances of same component into a network
I've been going through Syskit tutorials at rock-robotics.org. In the tutorials e.g. First composition, there are two different components declared with:

```<code> add Controldev::JoystickTask, :as => "cmd"
 add RockTutorial::RockTutorialControl, :as => "rock"
</code>```

I was wondering how could I add an additional RockTutorialControl into the composition, so that the instantiation would then create two separate instances of the same component?

I've tried something like

```<code>add RockTutorial::RockTutorialControl, :as => "foo"
</code>```

but this apparently isn't the way to go. syskit instanciate command shows only one instance of RockTutorialControl, but gives two roles to it (rock and foo). What is the meaning of "role" in this context?

I've noticed that the tutorial explains how to make multiple instances of the same component when we're declaring our components as Devices. But how to do this with components that should not be concerned as devices?

BR,
Mathias

EDIT:

This was my first question to StackExchange, and I don't know what's the policy for adding additional information to the original question, but here we go:

It seems that both the deployment and configuration need to be different when there are two instances of the same component. I did a small scale testing with two components:

```<code>using_task_library 'foobar_user'
using_task_library 'foobar_proxy'

module FooModule
  class FooControl < Syskit::Composition

  add FoobarUser::Task, :as => "producer"
  add FoobarProxy::Task, :as => "proxy"
  add FoobarUser::Task, :as => "consumer"

  producer_child.connect_to proxy_child
  proxy_child.connect_to consumer_child
  end
end
</code>```

where FoobarUser::Task has an input & output port of /std/string. FoobarProxy::Task has corresponding i&o ports. FoobarUser::Task has also two configurations called 'default' and 'other'. It also has two deployments 'foo_depl' and 'bar_depl'.

In order to create a "pipeline" where data flows producer ==> proxy ==> consumer, I made define line:

```<code>define 'conf_and_depl', FooModule::FooControl.use('producer' => FoobarUser::Task.use_conf('other').prefer_deployed_tasks(/foo_depl/), 'consumer' => FoobarUser::Task.use_conf('default').prefer_deployed_tasks(/bar_depl/))
</code>```

and then instanciated the network with

```<code>syskit instanciate scripts/03-nwtest.rb conf_and_depl_def!
</code>```

The component instanciation failed if either use_conf or prefer_deployed_tasks clause was left out. In both cases the produced error was "cannot deploy the following tasks... ...multiple possible deployments, choose one with #prefer_deployed_tasks".

答:
This is what syskit should do,
in the end syskit decides about the amount of modules.
If you simply add the Requirement a second time syskit recognizes that they can be merged together and removes during instanciation the second one. (to be more precise it merges them together).

You have to add different confiugations and/or build up connections that differ from the usage of the first one.

Hope this clarifies.

Best,
Matthias


答:
The term you are looking for is "frustrum", and the algorithm you want is "frustrum culling".

Check out this answer for how one would implement culling in a 2D game.

If performance is still an issue, remember that you don't need to consider all 400 "possible wall coordinates" every time.  If you try to determine your exact position in a single step, you're trying to outsmart the particle filter; you don't need to do this.

Think of it this way: your robot is not randomly teleporting from place to place -- it's in one position now, and it will be in a very similar position at the next time step or sensor reading.  Just evaluate as many coordinates as you can in the available time (for each particle), then do it again; your particles will doing the work.  Obviously, you will converge faster if you can evaluate more coordinates at each step... but there are diminishing returns to adding more accuracy to each particle.  This simulation shows that using only 20-ish measurements will still give you decent results:

(source: washington.edu)

I'd imagine your code looks like this:

```<code>foreach particle
    foreach coordinate
        foreach segment
            see if a ray through coordinate intersects segment
</code>```

You may want to try structuring it like this:

```<code>while there is still time before the next sensor measurement
    pick a coordinate that's far away from the coordinates that have been tried already
    foreach particle
        foreach segment_in_frustrum
            see if a ray through coordinate intersects segment_in_frustrum
</code>```

Title: Using vision for Monte-Carlo localization

Body:
From each step of my vision code I am able to get around 400 coordinates of where the robot thinks the walls are

I want to integrate this into Monte-Carlo observation step.

I'm storing the map of the maze as a set of Line segments. What would be a nice way to implement the sensor update, i.e. given the position (x,y) of the robot what is the probability that it is found there given the above described coordinates of the walls.

The main idea I currently have:

Transform points in polar coordinates. Then for each point (from vision output) compute a ray with this angle and find the first intersection with the maze. Now we have the predicted distance and real distance and we can compute the probability that this measurement is right.

The main drawback is that this is slow. For each point from vision output I have to iterate over all line segments to find the one with the closest intersection. The line segments number is around 50. So it gets to O(400*50*Particle number).

Body:
The term you are looking for is "frustrum", and the algorithm you want is "frustrum culling".

Check out this answer for how one would implement culling in a 2D game.

If performance is still an issue, remember that you don't need to consider all 400 "possible wall coordinates" every time.  If you try to determine your exact position in a single step, you're trying to outsmart the particle filter; you don't need to do this.

Think of it this way: your robot is not randomly teleporting from place to place -- it's in one position now, and it will be in a very similar position at the next time step or sensor reading.  Just evaluate as many coordinates as you can in the available time (for each particle), then do it again; your particles will doing the work.  Obviously, you will converge faster if you can evaluate more coordinates at each step... but there are diminishing returns to adding more accuracy to each particle.  This simulation shows that using only 20-ish measurements will still give you decent results:

(source: washington.edu)

I'd imagine your code looks like this:

foreach particle
    foreach coordinate
        foreach segment
            see if a ray through coordinate intersects segment

You may want to try structuring it like this:

while there is still time before the next sensor measurement
    pick a coordinate that's far away from the coordinates that have been tried already
    foreach particle
        foreach segment_in_frustrum
            see if a ray through coordinate intersects segment_in_frustrum

ContentLicense: CC BY-SA 4.0


问:
Artificial Potential Field navigation
I've been working on my two-wheeled mobile robot I've been trying to perfect my obstacle avoidance algorithm which is Artificial Potential Field method . Also i use Arduino Uno kit . The basic concept of the potential field approach is to compute a artificial potential field in which the robot is attracted to the target and repulsed from the obstacles. The artificial potential field is used due to its computational simplicity. the mobile robot applies a force generated by the artificial potential field as the control input to its driving system . the Artificial Potential Field method in its computations depends on the distance between robot and goal or target and the distance between robot and obstacles that effected the robot (which could easily get for ultrasonic senors)

I applied the Artificial potential field method in Matlab environment / simulation and it is done successfully , really what I need in the simulation is to get the current position of mobile robot and position of goal as x, y coordinates (to compute the distance between robot and goal) and the obstacles positions.

The output of the Artificial potential field is the desired angle to avoid obstacle and reach to the goal , the method give the robot the angle the pointed to the goal then the robot goes toward that angle and if the robot face an obstacle in his way (got from sensor reading) the Artificial potential field will update the angle to avoid the obstacle and then re-give the robot the angle that pointed to the goal and so on.

The question is how could I apply the Artificial potential field method in real would? what should I get? is it easy to do that or it is impossible?

I had Rover 5 with two normal DC motors and two encoders (incremental rotary encoder) per each wheel.

Any Help or suggestion on the topic will be highly appreciated please.

Edit: Based on the response from Shahbaz.

The case is very simple, but first, there is something to know that I constrained with some limitations that I couldn't overstep them, one of them is that the real world should be exactly as simulation for example in the simulation I consisted that robot started with (0,0) on coordinates  x, y axis and I should put the goal point for example (10,20)  and feed this point in the Artificial potential field method and then compute distance between  robot and goal (so I don't need any technique to determine the position of goal) and I don't know if I could applied that.

The second constraint is that I should use the encoders of wheels to determine the current position of mobile robot and its orientation depending on a calculation formula (something like this here) even if that will be inaccurate.

I had a Rover 5 with two normal DC motors and two encoders (incremental rotary encoder) per each wheel, each encoder has four wires I don't know how to deal with them yet, and how could I translate the pulses of encoders or how to work out the x.y position of your robot based on the shaft encoder data.

I am still searching for ….

答:
From the algorithm's point of view, there is really no difference between the real world and the simulation. The difficult part is to give the correct information to the algorithm.

For that, you need to look at what information your algorithm requires:

Your current position

Goal's position

All obstacles' position

The question is therefore how to get these information. The answer is that it really really depends. There are numerous ways for each and they all depend on what your robot can do, what facilities it has available, what control you have over the environment, whether the environment is static or not etc.

Your location

For example, outdoors you could use GPS to locate yourself, while indoors you may be looking for SLAM. You could possibly get information from a camera installed in the ceiling, or various other methods (search for robot localization).

Goal's location

You could find the goal with the ceiling camera if you have one, you could try to find it by exploration (i.e. set a random goal, go there and in the meantime scan for the real goal e.g. with a camera.  If goal not found, go to another random goal), or you could try other methods, e.g. by having the goal send a signal whose direction and strength would be picked up by the robot.

Obstacles' positions

You could again find the obstacles with a ceiling camera, you could find nearby ones (not all of them) with sonar, laser etc, or in case of a static environment simply have a predefined map.

Once you have these information, you can use your algorithm just as before and get the direction you need to go to. You still need to control the robot accordingly. Since you already know about encoders, I assume you know how to make your robot turn to the correct angle given your current angle (which is something you possibly calculated when looking for your current location).

I have a couple of suggestions though.  If you already know all the obstacles and the goal's position, then you have better algorithms for navigation.  Your algorithm would get stuck in a situation like this:

```<code>               ----
            --/
          -/
 goal    |           You
          -\
            --\
               -----
</code>```

where the algorithm would tell you to go straight to the wall until all potentials cancel out and you reach a stable point where no direction is preferable.

In the case when you have all the information about the environment, you can enlarge the obstacles (in your model) by half of your robot's size (i.e. maximum distance from your center, or whichever point you consider your position to be, to your outer layer), which means you can assume your robot to be a point and the obstacles larger. Then you can use an algorithm such as A* to find the best path to your goal.

If you don't have all information of the environment, you can still use A*, but just add information to the map as you find new obstacles and recalculate your path.

Alternatively, if you don't have all information of the environment and you like to continue with your Potential Field algorithm, you can avoid having information regarding all obstacles and run your algorithm with only those that you know of. Again, as your robot explores, you add more information about the obstacles. This really doesn't change the behavior much since potential is inversely related to distance squared, so the farther objects have very little effect on the potential field at your current position.

Update based on your edit:

Regarding your first point, it's ok. That simplifies things, so all you need is to store the map of your environment (goal position, obstacle positions etc) in whatever way you feel comfortable in your robot (i.e. in a way that you can feed it to your algorithm).

Regarding your second point, you seem to already have the formula, so only thing that remains is the third point, which is converting the signals from the encoder into position.

For that, let's take a look at this very general algorithm:

```<code>current_position = (0, 0)
for ever
    current_position = calculate(current_position, delta_encoder_1, delta_encoder_2)
</code>```

which means start from (0, 0) and on every update, get a new position based on how much each encoder has changed (since last update). The calculate function is effectively the calculations in the link you provided.

To get delta_encoder_1 and delta_encoder_2, you need to consult the datasheet of your encoders. What you get is a series of pulses that you need to detect. Perhaps the most reliable way would be through interrupts, for example by interrupts on the rising edge of a signal arriving from the encoder:

```<code>current_position = (0, 0)
for ever
    current_position = calculate(current_position, delta_encoder_1, delta_encoder_2)
    delta_encoder_1 = 0
    delta_encoder_2 = 0

interrupt_on_encoder_1
    if condition for an encoder step forwards
        delta_encoder_1 += 1
    else if condition for an encoder step backwards
        delta_encoder_1 -= 1

interrupt_on_encoder_2
    if condition for an encoder step forwards
        delta_encoder_2 += 1
    else if condition for an encoder step backwards
        delta_encoder_2 -= 1
</code>```

This means that the interrupts take care of updating delta_encoder_* based on the shape of the pulse, which is something you should get from the datasheet of the encoders. Note the race condition between the interrupts and were the application resets delta_encoder_* values (If you don't know what is a race condition, since you already accept inaccurate position calculation, then don't worry about it).

That said, if you still have doubts, I strongly recommend asking a separate question specifically regarding how to get meaningful data out of your specific encoders.

Title: Artificial Potential Field navigation

Body:
From the algorithm's point of view, there is really no difference between the real world and the simulation. The difficult part is to give the correct information to the algorithm.

For that, you need to look at what information your algorithm requires:

Your current position

Goal's position

All obstacles' position

The question is therefore how to get these information. The answer is that it really really depends. There are numerous ways for each and they all depend on what your robot can do, what facilities it has available, what control you have over the environment, whether the environment is static or not etc.

Your location

For example, outdoors you could use GPS to locate yourself, while indoors you may be looking for SLAM. You could possibly get information from a camera installed in the ceiling, or various other methods (search for robot localization).

Goal's location

You could find the goal with the ceiling camera if you have one, you could try to find it by exploration (i.e. set a random goal, go there and in the meantime scan for the real goal e.g. with a camera.  If goal not found, go to another random goal), or you could try other methods, e.g. by having the goal send a signal whose direction and strength would be picked up by the robot.

Obstacles' positions

You could again find the obstacles with a ceiling camera, you could find nearby ones (not all of them) with sonar, laser etc, or in case of a static environment simply have a predefined map.

Once you have these information, you can use your algorithm just as before and get the direction you need to go to. You still need to control the robot accordingly. Since you already know about encoders, I assume you know how to make your robot turn to the correct angle given your current angle (which is something you possibly calculated when looking for your current location).

I have a couple of suggestions though.  If you already know all the obstacles and the goal's position, then you have better algorithms for navigation.  Your algorithm would get stuck in a situation like this:

               ----
            --/
          -/
 goal    |           You
          -\
            --\
               -----

where the algorithm would tell you to go straight to the wall until all potentials cancel out and you reach a stable point where no direction is preferable.

In the case when you have all the information about the environment, you can enlarge the obstacles (in your model) by half of your robot's size (i.e. maximum distance from your center, or whichever point you consider your position to be, to your outer layer), which means you can assume your robot to be a point and the obstacles larger. Then you can use an algorithm such as A* to find the best path to your goal.

If you don't have all information of the environment, you can still use A*, but just add information to the map as you find new obstacles and recalculate your path.

Alternatively, if you don't have all information of the environment and you like to continue with your Potential Field algorithm, you can avoid having information regarding all obstacles and run your algorithm with only those that you know of. Again, as your robot explores, you add more information about the obstacles. This really doesn't change the behavior much since potential is inversely related to distance squared, so the farther objects have very little effect on the potential field at your current position.

Update based on your edit:

Regarding your first point, it's ok. That simplifies things, so all you need is to store the map of your environment (goal position, obstacle positions etc) in whatever way you feel comfortable in your robot (i.e. in a way that you can feed it to your algorithm).

Regarding your second point, you seem to already have the formula, so only thing that remains is the third point, which is converting the signals from the encoder into position.

For that, let's take a look at this very general algorithm:

current_position = (0, 0)
for ever
    current_position = calculate(current_position, delta_encoder_1, delta_encoder_2)

which means start from (0, 0) and on every update, get a new position based on how much each encoder has changed (since last update). The calculate function is effectively the calculations in the link you provided.

To get delta_encoder_1 and delta_encoder_2, you need to consult the datasheet of your encoders. What you get is a series of pulses that you need to detect. Perhaps the most reliable way would be through interrupts, for example by interrupts on the rising edge of a signal arriving from the encoder:

current_position = (0, 0)
for ever
    current_position = calculate(current_position, delta_encoder_1, delta_encoder_2)
    delta_encoder_1 = 0
    delta_encoder_2 = 0

interrupt_on_encoder_1
    if condition for an encoder step forwards
        delta_encoder_1 += 1
    else if condition for an encoder step backwards
        delta_encoder_1 -= 1

interrupt_on_encoder_2
    if condition for an encoder step forwards
        delta_encoder_2 += 1
    else if condition for an encoder step backwards
        delta_encoder_2 -= 1

This means that the interrupts take care of updating delta_encoder_* based on the shape of the pulse, which is something you should get from the datasheet of the encoders. Note the race condition between the interrupts and were the application resets delta_encoder_* values (If you don't know what is a race condition, since you already accept inaccurate position calculation, then don't worry about it).

That said, if you still have doubts, I strongly recommend asking a separate question specifically regarding how to get meaningful data out of your specific encoders.


问:
What is the difference between the two different types of Mecanum wheels?
While looking at Mecanum wheels, I noticed that there are two different designs that are popular.

One type holds the rollers in between the wheels frame, and the other holds the rollers from the center.

Is there a significant advantage to using one over the other?

答:
The first type of Mecanum wheel has the rollers held at both ends.

This type has a greater load capability, but they have a disadvantage. When they are traveling sideways and meet an inclined plane, the metal rim can collide with the plane.

The second type of Mecanum wheel has the rollers held in the middle

This has lower load capability, because the wheels are cantilevered. However, it is much better at dealing with obstacles and inclined planes.


答:
There are basically two types of components in a network from the point of view of syskit, functional components and device drivers.

Functional components behave as pure functions. It means that two components whose inputs are connected to the same source and that have the same configuration should produce the exact same output. Most components are like this, and that's how syskit works: it is able to find out which components are identical and merge them.

Devices are there to provide entry/exit points for the data, i.e. they tell syskit that the component is not functional but pulls, push or both pushes and pulls data from "the outside world". In a robot, these are provided by hardware which is where the name comes from. Note that for instance a random generator would also need to be declared as a device even though there is no real "device" below.

If you want to force syskit to instanciate the same component twice even though they have the same input connections, you therefore have to either make them device drivers and tie them to different devices, or assign different configurations. Note that they can be dummy configurations, i.e.

```<code>--- name:default
# Real configuration goes there
--- name:foo
# Empty dummy configuration to force double-instance
--- name:bar
# Empty dummy configuration to force double-instance

define 'foo', Composition.use(Component.use_conf('foo', 'default'))
define 'bar', Composition.use(Component.use_conf('bar', 'default'))
</code>```

About the deployments: what I have described so far is how two components get merged or not. Another issue is that, once two instances of the same component model end up in the final network, they have to be deployed. Since they are from the same component model, syskit cannot choose for you (see P.S. below for more details). There is actually a tutorial on that later on in the tutorial series you are currently doing.

P.S.: actually syskit could choose for you. The issue then is that you would not be able to easily understand what each component does when you look at rock-display. Indeed, the same component instance (let's say task1) could have different rols in the same network, depending on e.g. the order in which syskit would have assigned the tasks. Looking at a running system in rock-display and/or at logs with rock-replay would be hell. An integration of Syskit and Rock live display / log tools would solve that nicely, but we're not there yet.

Title: rock/syskit: How to add multiple instances of same component into a network

Body:
I've been going through Syskit tutorials at rock-robotics.org. In the tutorials e.g. First composition, there are two different components declared with:

```<code> add Controldev::JoystickTask, :as => "cmd"
 add RockTutorial::RockTutorialControl, :as => "rock"
</code>```

I was wondering how could I add an additional RockTutorialControl into the composition, so that the instantiation would then create two separate instances of the same component?

I've tried something like

```<code>add RockTutorial::RockTutorialControl, :as => "foo"
</code>```

but this apparently isn't the way to go. syskit instanciate command shows only one instance of RockTutorialControl, but gives two roles to it (rock and foo). What is the meaning of "role" in this context?

I've noticed that the tutorial explains how to make multiple instances of the same component when we're declaring our components as Devices. But how to do this with components that should not be concerned as devices?

BR,
Mathias

EDIT:

This was my first question to StackExchange, and I don't know what's the policy for adding additional information to the original question, but here we go:

It seems that both the deployment and configuration need to be different when there are two instances of the same component. I did a small scale testing with two components:

```<code>using_task_library 'foobar_user'
using_task_library 'foobar_proxy'

module FooModule
  class FooControl < Syskit::Composition

  add FoobarUser::Task, :as => "producer"
  add FoobarProxy::Task, :as => "proxy"
  add FoobarUser::Task, :as => "consumer"

  producer_child.connect_to proxy_child
  proxy_child.connect_to consumer_child
  end
end
</code>```

where FoobarUser::Task has an input & output port of /std/string. FoobarProxy::Task has corresponding i&o ports. FoobarUser::Task has also two configurations called 'default' and 'other'. It also has two deployments 'foo_depl' and 'bar_depl'.

In order to create a "pipeline" where data flows producer ==> proxy ==> consumer, I made define line:

```<code>define 'conf_and_depl', FooModule::FooControl.use('producer' => FoobarUser::Task.use_conf('other').prefer_deployed_tasks(/foo_depl/), 'consumer' => FoobarUser::Task.use_conf('default').prefer_deployed_tasks(/bar_depl/))
</code>```

and then instanciated the network with

```<code>syskit instanciate scripts/03-nwtest.rb conf_and_depl_def!
</code>```

The component instanciation failed if either use_conf or prefer_deployed_tasks clause was left out. In both cases the produced error was "cannot deploy the following tasks... ...multiple possible deployments, choose one with #prefer_deployed_tasks".

Body:
There are basically two types of components in a network from the point of view of syskit, functional components and device drivers.

Functional components behave as pure functions. It means that two components whose inputs are connected to the same source and that have the same configuration should produce the exact same output. Most components are like this, and that's how syskit works: it is able to find out which components are identical and merge them.

Devices are there to provide entry/exit points for the data, i.e. they tell syskit that the component is not functional but pulls, push or both pushes and pulls data from "the outside world". In a robot, these are provided by hardware which is where the name comes from. Note that for instance a random generator would also need to be declared as a device even though there is no real "device" below.

If you want to force syskit to instanciate the same component twice even though they have the same input connections, you therefore have to either make them device drivers and tie them to different devices, or assign different configurations. Note that they can be dummy configurations, i.e.

--- name:default
# Real configuration goes there
--- name:foo
# Empty dummy configuration to force double-instance
--- name:bar
# Empty dummy configuration to force double-instance

define 'foo', Composition.use(Component.use_conf('foo', 'default'))
define 'bar', Composition.use(Component.use_conf('bar', 'default'))

About the deployments: what I have described so far is how two components get merged or not. Another issue is that, once two instances of the same component model end up in the final network, they have to be deployed. Since they are from the same component model, syskit cannot choose for you (see P.S. below for more details). There is actually a tutorial on that later on in the tutorial series you are currently doing.

P.S.: actually syskit could choose for you. The issue then is that you would not be able to easily understand what each component does when you look at rock-display. Indeed, the same component instance (let's say task1) could have different rols in the same network, depending on e.g. the order in which syskit would have assigned the tasks. Looking at a running system in rock-display and/or at logs with rock-replay would be hell. An integration of Syskit and Rock live display / log tools would solve that nicely, but we're not there yet.


问:
Mechanism to oscillate a needle like object in vertical motion
I need to pop out a needle like object(toothpick,matchstick,etc) from a hole in a
surface and push it back in automatically.I need to make a array of such needles in which each needle's position can be controlled individually.The objects aren't supposed to be oscillated continuously, instead they are to be locked in one of the two positions-either above the surface or inside it.
I am trying to search a mechanism to achieve this.This can be easily done with a simple DC servo motor, but the problem is I have to do this in very limited space-about 6 such objects in base area of 3 cm x 3 cm.Moreover the power source would be DC +5 V

So far I have thought of creating small electromagnets with springs,but still not sure about it.Any inputs will be appreciated.

答:
You might consider a Bistable Solenoid. This is a solenoid where the plunger locks into position at either end of its stroke, so that the current only needs to flow to change the state of the solenoid. Usually the locking mechanism is a simple magnet, so the electric field of the solenoid can overcome it to cause the plunger to move.

The diagram shows a cross section through the design. The solenoid is at the bottom. Run the current one way, and the plunger magnet is pushed to the top, where it sticks to the steel tube. Stop the current, and the plunger stays in position. Reverse the current, and the plunger will be pulled back down.


问:
Repairing non-lubricated linear actuator
I have a Chinese CNC mill (CNC3020T, though several different devices go under this name), and its Z axis was very imprecise, often being randomly off position by as much as 0.5mm. I've disassembled the linear actuator and discovered several problems with it.

First problem is that they apparently forgot to lubricate the linear ball bearings. I make this conclusion because the rails have a set of grooves ground into them, and after wiping the rails with a tissue the only thing that is left is the finely powdered metal, with no traces of oil or other lubricant.

Second problem is the nut. I expected to see a ballnut, but in reality it is just a piece of threaded PTFE! The leadscrew rotates smoothly in it, but there is quite some lateral movement, i.e. I can tilt it slightly without any opposing force.

Third problem is the overall mounting. In the picture below, the top left screw has been sheared in the factory and then they hid their mistake by tapping a larger thread and putting in a shorter screw that doesn't actually hold anything in the top plate.  So the whole assembly was fixed in three, rather than four, points. However, the remaining screw was quite tight.

So my closely related questions are:

Is the assembly even salvageable? How do I verify that linear ball bearings, the PTFE nut are relatively undamaged?

Can I just rotate the rails by 45° to get smooth surface again?

What do I lubricate the linear bearings with? Do I clean them before lubrication? I have an ultrasonic cleaner.

Any other advice on maintenance of the whole assembly? There may be something that I missed.

答:
I've cleaned the bearings of residue using dimethoxymethane aerosol and lubricated them with PTFE-based oil lubricant. It works pretty well now.

More details here.


问:
translation the shaft encoder data
I am designing a robot in real world and i want to plot everything in X,Y (Cartesian) coordinates

I just want to use the encoders of wheels to determine the current position of mobile robot and its orientation depending on a specific calculation formula (like this http://rossum.sourceforge.net/papers/DiffSteer/ ) even if that will lead to inaccurate calculations .

Actually , I found out this formula below to compute x, y coordinates from encoder data but I still confused in some sides of this formula

I had a Rover 5 chassis form Dagu with two normal DC motors and two encoders (incremental rotary encoder) per each wheel, how could I translate the pulses of encoders or how to work out the x.y position of the robot based on the shaft encoder data.

I deduced some of values from Rover 5 chassis :

cm = conversion factor that translates encoder pulses into linear wheel displacement

Dn = nominal wheel diameter (in mm)
:
about 20 Cm

Ce = encoder resolution (in pulses per revolution)
:
Encoder resolution: 1000 state changes per 3 wheel rotations

n = gear ratio of the reduction gear between the motor (where the encoder is attached) and the
drive wheel.
:
Gearbox ratio: 86.8:1

In Rover 5 chassis there are 4 small wires with female headers. RED is +5V for the encoder , BLACK is 0V (ground) , WHITE is signal A , YELLOW is signal B . The important wires in each encoder are signal A and signal B ,so

How to get values of NL , NR  in the formula above from signal A & signal B ?

Is the value of NL is the direct value from  wire signal A or signal B ? the same question for NR .

Thanks a lot

答:
Encoders

These are quadrature encoders.

Quadrature encoders have two sensors that look at a rotating wheel with black and white bins alternating in regular intervals (or magnetic sensors looking at alternating magnets).
These two sensors are shifted relative to each other, so that when one looks at a center of one bin, the other is precisely at the edge between two bins.

Now, when the wheel spins, you will get a change on the sensors' outputs for every time one of them crosses the bin boundary. If you have $n$ bins, the value will change $2n$ times per rotation.
At any time at most one of the A or B values will change, and you can calculate direction of rotation from the pattern.
Also, if your microcontroller is not fast enough and misses a tick, you can detect this as both A and B changing value at once.

So, to get $N_L$ you will have to monitor the A and B signals from the left encoder and keep count of the changes. +1 for change in one direction, -1 for change in the other direction.
The same goes for $N_R$, only this time you do it with the right side encoder.

concerning the $c_m$ factor, you have specified that there are 1000 state changes per three wheel rotations. That means that your $c_m$ is wheel perimeter times $\frac{3}{1000}$.

Some more information about quadrature encoders is here: http://letsmakerobots.com/node/24031

Calculating $x$ and $y$

I believe it is more precise to replace equations (1.7a) and (1.7b) with

$$x_i = x_{i - 1} + \Delta{U_i} \cos (\theta_{i - 1} + \frac{\Delta\theta_i}{2})$$
$$y_i = y_{i - 1} + \Delta{U_i} \sin (\theta_{i - 1} + \frac{\Delta\theta_i}{2})$$

Title: translation the shaft encoder data


问:
it's worth to make a line follower using a raspberry pi and a web cam?
I wonder if this would be a competitive robot compared with one made with a traditional approach using a microcontroller and infrared sensors. I suppose that raspberry can perform an edge detection to tell the dynamic of the line far away, much more that the infrared sensor, but how fast can the raspberry do this process? should be a relative simple process in terms of computational requirements , an edge detection in a high contrast arena. Probably the bigger issue would be get the relative position of the robot respect to the line, may be a combination of the camera with some infrared sensors would work better, and what about the size? the robot will be significantly bigger when is used a camera and a raspberry for the control.</p>

答:
This may be overkill, but some of the past work I was involved in was trying to detect a vertical line (a pipe) in the camera's field of vision, and navigate relative to it.

The process was as follows:

Pick a threshold value, and split the image into black and white

Perform Canny edge detection on the image

Use a Hough transform to find the strongest lines in the image, and consider those to be the boundaries of the vertical strip you're looking for

Adjust for the perceived width (indicating distance -- you won't need this) and angle of the vertial strip in the image

We used OpenCV to do this.

We didn't get very good results at full camera resolution; The very pixellated lines in the image above were from downsampling the source video frame (by a factor of 3 in both directions, I think... so 1/9 the number of pixels to worry about).  This allowed us to process frames fast enough for it to be useful.  Also, the point of the initial threshold step was to speed up the Canny process -- fewer lines to find.


答:
Oussamma Khatib's potential field algorithms suffer from local minima/maxima finding problems vice global minima/maxima.  As such you will get trapped in "box canyons" where the potential field cannot escape.  You need to add extra algorithms on top of potential fields to avoid local minima paths.

I did my Master's thesis on artificial neural networks that avoid local minima and find global ones.  But there are lots of others to choose from:

Non-learning artificial neural network approach to motion planning for the Pioneer robot

DOI: 10.1109/IROS.2003.1250614

Available at IEEE (paywal)

Also available at academia.edu (non-paywall)

Title: Artificial Potential Field navigation

Body:
I've been working on my two-wheeled mobile robot I've been trying to perfect my obstacle avoidance algorithm which is Artificial Potential Field method . Also i use Arduino Uno kit . The basic concept of the potential field approach is to compute a artificial potential field in which the robot is attracted to the target and repulsed from the obstacles. The artificial potential field is used due to its computational simplicity. the mobile robot applies a force generated by the artificial potential field as the control input to its driving system . the Artificial Potential Field method in its computations depends on the distance between robot and goal or target and the distance between robot and obstacles that effected the robot (which could easily get for ultrasonic senors)

I applied the Artificial potential field method in Matlab environment / simulation and it is done successfully , really what I need in the simulation is to get the current position of mobile robot and position of goal as x, y coordinates (to compute the distance between robot and goal) and the obstacles positions.

The output of the Artificial potential field is the desired angle to avoid obstacle and reach to the goal , the method give the robot the angle the pointed to the goal then the robot goes toward that angle and if the robot face an obstacle in his way (got from sensor reading) the Artificial potential field will update the angle to avoid the obstacle and then re-give the robot the angle that pointed to the goal and so on.

The question is how could I apply the Artificial potential field method in real would? what should I get? is it easy to do that or it is impossible?

I had Rover 5 with two normal DC motors and two encoders (incremental rotary encoder) per each wheel.

Any Help or suggestion on the topic will be highly appreciated please.

Edit: Based on the response from Shahbaz.

The case is very simple, but first, there is something to know that I constrained with some limitations that I couldn't overstep them, one of them is that the real world should be exactly as simulation for example in the simulation I consisted that robot started with (0,0) on coordinates  x, y axis and I should put the goal point for example (10,20)  and feed this point in the Artificial potential field method and then compute distance between  robot and goal (so I don't need any technique to determine the position of goal) and I don't know if I could applied that.

The second constraint is that I should use the encoders of wheels to determine the current position of mobile robot and its orientation depending on a calculation formula (something like this here) even if that will be inaccurate.

I had a Rover 5 with two normal DC motors and two encoders (incremental rotary encoder) per each wheel, each encoder has four wires I don't know how to deal with them yet, and how could I translate the pulses of encoders or how to work out the x.y position of your robot based on the shaft encoder data.

I am still searching for ….


问:
How can I build a 10cm-200cm IR range sensor?
Everybody here is probably aware of the Sharp distance sensors (GP2Y0 series, e.g. GP2Y0A02YK0F). They use a diode to emit infrared light and measure the angle of the reflected light with a PSD (i.e. they do triangulation). They seem to be the only producers of this technology.

I am only aware of a few similar but incomparable devices (sensors of ambient light and distance or proximity like Si114x). Which other comparable products are out there?

Another way to ask this question: "What are the different ways to build a 10cm - 200cm range low-cost IR range sensor, and what is an example of each of those ways?"

答:
The range of the sensor is not the only characteristic you need to be concerned about.  Where are you planning to use the sensor? With what kind of reflective surfaces? Indoor? Outdoor? Both?  Against natural surfaces or sharp highly reflective like glass?   What shape of detected surface are you interested in - some return conical areas ahead.

You could use a passive infrared PIR sensor and a histogram algorithm for your rough area change detection.

A laser might be better for a linear range finding.

Perhaps some extra information on what you are trying to detect would help the answer.  Sorry for the half-answer but perhaps that inquiry will reveal a better solution.


问:
Single-shaft vs Double-shaft motors
I am trying to make a line follower robot and I need help regarding the type of dc motor to use.
So we have a single shaft BO Motor and a double shaft BO Motor. Can anyone help me understand what is the difference between the two?
Here's the link for
Single Shaft BO Motor:
http://www.evelta.com/industrial-control/motors-and-accessories/100-rpm-l-type-single-shaft-bo-motor

Double Shaft BO Motor:
http://www.evelta.com/industrial-control/motors-and-accessories/100-rpm-l-type-double-shaft-bo-motor

答:
A "double shaft motor" has "two shafts" that exit the motor case.
If you turn the motor on so the shaft spins and keep the motor case rigidly bolted in one position, there is one place where you can stand and see one shaft sticking out of the motor and pointed directly at you and turning clockwise.
Meanwhile, there is another position someone else can stand on the opposite side of the motor; that person sees the shaft sticking out of the motor and turning counterclockwise.
(Some people prefer to think of those two shafts as two ends of a single shaft -- they have a good point, since both shafts are part of a single rigid cylinder of metal).

(double shaft motor http://www.myrcstation.com/webshaper/store/viewProd.asp?pkProductItem=5797 )

A "single shaft motor" has a shaft that only sticks out in one direction.

Often the only difference between some "double shaft motor" and a closely related "single shaft motor" is how far out the "other" shaft sticks out.
Often there is a hole in the case of a single shaft motor, where the other shaft would have stuck out, if it were a double shaft motor.
In the single-shaft version of that motor, you can typically you can see, through that hole, the end the shaft turning -- but the shaft doesn't stick out far enough to do anything useful.

Often people put some sort of drive wheel on one shaft of a double shaft motor, and put a position-measuring encoder on the other shaft.

Most applications only require a single shaft motor.
Often such single-shaft applications work fine with a double shaft motor (with the unused shaft not connected to anything).
So when I see that it's the same price either way, I generally choose a double shaft motor -- that way I can use that motor in both single-shaft applications and double-shaft applications.

.... battery operated (BO) motor ...

Title: Single-shaft vs Double-shaft motors


答:
In general, visual odometry is a method that performs odometric measurements using visual means. This rules out the SLAM component, since visual odometry is only a relative means of navigation (see my answer on navigation). There are a number of methods to extract the relative motion of the camera. Since the transform from camera to robot is known this will also give you the relative transform of your robot.

If you only work with a single camera, you will always have a scale ambiguity, unless you have something to resolve that ambiguity in your image (e.g. object of known size) or combine it with another form of odometry like wheel odometry.

From a vision point of you, there are two ways you can follow: dense and sparse processing. Dense processing means, you use a regular sampling of your image points for your processing (could also be the full image). Sparse processing would mean, that you first extract feature points and only perform your operations on these features.

Using optical flow for visual odometry, I would consider a dense approach. Once you got the flow field, you need to extract the motion components. This is not so trivial, as it largely depends on how your environment looks. There was an interesting way of resolving this in the presence of outliers presented in "Monocular Heading Estimation in Non-Stationary Urban Environment"

Sparse approaches will use features, which are extracted using feature detectors. Then there are two different methods on handling the features. First approach will perform tracking of the feature and in this way estimate where the scene point was moving to. Second approach performs association of features through feature descriptors. First one is usually used with fast algorithms on high frequency, while the second one is more robust to larger scene changes and hence can be run at lower frequency. The visual odometry on the MER Rovers works this way e.g. Some form of geometric constraint is used to remove outliers, usually with a form of RANSAC. There is quite a nice library called libviso2 for performing visual odometry this way.

Title: Visual Odometry options?

Body:
What are the pros/cons of the different visual odometry options?

Stereo Camera

Optical Flow

SLAM

other?

Criteria:

how well it performs vs other odometry options/sensors (lidar, radar)

sensor fidelity

computation

accuracy

precision

drift

native resilience and repeadability in sensor noise or vehicle speed

ease of integrating with IMU/GPS

etc

In general, of course, because there are a lot of different ways the trade-offs go when we get into specifics about applications and hardware.  I'm asking out of curiosity, not for designing anything in particular.


问:
Counts of Quadrature Encoder
Simply, I had Rover 5 with 2 DC motors and 2 quadrature encoders, I just want to use encoders to measure the distance of travelling for each wheel.

To start with, I just want to determine the total counts per revolution. I read the article about quadratic encoder from this broken link.

In Rover 5, each encoder has four wires: red (5V or 3.3V), black(Ground), yellow (Signal 1) and white (Signal 2). I connected each wire in its right place on Arduino Uno board, using the circuit:

rotary encoder ChannelA attached to pin 2

rotary encoder ChannelB attached to pin 3

rotary encoder 5V attached to 5V

rotary encoder ground attached to ground

For one encoder, I test the code below to determine the total counts or ticks per revolution, the first program by using loop and second by using an interrupt.

Unfortunately while I run each program separately, rotating the wheel 360 degree by hand, the outputs of these two programs was just "gibberish" and I don't know where is the problem . Could anyone help?

Arduino programs posted below.

First program:

```<code>// Constants
const int  ChanAPin = 2;    // pin for encoder ChannelA
const int  ChanBPin = 3;    // pin for encoder ChannelB

// Variables
int encoderCounter = -1;   // counter for the number of state changes
int ChanAState = 0;         // current state of ChanA
int ChanBState = 0;        // current state of ChanB
int lastChanAState = 0;     // previous state of ChanA
int lastChanBState = 0;    // previous state of ChanB

void setup() {
  // initialize the encoder pins as inputs:
  pinMode(ChanAPin, INPUT);
  pinMode(ChanBPin, INPUT);
  // Set the pullup resistors
  digitalWrite(ChanAPin, HIGH);
  digitalWrite(ChanBPin, HIGH);

  // initialize serial communication:
  Serial.begin(19200);
  Serial.println("Rotary Encoder Counter");
}

void loop() {
  // read the encoder input pins:
  ChanAState = digitalRead(ChanAPin);
  ChanBState = digitalRead(ChanBPin);
  // compare the both channel states to previous states
  if (ChanAState != lastChanAState || ChanBState != lastChanBState) {
    // if the state has changed, increment the counter
      encoderCounter++;
      Serial.print("Channel A State = ");
      Serial.println(ChanAState);
      Serial.print("Channel B State = ");
      Serial.println(ChanBState);
      Serial.print("State Changes = ");
      Serial.println(encoderCounter, DEC);
    // save the current state as the last state,
    //for next time through the loop
    lastChanAState = ChanAState;
    lastChanBState = ChanBState;
  }
}
</code>```

The second program (with interrupt)

```<code>static long s1_counter=0;
static long s2_counter=0;

void setup()
{
  Serial.begin(115200);

  attachInterrupt(0, write_s1, CHANGE); /* attach interrupt to pin 2*/
  attachInterrupt(1, write_s2, CHANGE); /* attach interrupt to pin 3*/
  Serial.println("Begin test");
}

void loop()
{
}

void write_s1()
{
  s1_counter++;
  Serial.print("S1 change:");
  Serial.println(s1_counter);
}

void write_s2()
{
  s2_counter++;
  Serial.print("S2 change:");
  Serial.println(s2_counter);
}
</code>```

答:
You're likely getting something analogous to "contact bounce".
When you slowly rotate the wheel,
there are regions where channel A is Lo for a while,
then channel A is Hi for a while.
While it would be nice if the Arduino only saw one low-to-high transition
between those regions,
often a encoder will oscillate a few or a dozen times
during the brief period when the encoder is balanced on the edge of the transition.

Have you noticed that the original code always increments the counter, never decrements it?
If you had code that
handled both forward rotation (clockwise; incrementing the counter) and reverse rotation (counterclockwise; decrementing the counter),
it would automatically fix the "bounce" problem.

One popular approach: while B is low, low-to-high transitions on A increment the count,
while high-to-low transitions decrement the count.
Then if A bounces a few extra times while B is low --
instead of a crisp Lo-Hi (+1), it does Lo-Hi-Lo-Hi-Lo-Hi (+1, -1, +1, -1, +1) --
we still get the correct final count.
In either case the final result is one count more.
(While B is high, low-to-high transitions on A decrement the count, etc.)

A quick Google search
https://www.google.com/search?q=arduino+quadrature+encoder+library
shows many quadrature encode libraries for the Arduino.
Many of them are reviewed at
http://playground.arduino.cc/Main/RotaryEncoders
.

Could you maybe try one of those libraries and tell us how well it worked (or didn't work) ?

Title: Counts of Quadrature Encoder


问:
Machine Vision vs Computer Vision?
I'm trying to understand the core differences between the two topics.  Is one simply a newer term?  Connotations of automobile vs automation?  Something with a screen vs without?

I've only ever heard the term computer vision (tagged).

答:
These are two different things which share a lot in common.

Simply spoken the CV's task is to perform automatic image processing and then display it to humans.

The MV has to do similar things but you do not get an image as result, you get data.
For example: "There are 6 apples in this image" or "The image shows that the product has a malfunction"

Sources:
http://www.visiononline.org/vision-resources-details.cfm/vision-resources/Computer-Vision-vs-Machine-Vision/content_id/4585

Title: Machine Vision vs Computer Vision?


问:
What laser power for cutting and engraving wood and Acrylic robot baseplates?
Need to buy a DIY/High School grade laser cutter/engraver

How much laser power is needed for wood, acrylic (3 to 6mm thick), cutting and decorative engraving?

What parameters I need to take care in selecting suitable machines?

答:
For such results the laser should have a power of 2-3Watts

You can have a look at different projects like this here at kickstarter:
https://www.kickstarter.com/projects/1537608281/lazerblade-the-affordable-laser-cutter-engraver


问:
Is a Genetic alogorithm suitable for mobile robot path planning?
Regarding my project work, I have to write an algorithm for mobile robot planning. For that, I have chosen Genetic algorithm. Is it good for mobile robot path planning? If it is, then where can I start from and get some guidelines?</p>

答:
This question is pretty general.

There is an online course available at edx:

https://courses.edx.org/courses/TUMx/AUTONAVx/2T2014

Where they explain different possible solutions and their implementations.
This course is pretty good


问:
Dynamic tracking precision of UR5/10
I am willing to use a universal robot arm (UR10) in a path following mode. i.e. I have a desired trajectory for the robot's effector and I would like the effector to follow it as close as possible.

The specs here give a repeatability of +-0.1mm. This is not written but I guess this is the static precision (after the robot had enough time to converge to the position). Now what about the dynamic precision (i.e. max position error while performing the desired trajectory)?

Does anyone know more than me on this matter?

Kind regards,

Antoine.

答:
I've got two Universal Robots guys in the room with me here, so I asked them this question.

When the robot's performing a Trajectory move (e.g. linear move) then the dynamic precision is the same as the static precision (±0.1mm). The robot would need to be set up correctly, and know the weight of its payload, so it can correctly balance itself.

When the robot's performing a Joint move, where you simply command each joint to move to a certain angle, then precision is obviously irrelevant, since the trajectory is unknown.

Title: Dynamic tracking precision of UR5/10


答:
The short answer is no -- genetic algorithms are not good for path planning.

The longer answer is that while a genetic algorithm is very likely capable of solving a path planning problem, it's a very inefficient way to do so.  Genetic Algorithms are preferred in problems where there are many input variables and the interaction between those variables is complicated.  (A popular example of a Genetic Algorithm problem is the antenna shape that was "evolved" to produce the proper radiation pattern.)

Rather than trying to maximize the "fitness" of a set of inputs (as Genetic Algorithms do), in path planning you are trying to minimize the "cost" of getting to your end state -- finding a set of movements (the length of which is unknown at the start) to accomplish that goal.

If, on the other hand, you were trying to find an algorithm that could help a robot learn how to move, then the evolutionary approach is fine.  The example that comes to my mind is the robot from Cornell that can teach itself to limp when it stops being able to walk (PDF of some of their work is here).

Title: Is a Genetic alogorithm suitable for mobile robot path planning?

Body: Regarding my project work, I have to write an algorithm for mobile robot planning. For that, I have chosen Genetic algorithm. Is it good for mobile robot path planning? If it is, then where can I start from and get some guidelines?</p>


问:
Expression used with Rotary Encoders
While I am reading and collecting information about rotary encoders , I faced some troubles about the meaning of some expressions concerned with encoder ,which make me to be confused and stray,  these expressions or words are :

-Count per revolution (rotation)

-Pulse per revolution

-Tick per revolution

-Transitions per revolutions

-Number of transitions

-Number of state changes

I thought the transition is same as state changes which means change from high to low or low to high , but what about the others what is the diffenece among them (count , tick ,pulse ,transition .... etc)? and what the relationship between transitions and pulse ? Could anyone clarify that , please

答:
A quadrature encoder has two output channels.

Pulses per revolution

Looking at one output channel of the encoder, the number of pulses per revolution is the number of rising edges per revolution.

Counts per revolution

Combining the two encoder outputs, and counting every rising and falling edge gives the number of counts per resolution.

CPR = 4 x PPR

As for Transitions and State Changes per revolution, I would guess that these are equivalent to Counts.

Title: Expression used with Rotary Encoders


答:
My feeling is that a genetic algorithm wouldn't be a good way to do path planning. GAs are better at searching crazy multi-dimensional discontinuous spaces. On the other hand, path planning for a mobile robot just isn't that hard.

You didn't say what kind of robot this was going to be, but for 2D mobile robots, there are already several excellent path planning algorithms around, like A*.

My preferred robot path planning method starts with something like A* to generate a first path through the map. Then I would convert that into a piecewise linear path, and use an iterative algorithm on the path to straighten it out, and adjust the velocity, acceleration and jerk along the path to optimise it.

Having said that, people clearly are using GAs for path planning.


问:
Selecting an accelerometer for Deduced Reckoning
I have never used an accelerometer before, but I am aware that they come with I2C, SPI and analog outputs. If I choose to use an I2c or SPI, device, will I accumulate errors due to communication time?

Is the fast sampling of an analog signal likely to get me a more accurate deduced position than using am I2C?

Will this be true for

A robot moving in a room

A robot moving in an outdoor terrain and is likely to slip and roll down a slope.

Also, I have no sense of Gs. I tried to move my hand around fast with my phone running andro-sensor in my fist and saw that the readings saturated at 20m/s2. What G can I expect my robot to experience if it is hit by another fat moving bot or bumped by a fast walking human?

答: From your question I figure you are trying to get your position from the accelerometers. Have a look at what sort of errors you are expecting before, and then maybe reconsider. Position estimation has very large errors, mainly due to the uncertainty in the orientation. The application in ships, planes, rockets etc use very expensive high precision navigation grade IMUs. The latency, which your question boils down to is not so much of a problem. More relevant is the synchronization between your other sensors (e.g. Gyros). Accelerometers are usually not used for position estimation (there are some cases where it helps, but only for short periods), but rather for compensating gyro drift in orientation estimation. You can also use them directly to estimate your orientation, but then your estimate is perturbed by dynamic accelerations. </p>


问:
Denavit-Hartenberg parameters for SCARA manipulator
I'm going through the textbook Robot Modeling and Control, learning about the DH convention and working through some examples.

I have an issue with the following example. Given below is an image of the problem, and the link parameter table which I tried filling out myself. I got the same answers, except I believe there should be a parameter d1 representing the link offset between frames 1 and 2. This would be analogous to the d4 parameter.

If anyone could explain why I might be wrong, or confirm that I have it right, that would be great. I hate it when it's me against the textbook lol.

Cheers.

答:
You are right he made a mistake there.

This is probably one of many typos in this preprint of Mark Spong. You should rather turn to other good books, such as the mathematically more elegant book of Richard Murray,Zexiang Li and Sankar Sastry, A Mathematical Introduction to Robotics Manipulation (MLS94). The mathematics they use is consistent in other of their books such as Yi Ma, etal An Invitation to 3D-Vision. screw theory and Lie group theory instead of Denavit and Hartenberg's minimal approach are used in the book. It is much more superior than the D-H approach, and is widely adopted in the academia (the industry is another story).

Finally, a bonus is that the book MLS94 is completely free to download (under an agreement with the publisher CRC press). It also did a terrific job in systematic treatment from kinematics to dynamics to control.

Edit:

I shamelessly refer to one of our not-so-recent publication on robot kinematics calibration, in which you may find additional information on how one may switch between screw representation and DH parametrization of joint axes. The point is, one can easily deal with parametrization singularity of DH parameters if he/she looks at the problem from a geometric (differential geometry of Lie groups) aspect.


问:
PID in a system with pole at origin
I've seen in a lot of places some methods of tuning a PID controller. Most of them will say that one should apply a step input to the system and based on that response you can tune the PID parameters following some rule of thumb. But what about a system which one of its pole is at origin? In other words, a step response on a system like that will have an infinitely increasing ramp in the output (theoretically).

An example:

let's say we have a spinning wheel (fixed at center) and all we can control is the amount of torque applied to make it spin. If we can read its position (angle) and we want to design a PID controller to set its position (more or less like a step-motor). How can that be done? Note that a step input in this case will be a constant torque and this will make the wheel spin faster and faster. How should one proceed?

答:
There shouldn't be any reason a standard pid couldn't function in the example you gave. As long the position is being sampled at a reasonably high rate. If the pid in your system was only updated at .5 hz then the pid might have a problem keeping the wheel from over accelerating. However, if that's the fastest your system can sample the pid algorithm then I suggest stop using an under-clocked 4040 (or a MC14500 for that matter).

Now let's say you had this system, and you wanted to balance it upright. A bare pid wouldn't work so well here because it would overshoot near the top and not apply enough torque when perpendicular to the ground. The solution would be to realize that the torque required to hold it in place would be cos(angle to ground) * mass at end. If you had your theoretical system always apply that much torque, then applying a pid on top of that could work quite well (if T = cos(θ) * M + x where T is the applied torque then altering x will produce the same acceleration no matter what *θ is).

Title: PID in a system with pole at origin


问:
Arduino Power Supply
I want to power my Arduino Uno and I know I can do that either by connecting it with USB to PC or with DC power supply.But I want to connect it with a battery source(kindly see the image below) and I know its a silly question but how do I do it? The battery connector is not the regular DC jack but the one that's found in RC toys. So how do I power my Arduino with that battery?
And also how do I connect it with a DC power supply adapter to charge it once its discharged? Please also mention the specifications of the DC power supply adapter that is to be used while charging this battery.

答:
There are two main ways to power an Arduino: with 5 volts and with 6.5 to 12. Since your case falls under the 6.5 to 12 option there are two main ways you can get power into an arduino. The barrel jack can be plugged into a 6.5/12v source which works well. I have a habit of chopping the connectors off wall warts then I use the power supplies for other things (or sentence them to a life collect dust). If you take this route make sure the center pin is being fed positive voltage and the outside is ground.
The easier option here is probably to feed your 6.5/12v into the pin labeled vin. It is right next to one of the grounds, and is electrically connected to the barrel jack.

If your battery's JST connector is the right size you might be able to use .1 inch headers to plug it into your arduino (unlikely but possible). Otherwise I suggest you buy a JST breakout board. You said that you want to be able to take out and charge your battery which rules out soldering stuff to it. Unless you want to put a barrel jack on your battery, I suggest investing in a JST breakout.

The battery it's self looks like a LiPo (lithium-ion polymer) or Li-ion (lithium-ion), which means that you need to buy a charger for it. Lithium batteries have a bad habit of exploding when mistreated, so DIY chargers are for the suicidal. Just from the picture it looks like a Li-ion , but that's just a guess. You should really figure out what type of battery it is before going further with it. When you do figure out what type it is, buy a charger for it.

Title: Arduino Power Supply


问:
Motor control using arduino/raspberry pi
I'm new to robotics. I would like to know if 56 output lines can be taken from an arduino or raspberry pi?</p>

答:
From the Arduinos only the "DUE" will work.
It has 54 Digital IOs and 2 Analog Outputs.

The newest raspberry has "only" 40 IOs, so it won't fit your specs.

Another possibility would be the "BeagleBone Black" with up to 69 IOs.

http://www.raspberrypi.org/product/model-b-plus/

http://elinux.org/Beagleboard:BeagleBoneBlack

http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardDue


问:
Why models are not perfect to represent robotic environments?
Sebastian Thrun says in his paper on Particle Filters that - no model however detailed fails to represent the complexity of even the simplest of robotic environment. What does he means by this? Can someone please elaborate?</p>

答:
A model of the environment in this context is an abstraction of the real world, which should be adequate for the task of the robot. For example, if you have a robot that needs to navigate an office building, you can make the abstraction that your model only needs to be in two dimensions. Further, for the task of navigation you could discretize your space in a regular grid, and just model if cells of your grid are occupied by dense matter (e.g. walls, chairs, people) or by light matter (air) above the ground. This environment representation (model) is usually called a map.

What Thrun refers to is likely that your model only records particular aspects of your environment. Its an abstraction. This is good, to make it manageable from a computational and representational aspect. However, and this is in my opinion the key of the statement, its limited in the real world. For the office building example given above, you can easily come up with examples where the models breaks. How do you represent for example a table. A robot of a certain height may actually go underneath. How do you represent the temporal aspects. A chair might be at another position at another time. All possible to manage, but you will always find exceptions to your chosen abstraction in the real world.

Interesting in this context is for example the work from Brooks. He postulated to use the world itself as a model instead of a using abstractions that ultimately fail to represent the world adequately.


问:
What are the advantages of using the Denavit-Hartenberg representation?
When one wants to model a kinematic chain and in particular define the frames attached to each body, it is common to use the Denavit-Hartenberg parameters.

What are the advantages of this representation?

I can understand the interest of having a normalized representation but does it impact the algorithms performance?
The algorithm is not trivial to implement, what gain can we expect from this instead of, for instance, just fixing reference frames by hands (i.e. arbitrarily) like this is done in many robotics formats such as URDF.

答:
Aside from getting the final result as a composition of matrix multiplication, which helps a lot indeed, one crucial aspect of DH convention is the possibility of describing a rototranslation in terms of 4 variables only for each link (namely, the link length, twist, offset, and the joint angle), in place of the canonical 6 (i.e. 3 for translation and 3 for rotation).

To sum up, given that in DH we can conveniently assign the location of the subsequent reference frames complying with the specified standard, we are thus able to compact the representation: e.g. for a anthropomorphic manipulator equipped with 7 degrees-of-freedom, we can deal  just with 7*4=28 independent variables/parameters instead of 7*6=42.


答:
Something I've heard said many times (by a WHOI scientist, I think) is that

The problem with models is that they work.

In other words, the only things that can go wrong in a model are the things you put into the model ahead of time.  Your model may give you perfect results, but in the real world any number of strange things can go wrong; the world is a very complicated place.

Watch this entertaining presentation by Katy Levinson for a few examples.

Title: Why models are not perfect to represent robotic environments?

Body: Sebastian Thrun says in his paper on Particle Filters that - no model however detailed fails to represent the complexity of even the simplest of robotic environment. What does he means by this? Can someone please elaborate?</p>


问:
Comprehensive comparison of SLAM algorithms
I'm looking for a research paper or series of papers that compare the performance of various simultaneous localization and mapping algorithms for rovers in a variety of real world environments.  In particular, i'm looking for computational speed, accuracy (compared to the real world environment) and memory & power efficiency metrics.  Is there a journal that regularly publishes experimental performance comparisons?</p>

答: The Journal of Field Robotics is likely the closest to what you are asking for. Its one of the highest ranked journals in robotics, and requires the articles to have a significant part of field experiments. I don't recall a comprehensive SLAM survey article, though. </p>


问:
How can the dynamic effects of motor current on a digital compass be characterized and compensated for?
Digital compasses (magnetometers) require a hard/soft iron calibration in order to be accurate.  This compensates for the magnetic disturbances caused by nearby metal objects -- the robot's chassis.

(image from http://diydrones.com)

However, digital compasses are also susceptible to the electric fields caused by the relatively high amount of current drawn by motors.

In order to get an accurate compass reading, what is the best way to measure (and compensate for) the interference caused by changing motor current levels?

答:
Generally, this is not possible. This is because motors usually rotate very rapidly, creating rapidly fluctuating magnetic fields. Whether the disturbance is enough depends on how large the motors are.

For example, because I mounted an IMU (Inertial Measurement Unit) with magnetometers near some motors, and was forced to turn off the magnetometers to avoid the measurement affecting the state estimation.

In practice, the solutions most likely to solve your problem is:

move the compass/magnetometer away from from the motors

use shielding material (basically material with high magnetic permeability). They do not block magnetic fields, but because they provide a path of low magnetic resistance, they attact the magnetic field (lines from north to south) to pass through their interior, so that the magnetic field intensity is lower elsewhere.

The best shape for magnetic shields is thus a closed container surrounding the shielded volume. The effectiveness of this type of shielding depends on the material's permeability, which generally drops off at both very low magnetic field strengths and at high field strengths where the material becomes saturated. So to achieve low residual fields, magnetic shields often consist of several enclosures one inside the other, each of which successively reduces the field inside it. - Wikipedia/Magnetic shielding

You can thus wrap the motors in shielding material, such as:

Giron

MagnetShield

PaperShield

Magnetic Shielding Foil

Mag-Stop Plates

MetGlas

JointShield

Finemet (for kHz frequency fields)

CobalTex

A good site for comparison of these materials is LessEMF.com Magnetic Field Shielding

It is theoretically possible to correct for the magnetic disturbance without shielding. We do need to be aware that there are two possible sources - a rotating permanent magnet and/or current in the coils. If we have feedback of the rotor position, we can correct for the permanent magnet or coil position. If you perform some experiments, recording current and rotor position, you should be able to fit a model of the magnetic field. Fitting is necessary because the actual field strength is very hard to calculate because of how the magnetic field looks depends on the size and shape of both the magnet and coils.

In practice, it is difficult to do this - unless the motor is turning very slowly and your sensor and model is accurate enough. First, if the frequency is high, it can cause problems because of synchronization issues and communication delays. If you cannot synchronize the data obtained from the motor feedback (position and current) and that from your magnetometers, you will increase your uncertainty. Even if the frequency is low, you need to have good control of the accuracy of:

the magnetometer

the model

the inputs to the model (position and current)

If any of the above are not accurate enough, the residue magnetic field (assumed to be the earth's magnetic field) could be very inaccurate.

In general, accuracy can be decreased by:

frequency

motor field strength (since for the equation $residue magnetic field = raw measurement - motor model$, if the two terms on the right hand side are large, even at 1% accuracy, taking the difference could result in large left hand side uncertainties)

sensor resolutions


问:
How to filter vibration programatically?
I'm working on a quadcopter. I'm reading the accelerometer and gyro data out from the MPU6050 and using complementary filter to calculate the roll and pitch values. When the quad is on the floor, and the motors are turned on the roll values are:

```<code>-4.88675227698
-5.07656137566
 7.57363774442
-3.53006785613
 4.44833961261
-2.64380479638
-3.70460025582
</code>```

It is very messy. After minus five there is plus seven. I would like to filter out this too high/low values programmatically but I have no idea how to do it.

EDIT:
At this moment I think the solution is the Low-pass filter. I'll let you know if it is successful or not.

答:
I faced similar problem ,

My solution was:-

1- Record raw data for mpu6050 (6 DOF) , the chip should stay stable
with no move

2- Apply kalman filter ( one dimensional on each data type , we are
not trying to fuse data here .. ok :) )

3-Now you have a noiseless raw data that represents that the status
with no move or (vibration)

4-Calculate the standard deviation for each type of data i.e
(standard deviation for X axis, Y axis ... ) , you can also calcualte
the standard deviation for multiple trials and finding the mean or
average for them

5-Say we got 25 as standard deviation for X accelerator axis , you
will put a condition

```<code>if(current_reading - previous_reading >
   standard_devaition)  { accept this data as it doesn't represent
   vibration  }
</code>```

Body:
I faced similar problem ,

My solution was:-

1- Record raw data for mpu6050 (6 DOF) , the chip should stay stable
with no move

2- Apply kalman filter ( one dimensional on each data type , we are
not trying to fuse data here .. ok :) )

3-Now you have a noiseless raw data that represents that the status
with no move or (vibration)

4-Calculate the standard deviation for each type of data i.e
(standard deviation for X axis, Y axis ... ) , you can also calcualte
the standard deviation for multiple trials and finding the mean or
average for them

5-Say we got 25 as standard deviation for X accelerator axis , you
will put a condition

if(current_reading - previous_reading >
   standard_devaition)  { accept this data as it doesn't represent
   vibration  }


问:
What would be a good heuristic to solving this?
The aim is to guide a bot from Source S to Goal G while passing through all the checkpoints @ (in any order).

```<code>########
#@....G#
##.##@##
#..@..S#
#@.....#
########
</code>```

One way to solve it would be to select one checkpoint as goal from current state and then guide the bot to it. Then select the next checkpoint as goal and current checkpoint as source and guide the bot to its new goal. Eventually guide it to the state G from the last checkpoint.

But this technique relies heavily on the order of checkpoints traversed.

 I would like to know if a good heuristic can be found to decide which checkpoint to go to next?

答: This type of problem is called the travelling salesman problem, which is a heavily studied problem. The wikipedia entry lists a few heuristics in the middle.</p>


答:
Usually, what happens in practice is that you barely have access to the commanded torque. Instead, you can control electrical quantities, such as voltage and/or current, that in a electrical motor can be readily related to the torque applied to the shaft. This is to say that further dynamics appear in the response and thus the PID should be aware of them.

For example, a DC electrical motor is well described by the following transfer function:

$$
F(s)=\frac{\theta(s)}{V(s)}=\frac{K}{s\cdot(1+\tau s)},
$$

where $V$ is in the input voltage and $\theta$ is the measured angular position of the motor shaft. To a certain extent, by neglecting the elasticity of the gearbox, one can also apply the same plant model to a system where $\theta$ refers to the joint encoder measurements.

As you can see, there is still a pole in the origin, but this is not a real problem for the identification. So, before tuning the PID, it is always a good rule to understand what kind of system we are dealing with to then ground whatever approach we have in mind on the basis of the knowledge we have of such a system.

To come back to the point, the unknown parameters $K$ and $\tau$ account for the DC gain and the dynamical properties of the system, respectively. To find good values for $K$ and $\tau$ you can consider relying on a least-squares identification method (in its batch or recursive implementations) or even on the Extended-Kalman-Filter estimator (EKF).

The EKF technique can be profitably applied to the state-space system whose transfer function is $F(s)$, augmented of two further states representing the evolution of $K$ and $\tau$ which is in turn implicitly assumed to be constant (i.e. with null derivatives).

Given the template $F(s)$ of your system, you can then inject proper input signals (e.g. step-wise, chirp, pulse trains), measure the output angular position, go through the identification methods and determine good representative values of the free parameters. Once done with that, put the model to test by assessing its performance when stimulated by signals you did not employ in identification (e.g. by varying both the input amplitude and input waveform).

Particular care should be taken for estimating the working area where the system behaves linearly and where your model is supposed to generate good response profiles (e.g. check if the actuator intrinsic nonlinearities have an impact or not). If you experience significant deviations between the measurements and the predictions, then you have to refine the model (e.g. increase model order, introduce dead-time ...).

What's the reason why we struggle to find a good representation of the plant? Because, of course, the model provides us with an easy way to tackle the PID tuning problem. You can resort to simulation, to well-established rules available in literature or even to simple considerations as below.

The P design may turn out from the requirement of tracking a reference signal whose frequency content is limited to the band $\omega_c$. Therefore, we have to equate $\left|F(j\omega_c)\right|$ to 1, hence:

$$
\left|\frac{K_PK}{j\omega_c(1+j\tau \omega_c)}\right|=1,
$$

from which we get:
$$
K_P=\frac{\omega_c}{K}\sqrt{1+\left(\tau \omega_c\right)^2},
$$

where $K_P$ is the proportional gain.

Since the system is already equipped with an integrator (i.e. the pole in the origin), we don't need the integral part of the PID, thanks to the so-called internal model principle. Nonetheless, for disturbance rejection purpose, one can design the I part under some mild conditions as:

$$
K_I=\omega_{dr}K_P-\frac{\omega_{dr}^2\left(1-\tau \omega_{dr}\right)}{K},
$$

where $K_I$ is the integral gain and $T_{dr}=3/\omega_{dr}$ is the time period wherein a step-wise disturbance is required to be canceled out.

For instance, the scenario described by daweim0 will definitely require the integral gain to have zero steady-state error while counteracting the gravity component. The feed-forward term will be very helpful too.

Title: PID in a system with pole at origin

Body:
I've seen in a lot of places some methods of tuning a PID controller. Most of them will say that one should apply a step input to the system and based on that response you can tune the PID parameters following some rule of thumb. But what about a system which one of its pole is at origin? In other words, a step response on a system like that will have an infinitely increasing ramp in the output (theoretically).

An example:

let's say we have a spinning wheel (fixed at center) and all we can control is the amount of torque applied to make it spin. If we can read its position (angle) and we want to design a PID controller to set its position (more or less like a step-motor). How can that be done? Note that a step input in this case will be a constant torque and this will make the wheel spin faster and faster. How should one proceed?


问:
Continuous or Discrete
I am new to robotics and control and I have been thinking about how to deal with problems in real life. I have passed a course in control, but I do not have any idea about control for discrete/digital systems.

There are a lot of robots and in general dynamic systems which are controlled by microcontrollers or computers with some software, i.e. simulink. Usually there are sensors which send feedback to the microcontroller or the computer and the controller sends a signal w.r.t the input signal from sensors. I was wondering how we decide if the system is discrete or continuous? How one can decide if he should use discrete or continuous blocks in simulink to control a dynamic system. Does it really matter which one we use?

After all computers are digital and I think it is easier to work with digital signals and also  do we really have continuous signal? I have not passed any signals course, so my questions might be really easy. I did not find any other place for my question.

答:
Complex systems of differential equations governing a physical phenomenon under study are solved by means of a computer always in a discrete way, meaning that the differential equations are integrated step-wise with the integration steps decided according to some smart set of rules. This does happen therefore also within Simulink and even when you select continuous mode from the Solver panel.

What does really matter when you switch to discrete mode is that you plug in the simulation the fact that you use a real-time device (e.g. typically a controller) to deal with your task.

In simulation (e.g. in Simulink) you can even disregard the fact that you have such devices and focus on how the physical phenomena take place and evolve over time. However, whenever you have to implement the simulated controller you came up with into a real embedded system working under real-time constraints (e.g. the C++ code running on the Linux aboard your quadcopter), then you have to carry out the discretization stage.

A discretized system is not an exact copy of its continuous ancestor of course, depending the differences on the transformation you applied (e.g. Tustin, forward Euler formulas). Roughly speaking, the continuous mode gives us a more informative perspective on a system than its discrete counterpart, since it embeds all the behaviors the system can expose in the limit of the sample time approaching zero. Nevertheless, a code written for a machine cannot handle explicitly the notion of such a limit and will certainly make some approximations which may or may not be valid for your problem. Thus, always remember: never be happy about your results! Even if you enable continuous mode, the outcome might turn to be a too coarse estimation of what is going on in reality.

Simulink and other modern environments allow users to:

focus on the physics and controller design (continuous mode);

focus on the design of controllers to be deployed in real embedded devices (discrete mode);

evaluate the overall performance of the controller along with the plant (hybrid mode), where the controller is discrete and the plant is meant to run at much faster frequency (practically continuous).

As result, a typical work flow could be the following:

Continuous mode: simulate the plant given the set of its differential equations.

Continuous mode: design a controller for such a plant by optimizing some merit costs.

Discrete mode: discretize the controller and validate the final performance.

Discrete mode: deploy the controller's law in the embedded unit.

If you are not interested in code deployment or in assessing the effects of discretization, but you'd like rather to simulate the physics, you could stay "continuous". Conversely, if you deal with systems that are intrinsically discrete, the suggestion is of course to start already in discrete mode.

Philosophically speaking, continuous vs. discrete can represent a sort of dualism in engineering like the much more famous wave vs. particle dualism in nature: a continuous signal must be sampled to be handled by a digital machine, but a discrete signal remains physically continuous because sharp transitions link the digital levels. Even a switching state can be seen as a very quick voltage transition. It depends on the level of details we are interested in.

Title: Continuous or Discrete