问:
Detect physical touch/hit
I'm making a target to an outdoor robot competition.

The target should detect if some of the robot got touched or got an hit   automatically. and the target can get hit 360 degree.

I'm searching for the perfect sensor to detect an hit, without get false positive from a wind.

My option right now are:
1- ultrasonic sensor (bad coverage)
2- tilt sensor  (bad FP rate)
3- wooden conductive

I would like to know if someone has other ideas (that affordable - less than 30$ dollar per target might be o.k)

Edit: the target is static, and just waiting to a robot to touch it.

Edit: The specs are:

1- The target dimension is 1 meter height, 0.5 meter width , 0.3 depth.

2- To trigger the target ,the robot should be around 10 centimeter long to any point of the target surface.

3-To trigger the target the robot needs to get close up to 10 centimeter or even press with around 1 Newton force. the robot might even throw an object that satisfy the previous condition.

4-Detection must be only from intentional touch.

5-Wooden conductive is trigger because a human is Electrically conductive. this might not be the option when we throw an object.

6- Target will be placed outdoor, so the sensor need to be wind-resistance (not extreme wind condition- just around 20-25 km/h)

7- I  prefer a sensor that detect touch (more than proximity)because it might make my solution more cheap and reliable(in factor of amount sensors as i estimate).

Thanks.
Guy

答:
You could use a micro-switch if you're looking for touch sensing rather than proximity. Check this link out for more info (Its an example):
https://www.arduino.cc/en/tutorial/switch

The advantage (and disadvantage) of this switch is that it requires very little force to activate. Which also means that application of large force can cause the switch to get stuck or break. But with the description of the problem you've provided, I think this will help you out.

Title: Detect physical touch/hit


问:
In EKF-SLAM, why do we even need odometry when there is a more reliable sensor?Also, are all SLAM algorithms feature-based?
In the book of SLAM for dummies, why do we even need the odometry when the robot would use the data retrieved from the laser scanner which is more accurate than odometry? Why not just rerly on the laser scanner and do away from the odometry? Is there any contribution by the odometry that the laser scanner does not have? Also, are all SLAM algorithms feature-based?</p>

答:
Just to add up on this, using odometry to estimate the robot position is much faster than using data from a laser scanner. In most situations, data from a range scanner is handled as a 2D PointCloud. This means that in order to estimate the relative pose between positions A, B you need to align their corresponding PointClouds and find the most probable pose of that alignment operation. To do that you would use ICP or a similar algorithm, which due to its iterating nature is computationally intensive.

On the other hand, using odometry information (e.g. from the wheel encoders) you just need to add up to the current estimation of your pose which is just the sum of two Probability density functions (current estimation + incremental odometry reading)

ContentLicense: CC BY-SA 3.0


问:
Low power to motors -- motor power jumper issue
I'm currently working on my first robotics project using the Initio kit from 4tronix powered by Raspberry Pi. The setup was fairly simple, and I've been testing it out over the last couple of days. All of the sensors work as expected; however, my motor tests are failing. When I input commands to actually move the robot, I can hear the DC motors running but they're not getting enough power to do anything. In the instructions, it says if this issue is encountered, that the power selection jumper might not be set correctly and provides this diagram:

For comparison, here's how I have the wiring for the motors setup:

I'm not entirely sure what it means to have the power selection jumper being set incorrectly and would greatly appreciate it if someone could explain this to me or point out if they see anything wrong with my setup.

答:
I had the same problem with the "Ultimate 4tronix Initio 4WD Robot Kit" - the motors make some noise, but do not start moving. I tried using 8 batteries instead of 6 (for higher voltage on the motor), that helped for one motor assembly, but did not work for the other. I disassembled the gear box, and found that several of the gears had small plastic bumps remaining from injection molding. Those bumps were on horizontal parts of the gears, and some - between teeth of the gear. Here is a photo of one of them.  Plastic forks that are used to switch rotors off from the motor also have a ridge in the middle, and I think it is high enough to touch the teeth of the gear.

Below is the photo of the gear box immediately after I opened it - white paste is some kind of lubricant.

Then I increased the number of batteries to 10, and was able to get consistent rotation from one of the gear boxes at speeds of 30% to 100% - in the air, without wheels attached. The other gear box behaves much worse - sometimes manages to start up, sometimes not.

After spending few more evenings on the gear boxes, I was able to make them start consistently at speeds of 50% to 100%.

Here are the steps if you want to try this on your gear boxes:

Disconnect motors from any power supply.

Unscrew gear box from the chassis.

Unscrew 2 screws of the rotational encoder, detach it.

Unscrew 6 screws that hold the gear box case. Remove the gear box cap.

Take a photo or remember where each gear sits, and which side of the gear is up.

Carefully remove plastic gears and metal axles. Remember which axle was coming from where, as they are of different lengths. They will be in a greasy lubricant.

Unscrew 3 screws of the hood that protects the motor. Take a photo or remember which side the wires are pointing to.

Pull the motor from the gear box.

There may be some lubricant on the gear attached to the motor - wipe it with a cloth or tissue paper. Do not wash motor in water.

Wash gear box case, metal axes and gears in warm water with soap or kitchen washing up liquid. The goal is to get rid of the lubricant - it is not necessary, as the friction of plastic to plastic and plastic to metal is very small for the materials used in this gear box.

Wipe the gears and gear box case with tissue paper until they are dry. Make sure not to leave any paper on the gears.

Match gears with holes to the corresponding metal axles, try to rotate them - they should turn without significant friction. If there is some friction, use a thin round metal file to slightly increase the diameter of the hole in the gear. After using the file, make sure to wash the gear, so that small pieces of plastic do not go to the gear box.

Find a small plastic tube, like from LEGO Technic (see  Figure 2 below). Cut it a bit, so that it can be used as a support for the small gear with hole (See Figure 3 below).

Inspect each gear, and remove any bumps on the horizontal sides with a file.

Pay special attention to the sides of the gears marked by red arrows on Figure 5 below. Those sides should be filed so that a small chamfer is formed. It should not be a proper 45 degrees chamfer, you just need to remove a bit of material to make sure the teeth are not touching another gear.

Wash the gears after polishing, so that the dust does not go to the gear box.

Assemble the gear box without motor, try to turn one of the side axles. The rotation should be smooth, none of the gears should wobble or jump. If they do, or if you feel any obstruction on one of the angles, find the offending gear and polish it more.

Cut the legs of the black plastic forks, as they are not needed and can prevent gears from folling (see Figure 4 below).

Assemble the gear box back, screw in 6 screws.

Make sure the axles still can be turned without significant friction.

Looks into the motor holder place, note two bumps inside. There are corresponding holes on the motor, orient it accordingly, check the location of wire, and insert the motor.

Attach the motor hood.

Check that the motor is turning at reasonable levels of speed (pulse-width modulation).

Attach the encoder and check the motor again.

The gear boxes are very noisy when they manage to start rotating.


问:
Switch activated by a microcontroller
I'm working on a project where I'm using a voltage that is higher than what most microcontrollers can handle. I'm looking for a kind of switch that will connect a power source to an electromagnet and all of this controlled by my microcontroller. I also thought about using a potentiometer to control the speed of two high voltage DC motors via my microcontroller so please tell me if this is a good idea aswell.

Thanks for your time

Zakary

答: You can connect your switch to a comparator, such as the LM339, and wire its output to the microprocessor input pin.   It has open collector outputs, so you can pull the outputs up to whatever voltage level your micro can handle.  </p>

Title: Switch activated by a microcontroller


问:
Proper naming of PID regulators
I was wondering either there is any special naming for regulators that:

Outputs unit is the same as inputs, ie. velocity [m/s] as input and velocity as output [m/s].

Outputs unit is different than inputs, ie. position as input [m], velocity as output [/m/s]

I would appreciate all help.

答: I name them by the controlled parameter(s), such as velocity controller or position controller.   For clarity it is sometimes helpful to include the feedback variable(s):  velocity controller with position feedback. I am not aware of any notational standards.

Title: Proper naming of PID regulators


答:
What exactly do you mean? The units at what point in the control loop? You can't exactly have a speed reference input to a PID controller and use a position feedback.

Similarly, if you're just looking strictly at the inputs and outputs of the PID block itself, then the units are always different. That is, for a speed controller, you have:

(P)roportional gain output: [Speed ref] - [Speed fbk]  (Units of dist/time)

(I)ntegral gain output: [Pos ref] - [Pos fbk]  (Units of
dist)

(D)erivative gain output: [Accel ref] - [Accel fbk]  (Units of dist/time^2)

So, where the input of a PID controller are a particular unit, the I/D aspects of the PID controller require the output units to always be different. This is typically just the "control signal" and inputs to whatever the plant is.

Again I'll ask, what are the inputs and outputs you are considering? In and out of the PID block, or input/output as in the reference and feedback?

If you mean reference and feedback (inputs and outputs to the entire control system), then generally you have:

SISO - Single Input Single Output, meaning that there is one input and one output. These outputs should be the same units to make any sense.

MIMO - Multiple Input Multiple Output, meaning that there are multiple inputs and multiple outputs. This is generally some state feedback or LQR controller, and here the units can be mixed as you're trying to control the system instead of a particular parameter.

Consider any scenario when you might want to try using a feedback in units other than the reference units. What then are you trying to do? For instance, why would you want to use acceleration as a feedback for a speed reference? Maybe you want to control min/max acceleration while you try to achieve a particular speed, or you want to control speed while you try to achieve a particular position, but I'll point out that in these scenarios you are trying to control two parameters (speed and position, speed and acceleration, etc.), and thus it's a MIMO system (Multiple input - speed ref and [X] limits, multiple output - speed and [X]).

Title: Proper naming of PID regulators

Body:
I was wondering either there is any special naming for regulators that:

Outputs unit is the same as inputs, ie. velocity [m/s] as input and velocity as output [m/s].

Outputs unit is different than inputs, ie. position as input [m], velocity as output [/m/s]

I would appreciate all help.


问:
How would I go about making an art drawing robot like this?
I saw this art drawing robot on youtube:

http://www.youtube.com/watch?v=Wo15zXhFdzo

What do I need to learn in order to build something like that? What are some beginner oriented projects that could lead up to building something like this?

I'm an experienced programmer but I have very little hardware experience.

答:
I was in your situation when I made that video, but DaemonMaker, my friend who studies Robotics, helped immensely.

I can't really add much beyond what DaemonMaker said because my focus is on stroke planning and automatic painting and most of my work runs on simulated brushes and simulated canvas.

I'm preparing my techniques for profit and publication and wouldn't disclose them on a public forum. However, there are other methods out there, to control the robot, such as those mentioned by Aaron Hertzmann in Algorithms for Rendering in Artistic Styles

We describe new algorithms and tools for generating paintings, illustrations, and animation on a computer. These algorithms are designed to produce visually appealing and expressive images that look hand-painted or hand-drawn. In many contexts, painting and illustration have many advantages over photorealistic computer graphics, in aspects such as aesthetics, expression, and computational requirements. We explore three general strategies for non-photorealistic rendering

This technology has been around for a long time and if you're mostly interested in the robot, you can use this instead of worrying about control.

Hertzmann's algorithm depends on comparisons between the canvas and the reference image. If you want to do it with a robot, you'll need a camera to photograph the painting before and after every brush stroke. You'll also probably need computer vision algorithms to negate lens distortion, align the canvas and reference images, and adjust color biases from the illumination.

It's good to see fresh interest in the subject.


问:
Can a robot or mechanical part be programmed to exert a specific force
So I was thinking about projectiles that don't need a propellant like gunpowder I've seen coils gun but that's a little out my way. I was wondering if I know the force required to propel a object could I program a robot to exert that force to propel the object the same way (in a linear propelled fashion).</p>

答: Yes you can. People built robots doing exactly that for several hundred years.</p>


问:
Using Gazebo installed on same machine in MATLAB
I am planning to use MATLAB and Gazebo for one of my course projects.

However all the tutorials I have seen till now use Gazebo by using a virtual machine which has ROS and Gazebo installed. I have already installed ROS and Gazebo on this machine (OS Ubuntu). I also have MATLAB installed on it.

Is it possible to use the Gazebo on this machine itself with the MATLAB toolbox?

答:
The MATLAB tutorial doesnt cover this aspect well about when you have matlab  and gazebo  running on the same linux  machine with no virtual box.

Change your linux ethernet interface ip address statically  using:

```<code>sudo ifconfig eth0   192.168.1.1 netmask 255.255.255.0
</code>```

assign to ros master the same ip address using:

```<code>export ROS_MASTER_URI=http://192.168.1.1:11311 >> ~/.bashrc
export ROS_HOSTNAME=192.168.1.1 >> ~/.bashrc
export ROS_IP=192.168.1.1 >> ~/.bashrc
</code>```

assign to  matlab ros, an  ip address in same subnet as the master above using :

```<code>setenv('ROS_IP','192.168.1.100:11311')
setenv('ROS_IP','192.168.1.100')
</code>```

start rosmaster in terminal using : roscore

start gazebo model in terminal

connect to rosmaster ip adress in MATLAB using: rosinit('192.168.1.1:11311')

Now you should see gazebo and ros topics in matlab command window

You can also follow the matlab tutorial to see how much more you can do

Body:
The MATLAB tutorial doesnt cover this aspect well about when you have matlab  and gazebo  running on the same linux  machine with no virtual box.

Change your linux ethernet interface ip address statically  using:

sudo ifconfig eth0   192.168.1.1 netmask 255.255.255.0

assign to ros master the same ip address using:

export ROS_MASTER_URI=http://192.168.1.1:11311 >> ~/.bashrc
export ROS_HOSTNAME=192.168.1.1 >> ~/.bashrc
export ROS_IP=192.168.1.1 >> ~/.bashrc

assign to  matlab ros, an  ip address in same subnet as the master above using :

setenv('ROS_IP','192.168.1.100:11311')
setenv('ROS_IP','192.168.1.100')

start rosmaster in terminal using : roscore

start gazebo model in terminal

connect to rosmaster ip adress in MATLAB using: rosinit('192.168.1.1:11311')

Now you should see gazebo and ros topics in matlab command window

You can also follow the matlab tutorial to see how much more you can do


问:
Create2 incremental encoder rollover method
I have never yet had the Create2's incremental encoder rollover but want to write my code to be prepared for this to happen and test it. When the encoder rolls past 32767 (14.5m), does it rollover to -32768 and count there or start at 0 again and count up from there?

One other odd thing but not a big deal. When I reset the Create2, the first value is 1 not 0.

答: With a 16-bit two's-compliment counter, the highest positive number would be 32,767, while the lowest negative number is -32,768. So it would overflow from 32,767 to -32,768. When counting in the opposite direction, it would underflow from -32,768 to 32,767.</p>


问:
What algorithm can I use for constructing a map of an explored area using a number of ultrasound sensors?
Ultrasound sensors are incredibly cheap these days which makes them a popular choice for many hobbyist robotic applications, and I'd like to use a bunch of them (say 10) around a robot with an algorithm to build a rough map of an area (as the robot explores it.) I'm not interested in dealing with moving objects at this stage, just pinpointing stationary ones, and I'll be using GPS for location. I realise that other components such as a laser scanner would produce much more accurate results, however such devices are also astronomically more expensive.

Does an algorithm exist for this purpose?

答:
To do SLAM, you will need a relatively good estimate of position.

Robots that use laser scanners can make do with just odometry, because the data is relatively accurate, and the scanner data can be used to help localize in subsequent time steps.

Ultrasound sensors are very fuzzy, they generally have a direction fuzziness of 20+ degrees, and anything in the general direction will be detected.

Thus, they are of negligible help in helping to localize (except in very structured environments).

A GPS/IMU combination can be used to get reasonable localization. Of course, this depends on the scale of the robot, and if it is indoors, GPS may not be practical.

If you are able to carefully control wheel slippage, wheel odometry can significantly improve localization in the short term (although an absolute method of localization is preferred). Without an absolute reference (eg. GPS), even with a laser scanner, you will need to be able to solve the problem of "closing the loop".

Structured environments may have a lower accuracy requirement. For example, a maze-like environment with walls at regular square grid distances, where it is simple to detect the presence of a wall in each direction of a grid cell.


问:
The 3 key components of a robot are controller, servo, and reducer. Can someone give us an "official" explanation of what they do respectively?
I've googled a lot but wasn't able to find official definitions of these 3 parts. Maybe the explanations of servo and controller are good enough, but I'm still trying to look for a more "official" one.

Any ideas?

答:
Your question is premised on a misunderstanding of what a robot is composed of, but you are close.

A robot is an agent that is capable of sensing, thinking, and acting. The sense-think-act (or sense-plan-act) paradigm has historical significance in behaviour based robotics, and you can read about it in Ronald Arkin's book Behavior-Based Robotics.

The two of the three components that you mention in your question fall neatly into the categories of sensing, thinking, and acting. Sensing components, as the name suggests, gather data from sensors about the environment (internal or external). Common sensors include accelerometers, gyroscopes, cameras, radar, lidar, etc.. Thinking is implemented in a computing environment, small robots will use a micro-controller to facilitate this. On the computer, algorithms, controllers (the control theory type), artificial intelligence (and so on) process the sensor data as input and determine a desired output objective. Acting components, which include servo motors as you mentioned, are responsible for interacting with, or actuating in, the environment.

With this brief description, hopefully you better understand what a robot is at an abstract level, which should inform you as to what the physical components are for at a high-level. I will again point you to Arkin's book. The Springer Handbook of Robotics is another good resource that will certainly answer your questions.


问:
Create 2 Reading Sensor Values
I am trying to solve some Create 2 sensor reading problem that I am having when I came across @NBCKLY's posts (Part 1 and Part 2) that I believe are exactly what I am looking for. I copied his code from the original post into my project and updated the code from the second post as best as I could interpret...but something is not going according to plan.

For example, I am printing the angle to my serial monitor (for now) but I am constantly getting a value of 0 (sometimes 1).

Can @NBCKLY or anybody please check out this code and tell me what I'm doing wrong? I would appreciate it. Thank you very much.

```<code>int baudPin = 2;
int data;
bool flag;
int i;
int ledPin = 13;
int rxPin = 0;
signed char sensorData[4];
int txPin = 1;

unsigned long baudTimer = 240000;
unsigned long prevTimer = 0;
unsigned long thisTimer = 0;

void drive(signed short left, signed short right) {
  Serial.write(145);
  Serial.write(right >> 8);
  Serial.write(right & 0xFF);
  Serial.write(left >> 8);
  Serial.write(left & 0xFF);
}

void updateSensors() {
  Serial.write(149);
  Serial.write(2);
  Serial.write(43); // left encoder
  Serial.write(44); // right encoder
  delay(100);

  i = 0;

  while (Serial.available()) {
    sensorData[i++] = Serial.read();
  }

  int leftEncoder = int((sensorData[0] << 8)) | (int(sensorData[1]) & 0xFF);
  int rightEncoder = (int)(sensorData[2] << 8) | (int)(sensorData[3] & 0xFF);
  int angle = ((rightEncoder * 72 * 3.14 / 508.8) - (leftEncoder * 72 * 3.14 / 508.8)) / 235;

  Serial.print("\nAngle: ");
  Serial.print(angle);
  Serial.print("\n");
}

void setup() {
  pinMode(baudPin, OUTPUT);
  pinMode(ledPin, OUTPUT);
  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);

  delay(2000);
  Serial.begin(115200);

  digitalWrite(baudPin, LOW);
  delay(500);
  digitalWrite(baudPin, HIGH);
  delay(100);

  Serial.write(128);
  Serial.write(131);
  updateSensors();
  drive(50, -50);
}

void loop() {
  thisTimer = millis();

  if (thisTimer - prevTimer > baudTimer) {
    i = 0;
    prevTimer = thisTimer;
    digitalWrite(baudPin, LOW);
    delay(500);
    digitalWrite(baudPin, HIGH);
    Serial.print("Pulse sent...\n");
  }

  updateSensors();
}
</code>```

#

What I am asking is why do I only get an angle of rotation of 0 or 1 degrees when the robot is moving in a circle. The angle should be incrementing while the robot is moving.

The output I am getting on the serial monitor shows a line of what looks like garble which I assume is supposed to be the bytes sent back from the Create which is followed by "Angle: 0 (or 1)" What I was expecting to see was an increasing angle value. (1,2,3...360, and so on).

答:
First, I'll point out that OP code 20 will just give you the angle directly. Remember if you use that code then,

The value returned must be divided by 0.324056 to get degrees.

Regarding your code specifically, it looks like you're trying to do:

$$
\frac{\mbox{right distance} - \mbox{left distance}}{\mbox{wheel base}} \\
$$

This is a rearrangement of the arc length formula:

$$
s = r\theta \\
$$

where $s$ is the arc traversed (difference in wheel distances), $r$ is the radius of the circle (the wheel base), and $\theta$ is the angle traversed, in radians.

So, one of your problems is that you are using an int to define your angle value - int is short for integer, meaning that it can only be whole number. Radians are very small in magnitude compared to degrees. One complete circle is $2\pi$ radians, or about 6.28. Compare this to degrees, which is 360. This means that one radian is about 60 degrees; you won't get any update because of your unit definition.

Your biggest problem is, as NBCKLY asked about, the encoder counts that are returned to you from OP code 43 and 44 are not signed. So, when you your math, you are doing the following:

$$
\frac{ \frac{\mbox{right encoder}}{\mbox{counts per rev}} (\pi d) - \frac{\mbox{left encoder}}{\mbox{counts per rev}} (\pi d)}{\mbox{wheel base}} \\
$$

BUT, your drive commands are equal in magnitude. This means that $\mbox{right encoder}\approx \mbox{left encoder}$ because the encoder counts are not signed. That is, even though your drive command is negative, the counts come back as positive.

So, here's what you can do to fix this**:

Multiply the encoder counts by the sign (not sine) of the respective drive command.

Use a float for the angle and/or use degrees for the angle by multiplying your existing code by (180/3.1415).

** - A final note on your code: You're going to have trouble doing it the way you are at the moment because you're using total encoder counts for your math. Say you get to 16,000 counts and change direction on that motor. What happens? Well, the way I've written above (which fixes your current issue), you go from +16,000 to -16,000 (or vice-versa). What you should consider doing instead is to accumulate an angle and to evaluate only the elapsed wheel encoder counts. That is, I would do the following (pseudo-code):

```<code>float angle;
angle = 0;

<in your updateSensor code>
leftEncoder = <get left encoder counts>;
rightEncoder = <get right encoder counts>;

/* Rollover protection on the encoder */
if leftDriveCommand > 0
    if leftEncoder < prevLeftEncoder
        prevLeftEncoder = prevLeftEncoder - 65535;
    end
elseif leftDriveCommand < 0
    if leftEncoder > prevLeftEncoder
        prevLeftEncoder = prevLeftEncoder + 65535;
    end
end

<do the same thing for the right encoder>

elapsedLeft = leftEncoder - prevLeftEncoder;
prevLeftEncoder = leftEncoder;

elapsedRight = rightEncoder - prevRightEncoder;
prevRightEncoder = rightEncoder;

angleIncrement = (elapsedRight - elapsedLeft)*(pi*d/countsPerRev)/(wheelBase);

angle = angle + angleIncrement;
</code>```

So in this way you accumulate your angle by looking at how much of an angle has elapsed since the last time you updated your sensor. In this way, you don't have to worry about what happens with encoder counts when you reverse polarity on a drive command. You should also consider what is going to happen when you roll over from 65535 back to 0.

Or again, just use OP code 20 to get the angle directly.

Title: Create 2 Reading Sensor Values

Body:
First, I'll point out that OP code 20 will just give you the angle directly. Remember if you use that code then,

The value returned must be divided by 0.324056 to get degrees.

Regarding your code specifically, it looks like you're trying to do:

$$
\frac{\mbox{right distance} - \mbox{left distance}}{\mbox{wheel base}} \\
$$

This is a rearrangement of the arc length formula:

$$
s = r\theta \\
$$

where $s$ is the arc traversed (difference in wheel distances), $r$ is the radius of the circle (the wheel base), and $\theta$ is the angle traversed, in radians.

So, one of your problems is that you are using an int to define your angle value - int is short for integer, meaning that it can only be whole number. Radians are very small in magnitude compared to degrees. One complete circle is $2\pi$ radians, or about 6.28. Compare this to degrees, which is 360. This means that one radian is about 60 degrees; you won't get any update because of your unit definition.

Your biggest problem is, as NBCKLY asked about, the encoder counts that are returned to you from OP code 43 and 44 are not signed. So, when you your math, you are doing the following:

$$
\frac{ \frac{\mbox{right encoder}}{\mbox{counts per rev}} (\pi d) - \frac{\mbox{left encoder}}{\mbox{counts per rev}} (\pi d)}{\mbox{wheel base}} \\
$$

BUT, your drive commands are equal in magnitude. This means that $\mbox{right encoder}\approx \mbox{left encoder}$ because the encoder counts are not signed. That is, even though your drive command is negative, the counts come back as positive.

So, here's what you can do to fix this**:

Multiply the encoder counts by the sign (not sine) of the respective drive command.

Use a float for the angle and/or use degrees for the angle by multiplying your existing code by (180/3.1415).

** - A final note on your code: You're going to have trouble doing it the way you are at the moment because you're using total encoder counts for your math. Say you get to 16,000 counts and change direction on that motor. What happens? Well, the way I've written above (which fixes your current issue), you go from +16,000 to -16,000 (or vice-versa). What you should consider doing instead is to accumulate an angle and to evaluate only the elapsed wheel encoder counts. That is, I would do the following (pseudo-code):

float angle;
angle = 0;

<in your updateSensor code>
leftEncoder = <get left encoder counts>;
rightEncoder = <get right encoder counts>;

/* Rollover protection on the encoder */
if leftDriveCommand > 0
    if leftEncoder < prevLeftEncoder
        prevLeftEncoder = prevLeftEncoder - 65535;
    end
elseif leftDriveCommand < 0
    if leftEncoder > prevLeftEncoder
        prevLeftEncoder = prevLeftEncoder + 65535;
    end
end

<do the same thing for the right encoder>

elapsedLeft = leftEncoder - prevLeftEncoder;
prevLeftEncoder = leftEncoder;

elapsedRight = rightEncoder - prevRightEncoder;
prevRightEncoder = rightEncoder;

angleIncrement = (elapsedRight - elapsedLeft)*(pi*d/countsPerRev)/(wheelBase);

angle = angle + angleIncrement;

So in this way you accumulate your angle by looking at how much of an angle has elapsed since the last time you updated your sensor. In this way, you don't have to worry about what happens with encoder counts when you reverse polarity on a drive command. You should also consider what is going to happen when you roll over from 65535 back to 0.

Or again, just use OP code 20 to get the angle directly.


问:
Using Quaternions to feed a quadcopter PID stabilizing controller to avoid Gimbal lock
I am trying to control my F450 dji quadcopter using a PID controller. From my IMU, I am getting the quaternions, then I convert them to Euler's angles, this is causing me to have the Gimbal lock issue. However, is there a way that I directly use the quaternions to generate my control commands without converting them to Euler's angle?

This conversation here discusses a similar issue but without mentioning a clear answer for my problem.

The three errors so far I am trying to drive to 0 are:

```<code>double errorAlpha  = rollMaster  - rollSlave;
double errorTheta  = pitchMaster - pitchSlave;
double errorPsi    = yawMaster   - yawSlave;
</code>```

where the Master generates the desired rotation and the Slave is the IMU.

UPDATE:

Here are some pieces of my code:

Getting the current and the reference quaternions for bot the Master and the Slave from the ROTATION_VECTOR:

```<code>/** Master's current quaternion */
double x   = measurements.get(1);
double y   = measurements.get(2);
double z   = measurements.get(3);
double w   = measurements.get(4);

/** Slave's current quaternion */
double xS  = measurements.get(5);
double yS  = measurements.get(6);
double zS  = measurements.get(7);
double wS  = measurements.get(8);

/** Master's Reference quaternion */
double x0  = measurements.get(9);
double y0  = measurements.get(10);
double z0  = measurements.get(11);
double w0  = measurements.get(12);

/** Slave's Reference quaternion.
 *  If the code has not been initialized yet, save the current quaternion
 *  of the slave as the slave's reference orientation. The orientation of
 *  the slave will henceforth be computed relative to this initial
 *  orientation.
 */
if (!initialized) {
    x0S = xS;
    y0S = yS;
    z0S = zS;
    w0S = wS;
    initialized = true;
}
</code>```

Then I want to know the orientation of the current quaternion relative to the reference quaternion for both the Master and the Slave.

```<code>/**
     * Compute the orientation of the current quaternion relative to the
     * reference quaternion, where the relative quaternion is given by the
     * quaternion product: q0 * conj(q)
     *
     * (w0 + x0*i + y0*j + z0*k) * (w - x*i - y*j - z*k).
     *
     * ```
     * See: http://gamedev.stackexchange.com/questions/68162/how-can-obtain-the-relative-orientation-between-two-quaternions
     * http://www.mathworks.com/help/aerotbx/ug/quatmultiply.html
     * ```
     */
    // For the Master
    double wr = w * w0 + x * x0 + y * y0 + z * z0;
    double xr = w * x0 - x * w0 + y * z0 - z * y0;
    double yr = w * y0 - x * z0 - y * w0 + z * x0;
    double zr = w * z0 + x * y0 - y * x0 - z * w0;

    // For the Slave
    double wrS = wS * w0S + xS * x0S + yS * y0S + zS * z0S;
    double xrS = wS * x0S - xS * w0S + yS * z0S - zS * y0S;
    double yrS = wS * y0S - xS * z0S - yS * w0S + zS * x0S;
    double zrS = wS * z0S + xS * y0S - yS * x0S - zS * w0S;
</code>```

Finally, I calculate the Euler angles:

```<code>/**
     * Compute the roll and pitch adopting the Tait–Bryan angles. z-y'-x" sequence.
     *
     * ```
     * See https://en.wikipedia.org/wiki/Rotation_formalisms_in_three_dimensions#Quaternion_.E2.86.92_Euler_angles_.28z-y.E2.80.99-x.E2.80.B3_intrinsic.29
     * or  http://nghiaho.com/?page_id=846
     * ```
     */
    double rollMaster  =  Math.atan2(2 * (wr * xr + yr * zr), 1 - 2 * (xr * xr + yr * yr));
    double pitchMaster =  Math.asin( 2 * (wr * yr - zr * xr));
    double yawMaster   =  Math.atan2(2 * (wr * zr + xr * yr), 1 - 2 * (yr * yr + zr * zr));
</code>```

and I do the same thing for the Slave.

At the beginning, the reference quaternion should be equal to the current quaternion for each of the Slave and the Master, and thus, the relative roll, pitch and yaw should be all zeros, but they are not!

答:
you should not be seeing a singularity. For the standard roll, pitch, and yaw Euler angles, which are defined by a 3-2-1 rotation from level to the vehicle attitude, there is only a singularity at pitch=+-n*180 +90. This is not a scenario you should be seeing unless you are doing something acrobatic and aggressive. This is an attitude where the vehicle is totally sideways.

Look at how you are converting to Euler angles.

-

I recommend commanding psi like this
\begin{equation}
\psi_{error} = \left(\psi_{master} - \psi_{master,0} \right) - \left(\psi_{slave} - \psi_{slave,0} \right)
\end{equation}


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

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

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

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

Here is what I get for rostopic list:

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

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

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

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

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

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

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

答: Use the camera_calibration package. It's supported in all distributions. The package you're using looks pretty old.</p>

Title: PTAM CameraCalibrator error

ContentLicense: CC BY-SA 4.0


问:
Piezo sensors and multiplexers
I got asked to make some sort of trigger pads for the foot section of an organ working over midi to a electric piano and my friend wants it to be pressure sensitive so we can program in the note velocity when he's not using the organ sound.

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

That is what I try to achive. I want the pads to not just be on/off but also be able to control the velocity of the midi note.

Im planning to use a Adruino Uno with a MUX Shield II from Mayhew Labs to get 36 analog inputs. Not exactly sure on the wiring yet but have looked at some guides and videos on google to get a feel for how it can be made.

All these 36 piezo-"sensors" is planned to register how hard you push the pedals and then send out a MIDI signal with a specific note correspondig to the pedal, and velocity to the electric piano so you can control the low notes with your feet.

http://www.thomann.de/se/clavia_nord_pedal_key_27.htm

Just like that but more pedals and a lot cheaper.

Will the Arduino be able to read the analog output of the piezo sensor even though it's going through a multiplexer?

答:
You're asking about the Mayhew Labs multiplexer.  Looking at their user guide:

The Mux Shield uses TI 74HC4067 analog multiplexers (mux’s) for input functionality

I'm very sure those will be able to pass an analogue signal.

Bear in mind though that Piezo sensors respond to a change in pressure. When tapped they will produce a peak voltage that can be read to give a velocity, but they don't respond so well to continuous pressure (aftertouch) in the way that organ pedals might. This is fine if you want to know the velocity at which the pedals are hit, but perhaps not a full aftertouch.

Title: Piezo sensors and multiplexers


答:
A multiplexer should be able to do what you want, as could a multi-channel analog to digital converter.

A multiplexer "aligns" a particular signal line with a pin on the microcontroller, like a rail switch, and then the microcontroller reads the value of the signal.

An analog to digital converter actually reads the value at the signal, then stores that value in a register.

The microcontroller has to send a signal to the MUX to tell it which signal it should align, and it would also have to have a digital communication with the an analog to digital converter (ADC).

You can sometimes get faster connection with a MUX because you can sometimes use digital I/O to signal the MUX to change (rather than a bus communication), but there are also issues with a MUX in that the device might short two input signals together before switching is complete (make-before-break). A MUX might also buffer the signal such that you're not actually connected to the true device. Sometimes these are advantages, sometimes they're not.

It's up to you to carefully read the datasheet on all of the devices and make sure what you're getting is what is suitable for you.

Title: Piezo sensors and multiplexers

Body:
I got asked to make some sort of trigger pads for the foot section of an organ working over midi to a electric piano and my friend wants it to be pressure sensitive so we can program in the note velocity when he's not using the organ sound.

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

That is what I try to achive. I want the pads to not just be on/off but also be able to control the velocity of the midi note.

Im planning to use a Adruino Uno with a MUX Shield II from Mayhew Labs to get 36 analog inputs. Not exactly sure on the wiring yet but have looked at some guides and videos on google to get a feel for how it can be made.

All these 36 piezo-"sensors" is planned to register how hard you push the pedals and then send out a MIDI signal with a specific note correspondig to the pedal, and velocity to the electric piano so you can control the low notes with your feet.

http://www.thomann.de/se/clavia_nord_pedal_key_27.htm

Just like that but more pedals and a lot cheaper.

Will the Arduino be able to read the analog output of the piezo sensor even though it's going through a multiplexer?


问:
Should I use or not EKF for Baro-Acc altitude estimation?
I've recently implemented a kalman filter to estimate altitude for a small robot with an IMU+Baro sensor mounted on it.

My objective is to get max precision I can have, using this two sensor, with small computing power that a MCU can provide me. I've tuned my filter and it seems to work pretty well.

Can I obtain a significant improvement using an Extended Kalman Filter instead of a normal Kalman Filter and if it worth time to implement it?

More in detail, since this request is too specific for each application, if a Model function that use Baro and Accel as states should be linearized and used in a EKF and if this can improve data reliability compared to a simply KF?

答:
EKFs are appropriate when you have nonlinear equations describing the system, either in the system dynamics or the measurement dynamics. In this case, I think a plain KF should be sufficient assuming the accel measurements are just measuring gravity and veritcal acceleration.

If you expect your sensor to function well in a non level orientation where you are incorporating accel measurements from more than one axis on your IMU I would recommend using a nonlinear estimator.

If you are just estimating altitude with accel measurements of gravity plus motion and a pressure you should be more than okay with the linear KF.

I would also recommend estimating the bias in the IMU. These can, of course, be calibrated out at the start of a flight but estimating biases should be trivial.


问:
Landmark extraction algorithm
The landmarks are often used in SLAM. What are the algorithms used to extract them, and how can a robot differentiate the landmarks, if they detect one in point A at Xt and another in Xt+1? How can the robot know if it's the same landmark or not?

答:
Landmarks or features are usually found using SURf, SIFT, or ORB. these algorithms extract corners from images and can be found in the opencv library. </p>

<p>Matching measured features to previously seen features is called the assignment problem. There are a couple ways to deal with this. The munkres algorithm solves this problem in O(n^4) time with a nxn cost matrix. The cost of assigning a measured feature to a previously seen feature is often the difference between the two scaled by the mahalonobis distance . </p>

Title: Landmark extraction algorithm

Body:
Landmarks or features are usually found using SURf, SIFT, or ORB. these algorithms extract corners from images and can be found in the opencv library.

Matching measured features to previously seen features is called the assignment problem. There are a couple ways to deal with this. The munkres algorithm solves this problem in O(n^4) time with a nxn cost matrix. The cost of assigning a measured feature to a previously seen feature is often the difference between the two scaled by the mahalonobis distance .


问:
thrust measurement
I try to find out the relation between rpm vs. thrust for a battery+motor+propeller combination. the image shows my setup and also the measurement result. Can anyone explain how l should use this datas (I know Kv.v gives the rpm but my voltage values decreasing because of P=V.I relation etc.) </p>

答: Try to couple the batteries with voltage regulator. A simple IC DC regulator would do. It would help maintain the input voltage of the motor and helps getting the relation between RPM vs Thrust independent to the voltage irregularities.</p>

Title: thrust measurement


问:
Quadcopter that can carry heavy things?
So, while I was out drinking with a couple of my friends, one of us said something like 'man, wouldn't it be cool if the beer just came to us?' and that got me thinking.

We all have seen some crazy things people do with quadcopters (or polycopters even), but would it be possible (and not too expensive) to build a quadcopter that could carry, say, a crate of beer? (16-20kg)

I'm a bit of a tinkerer and I've built some minor things with rasp. pi's before but never tried myself at a quadcopter, because they are quite a big piece of work, but being able to fly a crate of beer right in front of me would be pretty awesome.

That aside, how strong would such a quadcopter have to be? In terms of motors, propellers, battery & frame. I'm a complete noob when it comes to RPM and the like, so I wouldn't even know where to begin. I have, of course, read through most of the available tutorials on the internet, but they don't answer my question of what exactly to look for when I want my quadcopter to be able to carry something specific.

答:
Well, let me put it this way. To carry anything, the total thrust generated by the quadcopter/multicopter's motors needs to be atleast twice the total weight you wish to carry. This includes the weight of the quadcopter itself as well.

The more heavier the copter, the lesser the kV of the motor must be, since you'll need large propellers ( I'm talking atleast 15 inches for your idea) so that the propellers are stable on the motor.

You cannot use frames currently on the market as I don't think they're strong enough to handle a large payload. You should try making your own frame, maybe 3d printing it or carving it out yourself. Materials you can use can be carbon fiber or even balsa wood, which is really light. You can look up frame designs on the web, but my suggestion is to go with an integrated prop guard design for your frame, since that'll be added protection without adding anything more to the frame.

You'll need lipos of large capacity in order to have a decent run time. Go look up Oscar Liang's website for understanding rpm, battery selection, motors and props, etc.

Title: Quadcopter that can carry heavy things?


问:
How to select dc motors for a line following robot?
What are the criteria to consider when ordering dc motors for a line following robot?

Is there a way to calculate the torque required?

答:
It's a question of balance as always. You need to select motors that require voltage and current that your robot's power source can provide, physical size so that it fits on your robot and also torque and RPM to give your robot enough oomph. Also note that gearbox and wheel size affect the final top speed an acceleration.

What I did was to go through several suppliers and preselect motors with acceptable physical dimensions and voltage. Then I made a spreadsheet where I calculated robot acceleration at motor stall from torque and robot speed from motor's free running RPM with estimated robot mass and with all wheel sizes in a certain range.
From this spreadsheet I selected set of parameters (2G acceleration and 3m/s top speed for my tabletop line follower) that seemed the best and bought the motors.

When doing this you must realize that the top speed and acceleration are only theoretical maximum, your robot will be slower (because the motor is loaded when dragging your robot around) and there will probably also be less available acceleration as well.


问:
Are there any others alternatives for PID controllers for line following robots?
Are there any better/ advanced ways of steering a line following robot other than pid controller? If so what are them? </p>

答:
Because you don't have any specific robot in mind, let's assume that you have a two-wheeled differential drive robot (TWDDR). TWDDRs can be modeled with unicycle dynamics of the following form: $$\dot{z}=\left[\begin{matrix}\dot{x}\\ \dot{y} \\ \dot{\theta} \end{matrix}\right] = \left[\begin{matrix}cos(\theta)&0\\sin(\theta)&0\\0&1\end{matrix}\right] \left[\begin{matrix}v\\\omega\end{matrix}\right],$$ where $x$ and $y$ are Cartesian coordinates of the robot, and $\theta \in (-\pi,\pi]$ is the angle between the heading and the $x$-axis. The input vector $\left[v, \omega \right]^T$ consists of linear and angular velocity inputs. For simplicity, I will assume that you can specify these inputs directly, which is reasonable for most off-the-shelf robots--if you want to implement this from scratch, then you have to specify velocities for the left and right wheels.

Following a line is essentially a trajectory tracking problem. For unicycle robots, trajectory tracking is achieved by controlling a point, which is holonomic, some small distance $l$ away from the center of the the two wheels rather than controlling the unicycle robot directly. To do this, we can derive the following rotation matrix to transform the control law of the robot to the control law of the point: $$\dot{p}=\left[\begin{matrix}\dot{p_x}\\\dot{p_y}\end{matrix}\right]=\left[\begin{matrix}\text{cos}(\theta)&-l\text{sin}(\theta)\\\text{sin}(\theta)&l \text{cos}(\theta)\end{matrix}\right]\left[\begin{matrix}v\\\omega\end{matrix}\right]$$

$\dot{p}$ is the velocity of the point being controlled, and it is decomposed into its $x$ and $y$ components.

At this point, control is quite simple; we control the point directly! The dynamics become: $$\dot{z}=\left[\begin{matrix}\dot{x}\\ \dot{y} \\ \dot{\theta} \end{matrix}\right] = \left[\begin{matrix}cos(\theta)&0\\sin(\theta)&0\\0&1\end{matrix}\right] \left[\begin{matrix}v\\\omega\end{matrix}\right]=\left[\begin{matrix}cos(\theta)&0\\sin(\theta)&0\\0&1\end{matrix}\right] \left[\begin{matrix}cos(\theta)&sin(\theta)\\-\frac{sin(\theta)}{l}&-\frac{cos(\theta)}{l}\end{matrix}\right]\left[\begin{matrix}\dot{p}_x\\\dot{p}_y\end{matrix}\right],$$Setting $$\dot{p}=u=r(t)=\left[\begin{matrix}r_x(t)\\r_y(t)\end{matrix}\right],$$ accomplishes this, where $u$ is the input, and $r(t)$ is the reference trajectory that you want, decomposed into its $x$ and $y$ components; this will accomplish movement along the trajectory.

With the controller designed, the last component of building a line-following robot will be to implement some form of perception. If you have a downward facing camera and assume a level surface, consistent lighting, and good contrast between the line and its background, then you can use simple computer vision techniques to measure the error between the point $p$ and the desired trajectory. A simple proportional controller can be used to drive the robot along the line.


问:
Generate synthetic accelerometer data based on (x,y,z) coordinate
I would like to create a simulation model (basically a signal generator) which will allow me to generate the 3 output signals of an accelerometer based on 3 location input signals (x,y and z). I would like a more realistic model of the data produced by an accelerometer (with some noise and bias offsets).

How can I convert the series of points into a simulated accelerometer output?

Specifically:

I have a series of positions which describe a trajectory in 3D space...If an accelerometer was moving along the trajectory described by the series of positions, I am interested in knowing (simulating!) the data that the accelerometer would produce as the result of moving along the described trajectory.

I could just calculate the 2nd derivative of the trajectory, but that would probably be too ideal. I am looking for a model which is more realistic.

答:
I assume that the three location input signals are functions of time, i.e., $x=x(t)$, $y=y(t)$, and $z=z(t)$ relative to a fixed, non-rotating reference frame.  Then one could create a simple kinematics model that implements $dx/dt=v_x$, $dv_x/dt=a_x$, $da_x/dt=n_x$ where $n_x$ is a normal (Gaussian) random variable (and similarly for the $y$ and $z$ axes).  The resulting state-space model has nine state variables ($a_x$, $v_x$, $x$, $ a_y$, $\ldots$) and three measurements (the location input signals).  A simple Kalman filter can then be designed to estimate the acceleration states given the location measurements. This will be the kinematic acceleration relative the fixed, non-rotating reference frame.  </p>

<p>Accelerometers measure specific force, i.e., the difference between the kinematic acceleration and the acceleration due to gravity.  Thus the components of the acceleration due to gravity must be subtracted from the components of the estimated kinematic acceleration to obtain estimates of what accelerometers fixed to the non-rotating reference frame would measure.  </p>

Body:
I assume that the three location input signals are functions of time, i.e., $x=x(t)$, $y=y(t)$, and $z=z(t)$ relative to a fixed, non-rotating reference frame.  Then one could create a simple kinematics model that implements $dx/dt=v_x$, $dv_x/dt=a_x$, $da_x/dt=n_x$ where $n_x$ is a normal (Gaussian) random variable (and similarly for the $y$ and $z$ axes).  The resulting state-space model has nine state variables ($a_x$, $v_x$, $x$, $ a_y$, $\ldots$) and three measurements (the location input signals).  A simple Kalman filter can then be designed to estimate the acceleration states given the location measurements. This will be the kinematic acceleration relative the fixed, non-rotating reference frame.

Accelerometers measure specific force, i.e., the difference between the kinematic acceleration and the acceleration due to gravity.  Thus the components of the acceleration due to gravity must be subtracted from the components of the estimated kinematic acceleration to obtain estimates of what accelerometers fixed to the non-rotating reference frame would measure.


问:
What does internal sparking in a motor mean?
My Arduino + Raspberry Pi robot was working fine in the morning. I tested it, it ran perfectly, and then I switched it off.

Now in the evening when I'm trying to run it again, with the same batteries and everything, it just doesn't move!

I stripped it down to the motor compartment and found that when I try to run my main motor, I can see sparks through the translucent plastic on the back.

Does that mean my motor is gone?

答:
If you are using a brushed DC motor, then (hopefully) the sparks that you are seeing are a discharge between the commuter and the brushes--this is normal. Another example of this is evident in certain electric drills; under low lighting, you can see sparks through the ventilation holes. If you are interested in this, you can ask at the EE Stack Exchange, or you can grab a textbook.

As for debugging your motor, try using a different voltage supply or use a multi-meter to make sure that your battery is charged. Motors do burn out, and this may have happened, but you should check the easy things first.

EDIT:

I found a resource that corroborates what I am suggesting: Debugging 3-Phase Motor Failure. Your motor is not 3-Phase, but the same idea applies. Measure the winding resistance with a multi-meter. If your coil has broken internally, you will get a very large resistance (unlikely because you are seeing sparks); if you get a very small resistance, smaller than the rated value, then your coil is shorted, which might explain the sparks.

I would do these checks first, then move onto the rest of your components, but if the motor is not spinning under a verified supply voltage, it's definitely toast.


问:
looking for a miniature joystick, but in reverse
Does anyone know if small mechanical actuators exist which can be controlled electrically, sort of like a miniature joystick, but in reverse.  Instead of it picking up mechanical movement and outputting electrical signals, I want it to generate mechanical movement controlled via my electrical input signals.  I’ve searched for : electromechanical actuators, not finding what I need. Think of a pencil attached to a surface which can pivot to point anywhere in its half dome.  I’m thinking small, on the order of an inch.  It will not be load bearing.

My goal is to programmatically control the normal pointed to by a small flat surface attached to the end of each joystick rod.  Accuracy is more important than speed.  From across a small room, say 10' by 10', I'd like the surface normal to accurately point to arbitrary objects in the room, say a person walking across the room.  If I can cheaply buy/build such mechanisms to control the movement of these small flat surfaces, I would like dozens places across the walls of the room.

Its for an electromechanical sound project I’m planning.

答:
You could do this using two servos (one for each axis).
Here is what I mean (sorry for the poor graphics) :

Edit : trying to find the original image and upload it.


问:
What are some pitfalls of an ultrasonic sensor?
I'm using a HC-SR04 sensor to detect obstacles. What are the pitfalls with an ultrasonic sensor?

Here are a couple I've found during my testing:

The signal can bounce off of one wall to another and then get picked up, distorting latency

Absorbent materials sometimes don't bounce the signal back

Check the datasheet for supported range (min/max)

答: From my experience, don't use them for obstacle detection on high speed robots. Your'e just as good as without using them. </p>


答:
It'll involve a bit of reading, but Johann Borenstein's papers include several 1980s-90s publications about ultrasonics (plus loads of other interesting stuff). Some pure ultrasonic systems, some mixed with other navigation techniques.

One interesting effect I read about was reflections. If the "beam" hits a wall at an oblique angle, then instead of reflecting back to the sensor it bounces on back into the room, hits something then bounces right back. The result is detecting things that appear to be "beyond" the wall, but really they're objects in the room but a longer path length is being measured.

Title: What are some pitfalls of an ultrasonic sensor?

Body:
I'm using a HC-SR04 sensor to detect obstacles. What are the pitfalls with an ultrasonic sensor?

Here are a couple I've found during my testing:

The signal can bounce off of one wall to another and then get picked up, distorting latency

Absorbent materials sometimes don't bounce the signal back

Check the datasheet for supported range (min/max)


问:
Fence avoidance for manually controlled robot
I'm trying to find known techniques for keeping a manually controlled robot within a known polygon fence. More specifically, a pilot controls a robot by issuing desired velocity vectors, and the autopilot adjusts the velocity so that the distance to any boundary is always at least the stopping distance of the robot.

My goal is to implement a system that:

Tries to follow the pilot's desired velocity as closely as possible.

Is robust to changes in position and desired velocity. At a minimum, I want the velocity to change continuously with respect to the position of the robot and desired velocity of the pilot. Informally, this means that sufficiently small changes in the position or desired velocity of the pilot induce arbitrarily small changes in the velocity.

The second point is particularly important. Suppose that the policy were to find the intersection with the boundary in the direction of the desired velocity and slow down smoothly to that point. The below figure depicts a couple of scenarios in which this would not be continuous. In this figure, the black lines represent the fence boundary, the red dot is the position of the robot, and the blue line is the desired velocity of the pilot. In figure (a), a small perturbation of the position to the left will cause a large increase in allowed velocity because the desired velocity will intersect the far edge instead of the near edge. In figure (b), a small clockwise rotation of the velocity vector will result in a large decrease in allowed velocity because the desired velocity will intersect the near edge instead of the far edge.

I have searched for relevant papers, but most of the papers I've seen have dealt with fully autonomous obstacle avoidance. Moreover, I haven't seen any papers address the robustness/continuity of the system.

:EDIT:

The robot knows its own location and the location of the boundary at all times. I also have some equations for maximum velocity that allow a smooth ramp-down to a single line boundary (though I'd be interested in seeing a better one). I would like the velocity limits to be continuous in the position and desired velocity of the pilot.

I want to continuously throttle the user's input such that a minimum safe distance between the robot and the boundary is maintained, but see the figure that I added to the question. The hard part (I think) is to make sure that small changes in position (e.g. due to sensor noise) or small changes in desired velocity (e.g. due to pilot noise) don't cause huge changes in what the autopilot allows.

I want continuity because I think it will provide a much nicer experience for the pilot while still enforcing the fence boundary. There is a trade-off with optimally but I think this is worth it. Even though the physical world smoothes any discontinuities in velocity, big changes could still cause large jerk which will be somewhat disturbing to the pilot. The goal is to not have the autopilot introduce large oscillations not intended by the pilot.

This Will be implemented On a physical system that has sensors that provide an estimation of position, and the boundary shape is known and is unchanging. The actual system that I'm targeting is a quadcopter.

答:
I think that your problem is rather uncommon, so there may be no solutions ready to use without any modifications. However, you may have a look at "The Dynamic Window Approach to Collision Avoidance" by Dieter Fox, Wolfram Burgard and Sebastian Thrun. This reverses your problem: given current velocity and achievable accelerations, find a path for a robot that avoids all the obstacles. </p>

<p>Or you could just calculate maximum velocity in any given point basing just on a distance to the closes point of the fence. That will of course mean that even going away from the fence you will go slowly, if you are close to the border, but it will surely be continuous. </p>

Body:
I think that your problem is rather uncommon, so there may be no solutions ready to use without any modifications. However, you may have a look at "The Dynamic Window Approach to Collision Avoidance" by Dieter Fox, Wolfram Burgard and Sebastian Thrun. This reverses your problem: given current velocity and achievable accelerations, find a path for a robot that avoids all the obstacles.

Or you could just calculate maximum velocity in any given point basing just on a distance to the closes point of the fence. That will of course mean that even going away from the fence you will go slowly, if you are close to the border, but it will surely be continuous.


答:
I'll second mactro's answer, with a few notes:

I'm not sure why you are so concerned with continuity. With the window, you setup an imaginary line on all axes of motion where the distance is basically, "If I issue a stop command right now, where do I come to a stop?" Add a buffer to that stopping distance, then if an object gets between you and your stopping limit, then issue a stop command. A stop command would be zero speed.

So your reference is  until the fence gets almost so close that you won't be able to avoid it, in which case you set the speed on that axis to zero. This is where my question on continuity comes in - what difference does it make if the speed reference has a jump from  to ? The quadcopter, being a physical system, will not be able to instantaneously change speeds. That is, by being a physical object, the quadcopter will filter that discontinuity for you.

Further, hypothetically speaking, if your boundary isn't the fastest you could come to a stop, then what is it? You sound like you want to lower the maximum speed when operating near the wall, but why? As long as the operator isn't requesting to fly into the wall, why limit the performance? Leave the speed maximum at 100%, and then kill the operator input on that axis when they request to fly into the wall.

As a pre-rebuttal (prebuttal?) to a comment I'd imagine you'll make, a PID controller has some time step involved. Even if you have an instantaneous change in reference speed, that change doesn't register until the next time step. So it may be a large jump, but that large jump is going to look like a step command, which is generally the standard to which PID controllers are tuned.

Title: Fence avoidance for manually controlled robot

Body:
I'm trying to find known techniques for keeping a manually controlled robot within a known polygon fence. More specifically, a pilot controls a robot by issuing desired velocity vectors, and the autopilot adjusts the velocity so that the distance to any boundary is always at least the stopping distance of the robot.

My goal is to implement a system that:

Tries to follow the pilot's desired velocity as closely as possible.

Is robust to changes in position and desired velocity. At a minimum, I want the velocity to change continuously with respect to the position of the robot and desired velocity of the pilot. Informally, this means that sufficiently small changes in the position or desired velocity of the pilot induce arbitrarily small changes in the velocity.

The second point is particularly important. Suppose that the policy were to find the intersection with the boundary in the direction of the desired velocity and slow down smoothly to that point. The below figure depicts a couple of scenarios in which this would not be continuous. In this figure, the black lines represent the fence boundary, the red dot is the position of the robot, and the blue line is the desired velocity of the pilot. In figure (a), a small perturbation of the position to the left will cause a large increase in allowed velocity because the desired velocity will intersect the far edge instead of the near edge. In figure (b), a small clockwise rotation of the velocity vector will result in a large decrease in allowed velocity because the desired velocity will intersect the near edge instead of the far edge.

I have searched for relevant papers, but most of the papers I've seen have dealt with fully autonomous obstacle avoidance. Moreover, I haven't seen any papers address the robustness/continuity of the system.

:EDIT:

The robot knows its own location and the location of the boundary at all times. I also have some equations for maximum velocity that allow a smooth ramp-down to a single line boundary (though I'd be interested in seeing a better one). I would like the velocity limits to be continuous in the position and desired velocity of the pilot.

I want to continuously throttle the user's input such that a minimum safe distance between the robot and the boundary is maintained, but see the figure that I added to the question. The hard part (I think) is to make sure that small changes in position (e.g. due to sensor noise) or small changes in desired velocity (e.g. due to pilot noise) don't cause huge changes in what the autopilot allows.

I want continuity because I think it will provide a much nicer experience for the pilot while still enforcing the fence boundary. There is a trade-off with optimally but I think this is worth it. Even though the physical world smoothes any discontinuities in velocity, big changes could still cause large jerk which will be somewhat disturbing to the pilot. The goal is to not have the autopilot introduce large oscillations not intended by the pilot.

This Will be implemented On a physical system that has sensors that provide an estimation of position, and the boundary shape is known and is unchanging. The actual system that I'm targeting is a quadcopter.


问:
Dynamic torque simulation for a 6 DOF robotic arm
I am working on a 6 DOF robotic arm(industrial manipulator). I have the basic structural specs (dimensions, weights etc) for the links and joints with me.

Basically, I want to simulate both static torque(Due to the weight of the arm) and dynamic torque(due to the accelerating joint's motion) Torque that the joints will need to bear for a given set of motions.

I have looked on the web and found tools like the ROS-MoveIt Visualiser, Gazebo, V-REP which let me visually see a robotic arm and simulate the position logic and external factors like collisions etc. But I have been unable to simulate/calculate dynamic torque values from these tools.

Ideally, I'd want to define a fixed motion of the end effector(i.e. move the robot between 2 positions) and measure the Torque(both static and dynamic) during that particular move.

These torque values are essential for selecting the optimum motors and gearboxes for my design and payload.

答:
In order to simulate dynamics you need a multi-body dynamics simulation software. Matlab-Simulink has  SimMechanics toolbox to do this, but many CAD software used to carry out the mechanical design of the robot can aolso do the simulation. SolidWorks for example has a simulation component calld Simulation. </p>

<p>If you are interested in wiring the dynamic equations and calculating the torques you can use the iterative newton-euler method. </p>

Body:
In order to simulate dynamics you need a multi-body dynamics simulation software. Matlab-Simulink has  SimMechanics toolbox to do this, but many CAD software used to carry out the mechanical design of the robot can aolso do the simulation. SolidWorks for example has a simulation component calld Simulation.

If you are interested in wiring the dynamic equations and calculating the torques you can use the iterative newton-euler method.


答:
The dynamics of robotic arms are fairly complex, especially when there are more than three joints to consider. The problem is that the movement of each joint moves all the links beyond it, which can induce torques at other joints. You have to consider how the movement of all links affects each individual joint.

There is software that can automatically compute the dynamics based on the geometry you provide (MATLAB + SimMechanics comes to mind, although that is an expensive option). I don't have any knowledge of free simulators, but I'm sure they exist. You may have to search around to see what simulator is right for your application.

Another option is to program your own simulation. The mathematics behind the dynamics of serial link robots are covered in many different textbooks. In order to do this part from scratch you would need to be familiar with using matrices, plus some understanding of differential equations. I can give some of the basics here, to give you an idea of what you would have to program.

You can calculate the torque required to move a serial-link robotic arm using the following nonlinear matrix equation:

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

where

$\boldsymbol{\tau}$ is the (6x1) vector of joint torques

$\boldsymbol{q}$ is a (6x1) vector of joint angles

$\dot{\boldsymbol{q}}, \ddot{\boldsymbol{q}}$ are the (6x1) joint angular velocity vector and joint angular acceleration vector, respectively

$\boldsymbol{M}(\boldsymbol{q})$ is the (6x6) inertia matrix of the robot, which is a function of the joint angles

$\boldsymbol{C}(\boldsymbol{q},\dot{\boldsymbol{q}})$ is the (6x6) centrifugal and Coriolis effect matrix, which is a function of the joint angles and angular velocities

$\boldsymbol{G}(\boldsymbol{q})$ is the (6x1) gravitational torque vector, which is a function of joint position

Notice that this equation includes both the dynamic and static loads on each joint. If you set the joint angular velocity and acceleration to zero, you would have the static equation by itself.

You may be able to find expressions for the $M$, $C$, and $G$ matrices online, but you can also try to derive them for your application using the Euler-Lagrange method.

So, the steps you would have to take are:

Derive the dynamic matrices associated with your application.

Derive the equations that convert the motion (position, velocity, acceleration) of the end-effector to the motion of the joints (the inverse kinematics).

Write a program that

Converts an end-effector trajectory to a set of joint trajectories (position, velocity, and acceleration).

Computes the required torque using the dynamic equation for each point along that trajectory.

This is all possible (in fact I have done this myself for a 3 DOF manipulator) but it might be too much work for an enthusiast.

Title: Dynamic torque simulation for a 6 DOF robotic arm

Body:
I am working on a 6 DOF robotic arm(industrial manipulator). I have the basic structural specs (dimensions, weights etc) for the links and joints with me.

Basically, I want to simulate both static torque(Due to the weight of the arm) and dynamic torque(due to the accelerating joint's motion) Torque that the joints will need to bear for a given set of motions.

I have looked on the web and found tools like the ROS-MoveIt Visualiser, Gazebo, V-REP which let me visually see a robotic arm and simulate the position logic and external factors like collisions etc. But I have been unable to simulate/calculate dynamic torque values from these tools.

Ideally, I'd want to define a fixed motion of the end effector(i.e. move the robot between 2 positions) and measure the Torque(both static and dynamic) during that particular move.

These torque values are essential for selecting the optimum motors and gearboxes for my design and payload.


问:
Programming Robots with JavaScript
As somebody who is spending the majority of his time programming in JavaScript, what's the best route to get into small-robotics without needing to deviate too much from my current language focus?

Are there any project kits or tools that make use of the JavaScript language that might make the field more approachable for developers like myself? I would even be interested in virtual environments where all code is executed in a simulation.

答: Microsoft Robotics uses a protocol called Decentralized Software Services Protocol (DSSP) and they released the specs under a license that allows anyone to implement it in any language. The DSSP protocol is totally compatible with current web standards and I think it would be a great idea to implement it in JavaScript and NodeJS. That can make it possible for your node application to interact with any DSS robotics services available today.</p>

Title: Programming Robots with JavaScript


答:
I think you may be going about this problem wrong. If you find a simulator that reports joint torques, then what? Are you going to iterate through every possible start and end location?

You should only need to evaluate the worst-case motion. Worst case static torque would be with the arm straight out carrying maximum load, and worst case dynamic torque would probably be whatever the largest range of motion would be while fighting gravity.

Evaluate the worst-case scenarios (not necessarily the same for each joint, by the way!) and you're done.


问:
Find object using only distance
I'm working on a extremely simple robot (very first project) that attempts to find the source of a Bluetooth signal. There are two motors that drive the platform and each has an encoder. We've already used a Kalman filter to calculate the approximate distance to the Bluetooth beacon within reasonable error.

I worked out a manual solution using some trig that solves the problem in theory, but it fails if there is any error (For example, it attempts to turn 73 degrees, but turns 60).

My question is how can I reasonably drive the motors based on the encoder data to continuously minimize the distance to the signal? Furthermore, is there a generic solution to problems like these? (I guess you might call it a stochastic "Hotter/Colder" problem)

Thanks in Advance.

答:
There are two challenges that you will have to address. First is localization of the robot relative to the Bluetooth source; second is the controller that will drive the robot to the source.

To localize the robot, I would consider using a triangulation method. One robotic platform that addresses a similar problem is the Kilobot, which is used in swarm robotics research. The Kilobot has an IR sensor, which it uses to determine the distance to its neighbours--this sensor is very susceptible to noise. Furthermore, the Kilobot uses vibrating motors to move, which are even worse for control than low quality motor encoders. The triangulation method is given on page 794--the only difference will be that your robot will be green and the source will be blue. To triangulate, you must take a minimum of three relative distance measurements from the source at different known locations (approximated due to dubious encoder quality)--you can now use this coordinate as a desired position for the controller.

To control the robot, we need to drive the robot to the source by applying control inputs. Because you don't have any specific robot in mind, let's assume that you have a two-wheeled differential drive robot (TWDDR). TWDDRs can be modeled with unicycle dynamics of the following form: $$\dot{z}=\left[\begin{matrix}\dot{x}\\ \dot{y} \\ \dot{\theta} \end{matrix}\right] = \left[\begin{matrix}cos(\theta)&0\\sin(\theta)&0\\0&1\end{matrix}\right] \left[\begin{matrix}v\\\omega\end{matrix}\right],$$ where $x$ and $y$ are Cartesian coordinates of the robot, and $\theta \in (-\pi,\pi]$ is the angle between the heading and the $x$-axis. The input vector $\left[v, \omega \right]^T$ consists of linear and angular velocity inputs. For simplicity, I will assume that you can specify these inputs directly, which is reasonable for most off-the-shelf robots--if you want to implement this from scratch, then you have to specify velocities for the left and right wheels.

Driving the robot to the source is equivalent to shifting the origin of the state and driving the state of the robot to 0. For unicycle robots, a easy method of control is achieved by controlling a point, which is holonomic, some small distance $l$ away from the center of the the two wheels rather than controlling the unicycle robot directly. To do this, we can derive the following rotation matrix to transform the control law of the robot to the control law of the point: $$\dot{p}=\left[\begin{matrix}\dot{p_x}\\\dot{p_y}\end{matrix}\right]=\left[\begin{matrix}\text{cos}(\theta)&-l\text{sin}(\theta)\\\text{sin}(\theta)&l \text{cos}(\theta)\end{matrix}\right]\left[\begin{matrix}v\\\omega\end{matrix}\right]$$

$\dot{p}$ is the velocity of the point being controlled, and it is decomposed into its $x$ and $y$ components.

At this point, control is quite simple; we control the point directly! The dynamics become: $$\dot{z}=\left[\begin{matrix}\dot{x}\\ \dot{y} \\ \dot{\theta} \end{matrix}\right] = \left[\begin{matrix}cos(\theta)&0\\sin(\theta)&0\\0&1\end{matrix}\right] \left[\begin{matrix}v\\\omega\end{matrix}\right]=\left[\begin{matrix}cos(\theta)&0\\sin(\theta)&0\\0&1\end{matrix}\right] \left[\begin{matrix}cos(\theta)&sin(\theta)\\-\frac{sin(\theta)}{l}&-\frac{cos(\theta)}{l}\end{matrix}\right]\left[\begin{matrix}\dot{p}_x\\\dot{p}_y\end{matrix}\right],$$Setting $$\dot{p}=u=\left[\begin{matrix}x_{desired}\\y_{desired}\end{matrix}\right],$$ accomplishes the objective of driving the robot to the desired pose, where $u$ is the input, and $[x_{desired},y_{desired}]^T$ is the location of the source.

The gif below uses this controller, driving all of the robots from arbitrary initial positions to the desired position at $(-5,-5)$.

I have glossed over the challenges of noisy sensor and actuators, but the core idea has been presented--both triangulation and control should be possible in simulation, and with a little tweaking, it should work on a physical system.

Title: Find object using only distance


答:
OpenRave is another good library that will calculate dynamic torques.  Use the ComputeInverseDynamics function.  Here is a python example:

```<code>robot.SetDOFValues(dofvalues)
robot.SetDOFVelocities(dofvelocities)
torques = robot.ComputeInverseDynamics(dofaccelerations)
</code>```

or

```<code>torqueconfiguration, torquecoriolis, torquegravity = robot.ComputeInverseDynamics(dofaccelerations,None,returncomponents=True)
</code>```

Body:
OpenRave is another good library that will calculate dynamic torques.  Use the ComputeInverseDynamics function.  Here is a python example:

robot.SetDOFValues(dofvalues)
robot.SetDOFVelocities(dofvelocities)
torques = robot.ComputeInverseDynamics(dofaccelerations)

or

torqueconfiguration, torquecoriolis, torquegravity = robot.ComputeInverseDynamics(dofaccelerations,None,returncomponents=True)


问:
Obstacle Avoidance while Navigating
I need some ideas for strategies or algorithms to apply on these strategies to perform obstacle avoidance while navigating.

At the moment I'm doing offline path planning and obstacle avoidance of known obstacles with an occupancy grid. And running the A* algorithm over the created matrix. After that my robot follows along the resulting trajectory. This is done by splitting the whole trajectory into sub-path. The robot adjust it's heading to the new target and follows the straight line. The robot is controlled by a fuzzy logic controller to correct deviations from the ideal line (steering) and adjusting the velocity according to the steering action and distance to the target. So far so good. And it's working very well.

As sensor system, I solely use the Google Project Tango (Motion Tracking and Area Learning for proper path following). Now I want to use the depth perception capability of the device. Getting the appropriate depth information and extracting a possible obstacle is done with a quite simple strategy. The robot analyses the depth information in front of the robot and if any object is in between the robot and the target point of the sub-path, an obstacle must be there.

Now I'm wondering how to bypass this obstacle most efficiently. The robot is only aware of the height and width of the obstacle, but has no clue about the depth (only the front of the obstacle is scanned). Feeding the occupancy grid with this new obstacle and running again the A* algorithm is not effective, because of the missing depth. One possible strategy I could imagine is estimating a depth of the length of the grid cell, re-plan and continue the navigation. If the robot faces the same obstacle again, the depth is increased by the size of one additional grid cell length. But I think this is extremely ineffective.

The requirement is to only use the Google Project Tango and no additional sensors, such as ultrasonic to sense the sides.

Update 1

The first picture illustrates the given trajectory from the path planning (orange). The gray and blue data points are the sensed obstacles in front of the robot. The notch behind the blue obstacle is actually the wall, but is shadowed by the blue obstacle. Image 2 shows the same scene just from a different perspective.

The issue I have to treat is, how to optimally bypass the blue obstacle even I don't know how deep it is. Driving to the left and to the right only to capture better data points (to generate a 3D model) is not possible.

Update 2
Yes, I'm using a depth sensor, the one integrated in Google Project Tango. It's a visual measurement. A infra-red laser beams a grid onto the objects and a RGB-IR camera capture these information and evaluates the appropriate depth information.

答: I think that vector field histogram method should be a good solution here. It's a method of local motion planning (avoiding local obstacles while navigating to a global target). It involves mapping measurements into cartesian occupancy grid, and making a polar obstacle density histogram from that grid. Later the direction with lowest obstacle density and closest to the desired target is selected.

Title: Obstacle Avoidance while Navigating


问:
How does a QuadCopter Startup work ? Will they tune every copter before releasing to market?
We know that a quadcopter needs to be tuned to its perfect PID values to minimise the pitch, roll , yaw errors and etc., Before releasing to the market will they tune every unit and ship it ? Or a any different algorithm is used which doesn’t require any tuning ? Because every motor/ESC or a chassis will not be exactly same, which will add to the noise. </p>

答:
If you want to build thousands of drones, you will use the same ESC, the same motor, the same chassis on each drone, with an assembly process that will make every drone identical. Therefore, you'll have less than 1% of variation on your mechanical characteristics (momentum, weight, and so on). This is far less than the variation of propellers performances due to temperature, pressure, and hydrometry. There is no reason to worry about that, automation is done to deal with it.

PS: it's also less important than the imperfection you introduce by tuning your drone by hand. The tuning of a PID (or any other regulator) is never perfect.


问:
Up to what force is a servo motor a reasonable choice as an actuator?
I'm working on an application where I need to apply a linear or angular force to operate a linkage mechanism, but I don't (yet) know what amount of force I will need. I anticipate that it will be less than 4.5 kg (44 N). The travel distance on the linkage input should be less than 15 cm.

As I look through available servos, they seem to exist firmly in the scale-model realm of remote control vehicles, and as such I am uncertain if any will be suitable for my application. For example, one of Futaba's digital servos, the mega-high torque S9152, is listed at 20 kg/cm.

From what I understand, this means that at 1 cm from the center of the servo shaft, I can expect approximately 20 kg force. If I wanted 15 cm of travel distance I would need roughly a 10.6 cm radius, which would diminish the applied force to 20 / 10.6 = 1.9 kg, well below the 4.5 that might be required.

Question:

Is my understanding and calculation even remotely accurate? Should I be looking at other types of actuators instead of servos? They seem to become prohibitively expensive above 20 kg/cm torque. (For the purposes of this project, the budget for the actuator is less than $250 US.)

For my application, I'd like to have reasonable control over intermediate positions across the travel range, good holding power, and fairly fast operation. For this reason I have dismissed the idea of using a linear actuator driven by a gearmotor and worm drive.

I am relatively new to robotics in the usage of motorized actuators, but I've used pneumatic cylinders for many years. For this application, I can't use pneumatics.

Edit:

Per comments, some additional constraints that are important:

Linkage Details: The linkage is a planar, one degree-of-freedom, part of a portable system (similar to a scissor lift mechanism). It is for a theatrical effect where the motion is amplified and force reduced (speed ratio and mechanical advantage are < 1).

Power: It will be carried by a person. As such, the actuation needs to be battery-operated, as no tubing or wiring can tether the person. Tubing or wiring that is self-contained is okay. Because this is a portable system, battery-power will be used. The control system will be designed specifically for an appropriate actuator. Rechargeable batteries up to 12V will most likely be employed. Actuators could operate on as high as 24V. Ideally a motor would not exceed 1-2 amperes draw, but as it is not in continuous operation, this is not a hard limit.

Not Pneumatic: I've considered pneumatic actuation, using CO2 cartridges, for example, but the client would prefer not to use pneumatics. Also, the ability to stop/hold at intermediate points in the motion range is desirable, and somewhat more complicated to do with pneumatic actuators.

Speed: An ideal actuator will be able to move the input coupling 15 cm in 1-2 seconds.

Weight: Weight constraints are not well-defined. As it will be carried by a person, it should be moderately lightweight. The actuator itself should probably be less than 1kg, but certainly this can vary. (The rest of the mechanism will probably be 6-8 kg.)

Size: The primary size constraint is that everything must fit within a space measuring no more than 500 x 500 x 120 mm (H x W x D). The linkage mechanism extends from and collapses outside the enclosure, parallel to the width.

Noise: The quieter the better, but noise is the least priority.

Servos seemed like the best choice for the job, but they don't seem to be available with the sort of torque I need.

答: A linear actuator would be the ideal solution. You can find them very cheaply on sites like ebay or specialised robotics stores. If you need to keep position there are models avaliable with built in position sensors and endstops. </p>


问:
ROS and Kinect data without callbacks
I'd like to get rgb and depth data from a kinect, and I found a little tutorial here: http://wiki.ros.org/cv_bridge/Tutorials/ConvertingBetweenROSImagesAndOpenCVImagesPython. It's fine, but what I'd like is to be able to get the data on demand, and not as whenever the callback is triggered, assuming I won't try to get the data faster than it can be available. I'd appreciate any help - do go easy on the ROS jargon, I'm still learning...Thanks.</p>

答:
If you like to get rgb and depth or euclidean space coordinates of any point from the kinect sensor then you can try this code in ros node:

```<code>void
cloud_cb (const sensor_msgs::PointCloud2ConstPtr& input)
{
 pcl::PointCloud<pcl::PointXYZRGB> output;
 pcl::fromROSMsg(*input,output );
 pcl::PointXYZ P[479][639];
    for(int raw = 0;raw<479;raw++)
    {
        for(int col = 0;col<639;col++)
        {
            P[raw][col] = output.at(col,raw);
        }
    }
 sensor_msgs::PointCloud2 cloud;
 pcl::toROSMsg(output,cloud);
 pub.publish (cloud);
}
</code>```

Here p[raw][col] is the main structure which contains the rgb data and depth along with x,y coordinate data. To access the rgb data just use p[raw][col].r ... to access depth data use p[raw][col].z. Was this the answer ur looming for.

Title: ROS and Kinect data without callbacks

Body:
If you like to get rgb and depth or euclidean space coordinates of any point from the kinect sensor then you can try this code in ros node:

void
cloud_cb (const sensor_msgs::PointCloud2ConstPtr& input)
{
 pcl::PointCloud<pcl::PointXYZRGB> output;
 pcl::fromROSMsg(*input,output );
 pcl::PointXYZ P[479][639];
    for(int raw = 0;raw<479;raw++)
    {
        for(int col = 0;col<639;col++)
        {
            P[raw][col] = output.at(col,raw);
        }
    }
 sensor_msgs::PointCloud2 cloud;
 pcl::toROSMsg(output,cloud);
 pub.publish (cloud);
}

Here p[raw][col] is the main structure which contains the rgb data and depth along with x,y coordinate data. To access the rgb data just use p[raw][col].r ... to access depth data use p[raw][col].z. Was this the answer ur looming for.


问:
Servo motor considerations for a quadruped
I'm building a quadruped and I'm not sure of the features I should be looking for in a servo motor. e.g. digital vs analog, signal vs dual bearings. Some of the ones I'm considering are here</p>

答:
If you are not on the budget, go for the digital with metal gears. Basically, higher the torque better your bot will be. For the legged bots speed of the servo is not an issue but torque is.
To be sure that servo will have enough torque, you will need to roughly calculate the mass of the bot, divide it by number of legs - 2. As during the walk two legs will be in the air and other legs need to be able to hold the mass of the bot.

Also consider how many DOF one leg will have. In 3 DOF leg systems, one servo is used for rotation of the leg and it will not be under heavy load. So that one can be "cheaper" servo. Consider that on 4 legged system you will need 12 servos. Having 4 of them cheaper would mean more money for sensors or lighter material for construction ...


答:
It sounds like you need a costmap.  I would project the 3D points down onto a 2D plane.  (At least the points that correspond to the height of your robot).  Then make an occupancy grid where each cell is labeled as either "free space", "obstacle", or "unknown".  You'll get something like this:

Where white is free space, blue is obstacle, and grey is unknown.

Points from your point cloud become the "obstacle" class obviously.  Use simple ray tracing so that points between the robot and obstacle are "free space".  And everything else is unknown.  (i.e. points beyond the obstacle or max distance of your sensor).  Then use these as costs in your A* path planner.  Allow the robot to plan paths through unknown space, but make it cost more than free space.

Other notes:

Typically, you bloat the obstacle cells by at least the robot's radius so it doesn't get too close to them.

You can do this probabilisticly if your robot/sensor has noise, or you are in a dynamic environment.  Here, "free", "obstacle", and "unknown" are now floating values based on a number of past sensor readings.

Title: Obstacle Avoidance while Navigating

Body:
I need some ideas for strategies or algorithms to apply on these strategies to perform obstacle avoidance while navigating.

At the moment I'm doing offline path planning and obstacle avoidance of known obstacles with an occupancy grid. And running the A* algorithm over the created matrix. After that my robot follows along the resulting trajectory. This is done by splitting the whole trajectory into sub-path. The robot adjust it's heading to the new target and follows the straight line. The robot is controlled by a fuzzy logic controller to correct deviations from the ideal line (steering) and adjusting the velocity according to the steering action and distance to the target. So far so good. And it's working very well.

As sensor system, I solely use the Google Project Tango (Motion Tracking and Area Learning for proper path following). Now I want to use the depth perception capability of the device. Getting the appropriate depth information and extracting a possible obstacle is done with a quite simple strategy. The robot analyses the depth information in front of the robot and if any object is in between the robot and the target point of the sub-path, an obstacle must be there.

Now I'm wondering how to bypass this obstacle most efficiently. The robot is only aware of the height and width of the obstacle, but has no clue about the depth (only the front of the obstacle is scanned). Feeding the occupancy grid with this new obstacle and running again the A* algorithm is not effective, because of the missing depth. One possible strategy I could imagine is estimating a depth of the length of the grid cell, re-plan and continue the navigation. If the robot faces the same obstacle again, the depth is increased by the size of one additional grid cell length. But I think this is extremely ineffective.

The requirement is to only use the Google Project Tango and no additional sensors, such as ultrasonic to sense the sides.

Update 1

The first picture illustrates the given trajectory from the path planning (orange). The gray and blue data points are the sensed obstacles in front of the robot. The notch behind the blue obstacle is actually the wall, but is shadowed by the blue obstacle. Image 2 shows the same scene just from a different perspective.

The issue I have to treat is, how to optimally bypass the blue obstacle even I don't know how deep it is. Driving to the left and to the right only to capture better data points (to generate a 3D model) is not possible.

Update 2
Yes, I'm using a depth sensor, the one integrated in Google Project Tango. It's a visual measurement. A infra-red laser beams a grid onto the objects and a RGB-IR camera capture these information and evaluates the appropriate depth information.


问:
Generalized Voronoi Diagram
I need to compute the Voronoi diagram for a map with some obstacles but I can't find any pseudo-code or example in MATLAB.

The "voronoi" function in MATLAB works with points, but in this case the obstacles are polygons (convex and non-convex). You can see the map in the attached image.

Because the obstacles are polygons I found that the Voronoi algorithm needed is the GVD (Generalized Voronoi Diagram).

Can anyone help with code or examples on internet explaining how to compute this GVD?

答: I bet some simple OpenCV code could do this.  I think you would first get the endpoints of the contours.  Then feed those points into the voronoi generator.</p>

Title: Generalized Voronoi Diagram


问:
Path planning of 2 arm 4dof Robot
I am working on path planning for a 2 arm 4dof (2 dof for each arm) robot. I am currently using a centralised planning methodology (considering the multi robot system as a single one with higher dof, 4 in this case) and A* algorithm to find the shortest path. The problem with this algorithm is its high computation time.Is there any way to reduce the computation time while still obtaining the shortest route ?

Note:decentralised path planning is not good enough for my case.

答:
When I was using A* to navigate mobile robot in environment I've got this same issue. I am assuming that you are using cubic representation (nodes) of the environment where you have some cubes that represents free space and obstacles. What you can do is to increase the size of nodes that represents the environment. This way there will be less nodes the A* algorithm needs to process.

Another thing you can do is to cancel nodes that are unreachable by robotic arm or nodes you don't want the arm should move in.

Next thing is that after you get the path, the robotic arm will be moving as close as possible to the obstacles because in most scenarios it is the shortest path. You can solve this issue by increasing the transition value (cost) between the nodes near the obstacle.

Title: Path planning of 2 arm 4dof Robot