问:
What is a good approach for outlier rejection during real time data filtering?
I'm trying to finish up a localization pipeline, and the last module I need is a filtering framework for my pose estimates. While a Kalman filter is probably the most popular option, I'm using cameras for my sensing and I wouldn't be able to ensure the kinds of noise profiles KF is good for, I doubt it would work as well with suddenly appearing outliers in my poses: so I am looking for other options which can work with real time data and be immune to outliers.

One thing I came across is a Kalman filter with a threshold based update rejection, something like Mahalanobis distance: but I don't know if this is completely applicable because the localization would be performed in real time, and it's not like I have a large set of 'good poses' to start with. The end result I'm expecting is something like smoothing, but without access to a full set of values. Another option I found is from a paper that proposes a 'robust Bayesian weighted Kalman filter' that's good for real time outlier rejection, but I still need to read through it: and I don't have much experience with filtering/smoothing, so any suggestions would be very helpful, perhaps about a decent go-to mechanism for this?

答:
It is both acceptable and standard to use camera observations with a  Kalman filter if you are talking about landmark positions in pixel or real-world space. Pixel space observations are usually randomly Caushy distributed but it turns out the Gaussian Kalman filter works pretty well in this case.

The method you're describing using the Mahalonobis distance to reject updates is $\chi^2$ gating, where you use the "running" covariance of the estimated mean in order to determine if the candidate observation is not within a given confidence interval.

$$\chi^2 = (z - \hat{z})^\top S^{-1}(z - \hat{z})$$

You then substitute $\chi^2$ with your chosen confidence interval, which is usually chosen from a table or graph given the degrees of freedom of the system (rank of $S$).

For example $\chi^2_{0.01} = 16.812$ for 6 degrees of freedom, which means if $\chi^2 \ge 16.812$ then there is a $99\%$ chance it is an outlier and you should reject it.
In order to do this you need to track the covariance $S$, the easiest way of which is to use a Kalman Filter.

A more simple method is to threshold on the Median Absolute Deviation metric.

The KF and MAD methods involves logging a small dataset and characterising variance.

NOTE:
The downside to any rejection method is that if you start on an invalid pose and you have no mechanism by which to "reset", you will always be locked on an invalid pose. A simple mechanism to circumvent this to count how many consecutive rejections are made, and if it's above say 2 sec worth of data then force the filter to update (ignore the rejection) and reset your $P$ matrix.


问:
Determining pose from ar_track_alvar message in ROS
I am using the ar_track_alvar package in Indigo to detect AR Tags and determine their respective poses. I am able to run the tracker successfully as I can visualize the markers in RViz. I give the following command to print the pose values

rostopic echo /ar_pose_marker

and I get the following output indicating that the poses are determined.

```<code>header:
  seq: 0
  stamp:
    secs: 1444430928
    nsecs: 28760322
  frame_id: /head_camera
id: 3
confidence: 0
pose:
  header:
    seq: 0
    stamp:
      secs: 0
      nsecs: 0
    frame_id: ''
  pose:
    position:
      x: 0.196624979223
      y: -0.238047436646
      z: 1.16247606451
    orientation:
      x: 0.970435431848
      y: 0.00196992162831
      z: -0.126455066154
      w: -0.205573121457
</code>```

Now I want to use these poses in another ROS node and hence I need to subscribe to the appropriate ROS message('ar_pose_marker"). But I am unable to get enough information on the web on the header files and functions to use in order to extract data from the published message. It would be great if somebody can point to a reference implementation or documentation on handling these messages. It might be useful to note that ar_track_alvar is just a ROS wrapper and hence people who have used ALVAR outside of ROSmay also give their inputs.

UPDATE:

I tried to write code for the above task as suggested by @Ben in the comments but I get an error. The code is as follows

```<code>#include <ros/ros.h>
#include <ar_track_alvar_msgs/AlvarMarker.h>
#include <tf/tf.h>
#include <tf/transform_datatypes.h>

void printPose(const ar_track_alvar_msgs::AlvarMarker::ConstPtr& msg)
{
    tf::Pose marker_pose_in_camera_;

    marker_pose_in_camera_.setOrigin(tf::Vector3(msg.pose.pose.position.x,
                             msg.pose.pose.position.y,
                             msg.pose.pose.position.z));

}

int main(int argc, char **argv)
{
    ros::init(argc, argv, "pose_subscriber");

    ros::NodeHandle nh;

    ros::Subscriber pose_sub = nh.subscribe("ar_pose_marker", 1000, printPose);

    ros::spin();

    return 0;

}
</code>```

And I get the following error

```<code>/home/karthik/ws_ros/src/auto_land/src/pose_subscriber.cpp: In function ‘void printPose(const ConstPtr&)’:
/home/karthik/ws_ros/src/auto_land/src/pose_subscriber.cpp:17:53: error: ‘const ConstPtr’ has no member named ‘pose’
    marker_pose_in_camera_.setOrigin(tf::Vector3(msg.pose.pose));
                                                     ^
make[2]: *** [auto_land/CMakeFiles/pose_subscriber.dir/src/pose_subscriber.cpp.o] Error 1
make[1]: *** [auto_land/CMakeFiles/pose_subscriber.dir/all] Error 2
make: *** [all] Error 2
</code>```

Any suggestions?

答:
may be this would be useful to you,

```<code>#include <ros/ros.h>
#include <tf/transform_datatypes.h>
#include <ar_track_alvar_msgs/AlvarMarkers.h>

void cb(ar_track_alvar_msgs::AlvarMarkers req) {
    if (!req.markers.empty()) {
      tf::Quaternion q(req.markers[0].pose.pose.orientation.x, req.markers[0].pose.pose.orientation.y, req.markers[0].pose.pose.orientation.z, req.markers[0].pose.pose.orientation.w);
      tf::Matrix3x3 m(q);
      double roll, pitch, yaw;
      m.getRPY(roll, pitch, yaw);
      ROS_INFO("roll, pitch, yaw=%1.2f  %1.2f  %1.2f", roll, pitch, yaw);
      // roll  --> rotate around vertical axis
      // pitch --> rotate around horizontal axis
      // yaw   --> rotate around depth axis
    } // if
}

int main(int argc, char **argv) {
  ros::init(argc, argv, "arlistener");
  ros::NodeHandle nh;
  ros::Subscriber sub = nh.subscribe("ar_pose_marker", 1, cb);
  ros::spin();
  return 0;

}
</code>```

Thanks to http://ros-robotics.blogspot.de/

ContentLicense: CC BY-SA 3.0

Body:
may be this would be useful to you,

#include <ros/ros.h>
#include <tf/transform_datatypes.h>
#include <ar_track_alvar_msgs/AlvarMarkers.h>

void cb(ar_track_alvar_msgs::AlvarMarkers req) {
    if (!req.markers.empty()) {
      tf::Quaternion q(req.markers[0].pose.pose.orientation.x, req.markers[0].pose.pose.orientation.y, req.markers[0].pose.pose.orientation.z, req.markers[0].pose.pose.orientation.w);
      tf::Matrix3x3 m(q);
      double roll, pitch, yaw;
      m.getRPY(roll, pitch, yaw);
      ROS_INFO("roll, pitch, yaw=%1.2f  %1.2f  %1.2f", roll, pitch, yaw);
      // roll  --> rotate around vertical axis
      // pitch --> rotate around horizontal axis
      // yaw   --> rotate around depth axis
    } // if
}

int main(int argc, char **argv) {
  ros::init(argc, argv, "arlistener");
  ros::NodeHandle nh;
  ros::Subscriber sub = nh.subscribe("ar_pose_marker", 1, cb);
  ros::spin();
  return 0;

}

Thanks to http://ros-robotics.blogspot.de/


问:
How do monocular visual odometry algorithms work?
What is the core principle of a monocular visual odometry algorithm? I mean, after calibrating a single camera (undistortion etc.) images are fed into an algorithm - what exactly does this algorithm do with the images in order to get the translation/rotation between successive frames?

Do various mono algorithms use various techniques or is the core principle same everywhere? I see some libraries use image features (indirect approach) and some use pixel intensity (direct approach) but I am not really able to understand the principles from the papers... I can only see the algorithms use various methods of estimating the translation/rotation matrix (5-point, 8-point algorithms...).

Also, is it true that no mono algorithm is able to get the absolute scale of the scene? How does the relative scale work - is it set randomly?

I found following mono odometry libraries:

indirect methods (using image features)

Avi Singh via OpenCV (blog post) - uses Nister’s 5-point algorithm

VISO2 - uses 8-point algorithm (paper)

ORB_SLAM / ORB_SLAM2 - indirect approach?

direct approach (using whole edges etc.)

SVO: Fast Semi-Direct Monocular Visual Odometry (paper)

LSD-SLAM: Large-Scale Direct Monocular SLAM (paper) - needs ROS (but only for input/output)

DSO: Direct Sparse Odometry (paper)

I understand how stereo visual odometry works - they reconstruct 3D scene in each image frame and then compare (register) the point clouds of successive image frames and get directly the distance traveled like this - pretty simple principle.

答:
Monocular vision is a difficult and very interesting, particularly in its application to the general navigation problem. I will make an attempt at answering your questions, but if you find anything lacking, you can read through Szeliski's book Computer Vision: Algorithms and Applications.

What is the core principle of a monocular visual odometry algorithm?

Monocular or stereo, the objective of visual odometry is to estimate the pose of the robot based on some measurements from an image(s). It's hard to pin down a single core principle--Bayesian Probability Theory is likely to core principle, but epipolar geometry certainly important.

For stereo, the general idea is that if you know your camera parameters, and you know that the relationship between your camera is fixed, then a point $\textbf{p}$ that is viewed from both cameras projects onto each image plane an epipolar line segment. Using the epipolar plane defined by these line segments and the camera geometry, the distance to the point can be estimated, which can be used to estimate the pose of the robot.

For monocular vision, the task is trickier because there is only one camera. To get an image pair, an image is captured at time $t$; the robot is actuated, and another image is taken at time $t+1$ (e.g. a video stream). This pair of images can be used in the same way as any other stereo image, but because we don't know for certain the relationship between the cameras (due to deviations in motion from what the robot did and what it was instructed to do), in order to estimate the pose of the robot, the motion model has to be taken into account. In the end, monocular visual odometry is more difficult because there are more unknowns that have to be accounted for probabilistically.

What exactly does this algorithm do with the images in order to get the translation/rotation between successive frames?

The main objective is image matching. While there are numerous approaches to this problem, some approaches find feature point in the scene and match those between images to match the images themselves. A number of algorithms can be used to find feature points; SIFT is a good standard although other methods have been shown to outperform it. With features described, an algorithm that matches the points should be used; RANSAC is one such algorithm. Leveraging known relationships (such as accurate motion models or fixed cameras/projectors) can improve image matching.

Do various mono algorithms use various techniques or is the core principle same everywhere?

Regardless of the approach, the techniques will boil down to probability theory. That said, there are many approaches. Feature point matching is one approach, others, such as LSD-SLAM that you reference, advocate for using the pixel values directly rather than isolating feature points. Machine learning also has a role--convolutional neural networks have been very successful at solving vision problems, so you should be able to find a wealth of literature about them.

Is it true that no mono algorithm is able to get the absolute scale of the scene?

Getting accurate distance measurements is difficult for camera-based vision in general. The main problem is that the distance between the cameras is relatively small compared to points in the scene that are very far away. As for determining the scale of objects, that may not be a problem of monocular vision so much as reasoning. Humans know the relative scale of objects based on priors, which is a very important and related problem for computer vision and robot perception.


问:
Self learning maze solving robot using 8bit microcontroller?
I want to know if there is best algorithm and technique to implement self learning maze solving robot in 8 bit limited resource micro-controller? I was looking for some well optimized algorithm and/or technique. Maze can be of any type. Of-course first time it has to walk all the way and keep tracking obstacles it found.

I think best technique would be neural networks but is it possible to do this in such a short resources of 8bit? Any example online with similar kind of problem?

My wall detection is based on units, well, I have counted the wheel turns and it is almost 95% accurate in integers. For sensing the walls Ultrasonic range finding is used. Wheel can remeber its current position in let say, 3 feet staight, 2 feet right, etc.

答:
My understanding of your problem is that you would like to discover and navigate a 2D maze of irregular obstacles with a non-holonomic robot using a single forward-looking ultrasonic range sensor and wheel odometry.  This is a hard problem.

"Best" solution

Although a "best" or "optimal" solution to this problem possibly could be implemented on an 8-bit microcontroller, it is made up of 3 problems -- each nontrivial and frequently left to full-fledged  computing systems:

Enhancing your ultrasonic sensor to be able to differentiate between walls and corners, because echoes from a maze-like environment can confuse your sensor.

Exploring and mapping the space, typically done with a SLAM algorithm.  (This will assume that you get near-perfect localization information from your odometry approach to navigation.)

Using your map, compute a solution using a maze-solving algorithm

Achievable Solutions

Since the "best" solution is a tall order for an 8-bit microcontroller, focus on a "dumb" solution that actually works: use whisker sensors and the right-hand rule.

Going further, you could add a compass/accelerometer for navigation, use infrared sensors to  detect obstacles, and use a regular 2D grid with large gird squares.  That would be similar to the Micromouse competition (for example, this one), which also uses microcontrollers for maze solving.


问:
How to construct rotary turn table (S/J1 axis) from ball bearing?
For my robotics arm project I have recently come across the following ball bearing at low discount price which I think could make a great rotary table for my arm.

However it does not seem to have any mounting connectors, and the inner and outer rings are the same height.

My mechanical creativity is a bit limited, but my goal is to drive (spin) it with a large stepper motor (I have 34 and 42 series available which, even ungeared, should be enough for my smaller arm). On top of the rotary table that I'm trying to create will sit a U-channel that will hold the rest of the robot arm. So in the bottom of that channel I will drill holes and connect it to... something.

If anyone could point me to, recommend, or create a simple design - I have access to basic metalworking tools and scrap aluminum - that would be absolutely fantastic. My main goal is to work with what I have: the bearing, stepper motors, aluminum, other things at a standard hardware store.

BTW, here is how I refer to the standard robot axes (of a 6-DOF industry bot) by name.

答:
To get the advantage of having a bearing, you need a hole to fit it into. Typically this will require a lathe or mill. A simple example of a home-brew rotary table shows how; searching for 'rotary table plans' finds many google image results. Basically you mount the bearing in a hole in one plate, mount the other plate to the inner ring of the bearing, and bolt them together. The two plates are machined to touch each other and the inner plate is machined to not touch the bearing outside of the inner ring.

These bearings are primarily for radial loads. Deep groove bearings also have some axial load capability, but it will be less than the value quoted which will be the radial load (axial rating is between 0.25 and 0.5 times the radial).

In these types of rotary tables, the bearing's main role is to centre the rotating parts with less wear than a simple pivot will have, and the axial and moment loads are taken by sliding faces lubricated by oil. If you want higher speed operation, then you may also need a thrust bearing for the axial/vertical load or some other configuration, and you may need two bearings separated to handle moments rather than one bearing and sliding faces. Essentially single row bearings don't handle moments at all, and a long robot arm with a weight on the end may be a significant moment.

To get there without a lathe, if you can find some square, thick walled box section which is just larger than your bearings diameter you may be able to mount one at each end with a little filing, and use something to prevent the bearings moving further into the section. Then you can put a shaft through the bearings and you will have a very rigid mounting that handles all three loads.


问:
Granite devices IONI servo drive
The IONI drive can accept a new setpoint using an analog input.  How many bits is the ADC on the IONI drive?  Is it 12, or 16 bit?</p>

答: Although the Analog setpoint resolution isn't documented on the Granite Devices Wiki, the ADC in IONI is 12 bits.</p>

Title: Granite devices IONI servo drive


问:
Need help modelling and coding a feedback scenario

Above illustration is the basic setup for the question. The scenario will be the following:

A potentiometer(providing 0 to 5V) is an analog input to A0. This
  potentiometer voltage is converted to PWM(pin9) which controls a fan
  M1. Which means the human controls directly the M1 fan speed.

This directly speed-controlled M1 fan creates air pressure on a sensor
  Sen1.

On the other hand I want M2 fan to reach to a speed(via pin10 PWM)
  such that Sen2 should output the same voltage as Sen1. Which means
  eventually voltage at A1 analog input should be equal to A2. So one
  can achieve same air pressures at Sen1 and Sen2.

I'm not experienced in PID or other type of controls. I would be glad if someone can help me to relate parameters and code this scenario. I was suggested to ask here instead of Arduino stack-exchange.

edit: Do you think I can use the following idea.  If I make changes as following: PWM to LED in that example will be PWM to M2 in mycase; poti input in the example will be Sen1 input in mycase. And LDR input in the example will be Sen2 input in mycase. Do you think it is worth to try?

答:
I'm not sure I understand why you're taking such a long "around the block to cross the street" approach to this problem. Your basic steps are:

1.  [The human controls directly the] potentiometer voltage [which] is converted to PWM... which controls a fan M1.

2.  This directly speed-controlled M1 fan creates air pressure on a sensor Sen1.

3.  [The] M2 fan [should] reach to a speed(via pin10 PWM) such that Sen2 should output the same voltage as Sen1.

4.  Which means eventually voltage at A1 analog input should be equal to A2.

5.  So one can achieve same air pressures at Sen1 and Sen2.

If, per step 4 above, you think the analog input voltages should be the same, then why not just feed the human-reference input provided at step 1 to both fans?

Another way to think critically about this problem is to recognize that I, personally, have no idea what voltage is required to get a fan to achieve a particular air pressure. That is, maybe you as the designer should choose some maximum allowable air pressure (perhaps dictated by the capacity of the fan), and then have the human's reference be interpreted as a desired air pressure instead of a desired fan voltage.

Then, the desired air pressure is the reference, the actual air pressure is the feedback, and you use the error between the two to create your PID loop.

This is basically what you're talking about for fan two, where you have fan two setup in a "follower" mode.

The problem I would see with the approach you've requested is in your statement in the comments:

The flow of M1 might affect M2's flow a bit.

I'm assuming that this implies that M2's flow might also affect M1's. So imagine this:

M1 is running at 50%.

M2 is not running.

M2 gets M1's 50% flow as a reference.

M2 spins up, but a portion of its flow is sensed by M1's sensor, Sen1.

M1's flow sensor now reads 50% + X%.

M2 gets M1's 50% + X% flow as a reference.

M2 spins a little faster, but a portion of its flow is sensed by M1's sensor, Sen1.

Repeat 5-7 until M2 is spinning at full speed or the system naturally stabilizes at some value higher than probably intended.

If you have both PID loops (for M1 and M2) tuned to the same response time, then there is a high probability that they'll wind up "fighting" each other - both fans spin up at the same time, overshoot, trigger each other to slow down, and you may find that neither fan ever settles at the desired setpoint.

The two approaches I would take to inhibit this kind of behavior would be to intentionally tune one loop slower than the other. The slower system acts as a "base load" supplier, the faster loop responds to disturbances. This also assumes there's some moderate cross-flow between the two systems.

The other way you could try to do this is to have one control loop, where the output signal is sent to both fans (instead of being tailored on a per-fan basis) and maybe the output signal (Sen1 and Sen2) is averaged to produce one feedback.

I'm not sure what the application here is so I can't provide any meaningful advice beyond what I've posted above. You could consider ducting or physically relocating the fans to prevent cross-flow between M1 and M2.

I'll say that steps 4 and 5 above are generally conflicting - due to variations in motor and sensor construction, impedances, etc., you will probably find that voltages A1 and A2 are not equal when the outputs of Sen1 and Sen2 are equal, and vice-versa.


问:
Wake up iRobot Create 2 while on dock
I have a 7 pin cable connected to the OI port of my Create 2. While the Create is on the floor away from the dock, if I touch the BRC pin (7) to the ground pin (5), the Create wakes up, makes a beep, and the green Clean button light turns on.

However, if I put the Create on the dock and let it sit for several minutes and then touch the BRC pin to the ground pin, nothing happens.

Is there a method for waking up/starting the Create while it is on the dock/charging?

(Note: I have seen this answer and it does not solve the issue IRobot Create 2: Powering Up after Sleep)

If I send a command or try to fetch sensor data after the Create has been sitting on the dock for several minutes, I get no response and the Create doesn't do anything (no lights, sounds, movements, etc).

While the Create is already awake, the response from a restart command (0x7) looks like this

```<code>bl-start
STR730
bootloader id: #x4718535E 7DDBCFFF
bootloader info rev: #xF000
bootloader rev: #x0001
2007-05-14-1715-L
</code>```

EDIT: simplified the scope of the question.

EDIT 2: added info from Jonathan's questions.

答:
With the firmware you have, the robot does not sleep on the dock. Assuming the baud rates are correct, it will still respond to sensor fetches and should respond to the 'clean' request.
Pulsing the BRC pin could be changing the baud rate or could be doing some other unintentional behavior. </p>

Title: Wake up iRobot Create 2 while on dock


问:
Robotics with Kinect
I want to learn robotics and really interested in making a robot based on Kinect sensor.

I see so many projects like this one, and just wondering how it works on top level. I downloaded Kinect SDK and did some basic tutorials, but I just don't think that Microsoft SDK is the library to use for real robotics projects. Any suggestions where to start and what library to use? Any good books in particular or online resources?

答:
As a follow-up (albeit after 2.5 years) I would like to add some other things that I was able to work on and might possibly help you / anybody else foraying into this field.

Option 1) Use an existing robot hardware and add your own sensors and actuators:

For e.g.: I had access to a iRobot Create (Roomba without the vaccum cleaner). So I modified that hardware-wise by adding a long "neck" made out of a plastic tube that was lying around (I had to add a tough-plastic platform on top of the Create on the screws provided so that I could fix whatever I wanted to this plastic platform (see image below to get an idea).

You can then interface with the Roomba from your laptop or other PC using several Roomba interface packages available (I used the one for Matlab since my CV code was in Matlab). I connected a Kinect v2 to my laptop and thus I had complete control over the robot as well as was able to acquire data from the Kinect. The wires and electronics that you see on the robot are from my previous attempt to supply power directly from the robot battery to the Kinect v1 that I was using on it earlier to make the robot completely mobile. For the v2 I did not bother with the power conversion as it was complicated so I just used tethered power supply for the kinect v2. Since I had a laptop (Thinkpad with usb 3.0 that the Kinect v2 needs), the interfacing with Kinect v2 was relatively easy; I used the libfreenect2 for running Kinect v2. I called it as a system call from my Matlab image processing code.

The advantage of this system is that it's cheap. You only have to pay for the robot base, the Kinect, and any other hardware you buy. The disadvantage is that it's very slow moving robot since it's top heavy. The Kinect v2 also had to be tethered. This setup cost me around \$ 300 since the base was pre-owned from ebay, and the Kinect costs ~$200. Not including any additional hardware costs.

Option 2): Build your own robot hardware. This option is more time+money consuming. The way I did this was I purchased a 6-wheel drive robot chasis (it's not cheap; around $300) from sparkfun. To this I added a pan-tilt system from servocity. And to this PT system I added a asus xtion (since it's light). The motors of the robot and the PT system were controlled by a gorilla controller board, which received commands from a Jetson TK1 which was processing the Asus depth data, and sending commands to the motors. Unfortunately I do not have the pictures on my machine right now; but it looks a bit like a cross between Wall-E and a 6WD military vehicle ;) . Jetson TK1 is considerably powerful and I've run Kinect v1, Asus Xtion, and Kinect v2 on it (it has a usb 3.0 as well).  For Kinect v1 and Asus I used OpenNI2 and for Kinect v2 I used libfreenect2 (for both these robot options I used Ubuntu btw). But since the PT system was present I stuck with the lightweight Asus sensor.

The advantage of this system is that you can change it however u want with different hardware or electronics. The disadvantage is that you've to do a lot of motor controller programming on your own which means you've to understand how to control motors using PWM signals, for example. This setup aint cheap. Cost me around $800-900 without the additional hardware I had to purchase to make it work.

In both these options I did not use any odometry data coming from the wheels or sensors (e.g. how many rotations of the wheel, data from the IR sensors on the Create etc). I relied entirely on vision data.

Hopefully this helps. Let me know if you have questions.

Title: Robotics with Kinect


问:
Determine what the rotation axis is given a rotation matrix
How do I find out around which axis the coordinate system has to rotate, if the rotation matrix is given?

$ {^{a}R_{b} } $ = $ \left(\begin{matrix} 0 & 1 & 0 \\ -1 & 0 & 0 \\ 0 & 0 & 1 \\\end{matrix}\right)$

$ {^{a}R_{c} } $ = $ \left(\begin{matrix} 0 & 0 & 1 \\ 1 & 0 & 0 \\ 0 & 1 & 0 \\\end{matrix}\right)$

For $ {^{a}R_{b} } $ I thought, that it has to be a rotation around the z-axis, because
$R(z,\theta) =  \left(\begin{matrix} cos(\theta) & -sin(\theta) & 0 \\ sin(\theta) & cos(\theta) & 0 \\ 0 & 0 & 1 \\\end{matrix}\right)$

the values at the positions $a_{13}, a_{23},a_{33},a_{32},a_{31}$ of $ {^{a}R_{b} } $ and $R(z,\theta)$ are identical.

So I solved $cos(\theta) = 0$ =>$\theta = 90° $ => 90° rotation around z-axis.

But how do I solve it, if there is more than 1 rotation, like for $ {^{a}R_{c} } $?

答:
For solving individual cases, if you do not want to script yourself, you can enter the matrix in this Online Calculator for 3D Rotation Formats, switch the output to degrees, and see the axis-angle output.

In case your of ${}^aR_c$, it outputs a 120 degrees rotation around the axis [0.5773503, 0.5773503, 0.5773503].


问:
What microcontroller and parts will work for the robot project described bellow?
I want my robot to contain about 20 MB of data or a little more, this will be mostly in text, some pictures so that it can recognize one or two particular objects.

So obviously, I want a camera connected to it and I want it to be able to save images (no need to display them, just save, I would access them through a PC later. However, I do want it to have an output text screen, i.e.: I want it to be able to display text on a screen, just plain text.)

I also want it to be controlled by speech recognition, so it has to be able to accept voice input. Also, iI want it to be capable of producing voice output, but only one or two prerecorded sounds.

Lastly, an infrared sensor will be used for distance gauging and a push button one for contact.

Summary of needs:

Microcontroller and parts required to:

store at least 20 MB of data, text (the microcontroller needs to be
able to access this text and run algorithms on it, GET data only, not
change it), and images (images only for image recognition)

allow saving images taken by the camera

speech recognition as input

output audio (only one or two prerecorded sounds)

output plain text on a screen

equip an infrared sensor for measuring distance and contact
push buttons for detecting contact

If relevant, I am using tracked wheels, two DC motors, the robot will move upon detecting an object using the camera. I will decide what motor controller to use when one of you good fellows let me know what microcontroller would be adept for my wants.

Note: for speech recognition input, I will use an advanced sound sensor, and for the infrared and push button sensors I obviously know what I'm using, same with the camera.

I only mentioned these ones so you would know what I need the microcontroller to be capable of to use. But as for the data storage and saving photos and screen, I have no idea what I can use as I have never used anything similar in a robot before.

答:
I would consider using a Raspberry Pi. It certainly has the required memory, already has audio output and enough performance to perform image processing with. You can easily interface a simple 2x16 character LCD with it and the camera would not be a problem either. To control the motors you will need PWM, which is available on the PI, for example using this kernel modul from Adafruit.

One thing you will require is an external ADC so you can interface an analog infra red sensor and it is needed for the audio inout too. Or for the audio input you can use its I2S interface as well.

As for the microcontrollers.

For 20 MB of memory an SD card would be the easiest way here, which you already have at the PI. Regarding the audio, there are some with I2S interface but you would certainly need additional hardware to play audio or receive audio signals. An LCD, IR sensor and push button won't be a problem to any currently available MCU. Adventage is that the ADC is already built in.

All in all I would go with the PI.


问:
Is there a way to combine and sync two 2K cameras @ 90fps with ICs
I am searching for a way to minimize the size of a stereo vision module and cannot find any ICs that will combine and sync two MIPI CSI-2 (4 lane) data streams without an FPGA and too much code.  there was one online (MAX7366A 3D Video Combiner/Synchronizer with two MIPI CSI-2 Input and one MIPI CSI-2 output) but the product is not publicly available.   Does anyone have knowledge of an arrangement of ICs that I could try?.</p>

答:
Sony PS4 Camera is based on the same controller, for just $55.
It USB3.0 cable but firmware connector. Price difference motivates people to hack but that is not easy walking. </p>


问:
How can I implement tremaux algo in arduino line follower to navigate and create map?
The Map1

The task is divided into 2 runs, In first run, We have to navigate through whole map and reach the end mark taking all checkpoints.
In second run, using the mapping from first run we have to follow the shortest path.

I am reading Algos and codes from days, I know the steps that should be taken,
Navigate the maze using Tremaux algo and turning right at each possble junction.
then Save that map in memory and use djikstra algo or A* algo to find the shortest path.
But how to implement it practically?

Also since all  the dictances and angles are known and also the wheel dia, motor rpm, bot width then Can I skip wheel encoders and use calculation instead?

答: A good starting point is to solve the problem first in simulation. If the algorithm not work on a 2D map on screen it will never work on a real arduino. For inspiration github is a good ressource. There are many implementions available [1] [2]. After analyzing the sourcecode of somebody else it is time for writing the code from bottom up. In most programming languages the concept of "creating a library" is well suited for iterative development. The first methods in the library deals with pathplanning and obstacle avoidance and later additional features like "motor rotation per minute" will be added. The development cycle is testdriven, that means that after programming a small function, the code will be tried out in simulation and on a real robot. In most cases the development cycle is very slow, it is possible that even after one month of work no substantial progress is visible. Sometimes the code will result in a working robot, and sometimes not. It depends on the experience, the team and the invested workhours.</p>


问:
Seminal work in multi-robot task decomposition
Multi-Robot task decomposition implies that there is a mission that needs multiple mobile robots like guarding the president's car with a team of drones. This high-level layman interpretation of the mission has to be broken down into algorithmic language. Basically the missions have to be decomposed into atomic tasks which robots can be instructed to do in terms of their existing abilities and intelligence.

Here are some papers i found on this problem:-

[1]

[2]

Can someone point some seminal papers on it that tackle the algorithmic aspects of this problem? Pointing to open source codes in any language will also be preferred.

Note there is a closely related problem of multi-robot task allocation which i am not referring to.

答:
The most simple example for multi-robot task planning are boxpushing (two robot push a object through the room) and Real-time-strategy games (a robot army has to follow the tiberium truck). The algorithm for solving these problems are:

Solver (particle swarm optimization, Neuroevolution)

Hybrid Solver (PDDL Planner mit motion primitives)

procedural animation (hardcoded software with AutoIt)

According to my knowledge the two first concepts doesn't work on real robots because the cpu-usage is to high.


问:
Is it possible to make Kite flying robot?
This question was asked in electronics stackexchange. I want to know if is it possible to make a robot that can fly kites. Is this idea practical? I was thinking that making a kite is just like making some flying quadcopter or helicopter. I just want to know is this idea really implementable?  Is there an example or similar work in reference to this?     </p>

答:
Of course it's possible. Here's how I would try it out.

This would work best if the kite had some sort of sensor on it. GPS would work, but better would be some sort of local GPS function. This would allow the robot to know where the kite was easily. It would also be helpful to have a rate sensor to give a better overall picture of what is happening.

The robot would have to be able to pick up the kite somehow, and move a far enough distance away.

The robot would also need to know wind speed, to figure out where to go.

When the robot was an appropriate distance away, it could simply reel in the string, probably from an elevated position.

When the robot sensed that the kite was getting higher, it could stop pulling back.

It would not be a simple robot by any means, but it should be possible.


问:
Do I need the 5V to 3.3V level shifter?
I would like to follow the instructions here, to allow myself to control the Create2 with a Raspberry Pi 3.

However, this source, says that I need a level shifter to protect my Pi's circuitry from the Create's serial logic signal.

I'm fairly certain that I don't need the level shifter, since it looks like it's more just used to integrate the camera with the Create 2. But I am not in a rush to burn out either of these devices, so I'd like some verification.

答: I think we need 5-3.3 bidirectional voltage shifter (not for camera) to communicate between raspberry pi and create controller, since serial communication protocols for Create uses 0-5 voltage range and Raspberry Pi uses 0-3.3 volt range. This dissimilarity might result in signal distortion between the two devices. For instance, raspberry pi might send 2.5V as high signal but in create logic that might not recognize that as  high signal. As you stated,5V might be dangerous for raspberry pi circuit that runs on 3.3V. Also, for better communication, I suggest you should build the voltage shifter.

Title: Do I need the 5V to 3.3V level shifter?


答:
Just buy a level shifter, it's not worth a fried Pi.

For example, SparkFun Logic Level Converter - Bi-Directional.

Title: Do I need the 5V to 3.3V level shifter?

Body:
I would like to follow the instructions here, to allow myself to control the Create2 with a Raspberry Pi 3.

However, this source, says that I need a level shifter to protect my Pi's circuitry from the Create's serial logic signal.

I'm fairly certain that I don't need the level shifter, since it looks like it's more just used to integrate the camera with the Create 2. But I am not in a rush to burn out either of these devices, so I'd like some verification.

ContentLicense: CC BY-SA 4.0


问:
There seems to be so many robotic arms on the market, where can I get a list of pros/cons of each?
Doing some research on robotic arms and thinking about getting one, but I was wondering where can I get info on the pros/cons of each one and how they compare to each other. Another important factor is which one has the largest community following.</p>

答:
There's no such list because if a property is an advantage or disadvantage depends on the application to a large degree.

This holds true for a lot of things in engineering and life in general.

You said nothing about your application. From your statement:

thinking about getting one

it looks like you don't really have one either.

So what would you want to do with such a list anyway? Are you worried about making a mistake and buying the wrong arm? What if arm A has 20% more maximum force than arm B, but B has a 20% larger community? Would you want to come up with some weighted scoring system? How would you be able to decide which arm is right for you given that you have no experience with them and no clear requirements?

Just get started with any arm. This is the best way to gain experience with what matters and what does not.


问:
How to assemble brushless motors and propellers?
I'm building a quadcopter and I've received my motors and propellers.

What's the right way to assemble those together?

I'm not confident with what I've done, as I'm not sure the propeller would stay in place on a clockwise rotating motor.

I mean, if the motor rotates clockwise, will the screw stay tightly in place, even with the prop's inertia pushing counter-clockwise?

Here's what I've done (of course i'll tighten the screw...) :

答: This is correct. Just make sure to insert a lever into the hole at the top to really tighten the nut!</p>


问:
2DOF arm with quick movement: Stepper, servo, or DC motor?
To make a two degree of freedom arm capable of speeds needed to play air hockey, how should the arm be controlled? I'm wondering about speed vs accuracy.

The following image is from a project involving a 2DOF drawing arm:

For this air hockey project, the general mechanics of that arm seem appropriate. it can move the "hand" around a 2D plane. I also like how both motors are at the base of the arm, instead of having the 2nd motor at the elbow (which adds weight to the arm and slows it).

However, the drawing robot is slow.

Steppers:

I understand that in general, steppers are 'slow'.

But, steppers have accurate positioning, which is very important in a game of air hockey. I also know that the steppers can be geared-up, but then they lose torque. The steppers would need to handle the inertia of quick, back-and-forth arm movement.

Hobby servos:

I've used small servos for other projects, but the accuracy was poor. Most don't have a way to read the angle externally, and those that do, have noisy signals. I'm not sure how strong the hobby servos are, and if they can be accurate enough for this project. I understand that using digital servos improve dead band issues.

DC motors with external feedback:

The only other method I can think of for controlling the arm would be to use DC motors with sensors like as rotary encoders. I think I would need an absolute rotary encoder.  But they seem to be around \$50-$1000, which is a bit much for a solution I'm not sure will even work out. Perhaps there are cheaper solutions to motor angle measurement. I could just use a potentiometer, but then I'm worried about noise again.

It's worth noting that I don't know of any easy or affordable way to design my own drivetrain. All I have is a drill, and I don't know how I would mount shafts/bearings and such, even if the gears themselves were affordable.

This means that if I need to gear-up or down, I don't think I can unless it's cheap and involves simple tools.

So for the arm: DC motors with external feedback, servos, steppers, something else?...

Which method would be the best in terms of speed, and which for accuracy? I'm wondering which would cost less as well, but I understand that is a grey area.

I'm leaning towards servos out of simplicity. I'm may try digital servos with ball-bearings, in the hope they that will move quick enough, but be strong enough to handle the inertia of the arm.

(Note that a 2DOF arm is desired, and not something else like a 3D-printer x-y belt system.)

答:
Servo mechanisms are not the "popular" RC-Servos (not-only). Servo is a closed-loop control, not only for motors. Even Steppers could or not be servo-motors. RC-servos are in major cases a DC brushed motor, with reduction gear and a potentiometer for position feedback, and electronic control.

This is a common RC Servo. The fact that it has no ball bearings does not
directly to bad precision, there's plenty of high precision products that don't use ball bearings, they are better lubricated and more strong.

By Gophi (Own work) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 4.0-3.0-2.5-2.0-1.0 (http://creativecommons.org/licenses/by-sa/4.0-3.0-2.5-2.0-1.0)], via Wikimedia Commons

So you can use a DC brushed, brush-less, steeper motor, AC induction motor, and still add servo-mechanism (closed loop).

But what is common for staring designer on robotic arms, is a big interest in motor and actuators, and a low research on the mechanic itself. If the structure is much flexible, using high precision actuators would not help so much.

So you need to design the arm itself to be strong under the weight, forces, acceleration and deceleration (be it or not with ball bearing), and then with the dimensions, you can start selecting the actuators.

Rought speaking, the bigger the number of poles, the more torque the motor will have and less the speed (this is very variable). The question is, if the motor is directing driving the arm you would want high-torque and less speed. If you gearing, you can use a low pole, high-speed, medium to high torque motor, and have the gearbox match the speed and torque for your application.


问:
Why do people use camera instead of laser sensor for robot navigation?
I am working on Robot localization and navigation in urban environments. I want to use a camera. But I am a little bit confused about LRF (laser range finder) data or other laser data.

Why people want to use camera?

Why not LRF or other laser data?

Can anyone explain please in favor of Camera?

答:
A 3D laser range finder or LIDAR such as the one on the Google Car is far more expensive than a camera. The other reason is that while in case of a LIDAR the distance of every pixel is available, the generated data to be processed is enormous. You have to transfer and process data faster which comes out again as rising cost. Finally cameras usually have a longer lifetime, so there is less maintenance required.

With relatively cheap cameras and computer vision, pretty good results can be achieved.


答:
In addition to those points in Bence's answer, cameras can:

Calculate many complex features that result in very robust matching between frames, and object recognition

High angular resolution (typical low->high range goes from $0.5^\circ$ -> $0.025^\circ$)

Lower power usage

Passive sensor (doesn't require 'clean' signal of a laser)

Title: Why do people use camera instead of laser sensor for robot navigation?

Body:
I am working on Robot localization and navigation in urban environments. I want to use a camera. But I am a little bit confused about LRF (laser range finder) data or other laser data.

Why people want to use camera?

Why not LRF or other laser data?

Can anyone explain please in favor of Camera?


答:
navigation in urban environments

Depending on the laser, there might be legal constraints on where you can use it. Running around town throwing laser rays around might require special permission/licence.


答:
Are there any advantages to using a LIDAR for SLAM vs a standard RGB camera?

You may check this link where I have previously answered a somewhat similar question. (advantages and disadvantages of each)

in urban environments

If you are referring to autonomous cars like the Google ones, there are lots of considerations and constraints (safety, cost etc.).

If you are interested in research & learning, I suggest that you use any hardware platform that is available.

Keep in mind:

A car with a LIDAR that is extremely expensive won't be easily sold.

A car moving autonmously around people, might kill in case of a mistake. Thus the considerations are different than just developing algorithms for the sake of research and learning.


问:
Complimentary filter issues
I'm trying to implement the complimentary filter to get Euler angles using accelerometer and gyroscope data. Attached is the MATLAB code that I have along with a data set.

The data corresponds to moving the sensor from 0-90 degrees while attached to a goniometer. The sensor has an inbuilt algorithm that outputs Euler angles too and I'm trying to test the accuracy of this algorithm as it tends to overshoot the angle estimates.

The problem with the complimentary filter is that the angles move between (around) negative 40 and positive 40 degrees instead of changing between (around) 0-90 degrees.

Can anyone please point out what is wrong and why the complimentary filter isn't working well.

```<code>clc;
clear all;
close all;
M=importdata('Multiple_Sensors_747000.csv');
A=M.data;
[m n]=size(A);
a=1;
t=m/60;
angle=0;

for i=1:3723
    Acc(a,:)=M.data(i,6:8); % Reading Accelerometer data
    R_norm(a)=sqrt(Acc(a,1)^2+Acc(a,2)^2+Acc(a,3)^2); % Normalized accelerometer
    Racc_norm1(a,1)=acos(Acc(a,1)/R_norm(a));         % Angle from accelerometer in X
    Racc_norm1(a,2)=acos(Acc(a,2)/R_norm(a));         % Angle from accelerometer in Y
    Racc_norm1(a,3)=acos(Acc(a,3)/R_norm(a));         % Angle from accelerometer in Z

    Gyroscope(a,:)=M.data(i,3:5);                     % Reading gyroscope data
    gyro(a,:)=Gyroscope(a,:)*(1/t);                   % Integrating gyroscope data
    r(a,1)=sum(gyro(:,1));                            % Angle from gyroscope data
    r(a,2)=sum(gyro(:,2));
    r(a,3)=sum(gyro(:,3));
    angle=0.99*(angle+(gyro(a,:)))+(0.01*Racc_norm1(a,:)); % Complimentary filter equation
    ang(a,:)=angle;
    a=a+1;
end
</code>```

答:
There are quite a few things wrong here. I'll split them into two sections: technical errors, and coding warnings.

Technical Errors:

You are not calculating your angles from accelerometer readings correctly. Consider the arguments in general - they are the normalized accelerometer readings on each axis. You then take the inverse cosine of these. So, if the accelerometer is sitting flat on a table, a_z = -1 (or 1, depending on the polarity/handedness of your sensor), and a_x and a_y are zero. You then take the inverse cosine of those values, to find that the angle of rotation about the x and y axes are +90 degrees and the angle of rotation about the z axis is zero. This doesn't make sense. Consider instead using the equations found here:

$$
\theta_x = \arctan{\left(\frac{X}{\sqrt{Y^2 + Z^2}}\right)} \\
\theta_y = \arctan{\left(\frac{Y}{\sqrt{X^2 + Z^2}}\right)} \\
$$

Here you can see that, if the accelerometer is reading 0 on the x/y axes and +/-1 on the z-axis, that there is no rotation about the x or y axes. This makes sense.

You are not using the gyroscope angles. The gyroscope outputs an angular velocity, not an angular position. In order to get the angular position, you need to numerically integrate the gyroscope readings. You seem to have this in your code: r = sum(Gyroscope)*(1/T);, but then you fail to use those angles in the complimentary filter. Instead you go back to the raw gyro outputs.

Your complimentary filter isn't a complimentary filter. A complimentary filter is like a lag filter. Each have the form: y = (k)*a + (1-k)*b;. In the complimentary filter, a and b are two different signals, and k is like a "blend" factor, where you take k% of one signal and add it to 1-k% of the other signal. You end up with 100% of signal strength if you do this. In a lag filter, a is the current sample and b is the previous output of the lag filter. The k and 1-k argument still stands, though, and you still wind up with 100% of signal strength. I'll split what you're doing into parts to try to make it more clear what you're doing:

You have:

```<code>angle=0.99*(angle+(gyro(a,:)))+(0.01*Racc_norm1(a,:));
ang(a,:)=angle;
</code>```

Splitting this up a little, you could rephrase it by pulling the angle term out of its own definition and calling a different variable - prevAngle. Factor the 0.99 that it's multiplied by as well and you get:

```<code>prevAngle = angle;
angle = 0.99*(gyro(a,:))+(0.01*Racc_norm1(a,:));
ang(a,:) = 0.99*prevAngle + angle;
</code>```

So here it's like you've got a complimentary filter in the form of:

```<code>k = 0.99;
angle = k*gyro(a,:) + (1-k)*Racc_norm1(a,:);
</code>```

but, your lag filter is broken, because after that line you have:

```<code>k2 = 0.99;
ang(a,:) = k2*prevAngle + (k2+(1-k2))*angle;
</code>```

which is the same another way of saying what you have, which is:

```<code>ang(a,:) = k2*prevAngle + (1)*angle;
</code>```

Hopefully here you can see that, while your complimentary filter is setup okay and you retain 100% signal strength, your lag filter is broken and each sample increases in magnitude by 1.99. You should be doing k2*prevAngle + (1-k2)*angle, but instead of adding (1-k2)*angle, where (1-k2) is 0.01, you're instead adding 1*angle.

So, in summary, you are getting gibberish from the accelerometers, and combining that with gyroscope velocities with a broken filter.

Coding Warnings:

I'm really not trying to poke you in the eye/salt in the wound at this point, I'm just pointing out some flaws and hopefully giving some guidance that should speed up the work I'd imagine you'll be doing in the future. (Combination of IMU filtering and Matlab all sounds like a senior/grad project).

Don't use magic numbers. Your for loop runs to 3273. What is that? Why that specific number? You seem to have a grasp of the size() function. I'll point out that you can call size() two different ways - as you have, which is [m,n] = size(data), or another way - m = size(data,1) and n = size(data,2). You never use n, so I'm assuming all you care about is the number of rows. I generally get the number of samples/rows with a one-line call like: nSamples = size(data,1);. Then I can use nSamples instead of magic numbers in all other places and I don't need to go back and edit the code for different data sets. Manually re-coding for every data set is hazardous to your sanity and can give you lots of grief when you forget to change all of the magic numbers and then switch data sets.

Don't manually increment anything. You declare a=1; and then use the a=a+1; at the end of your for loop, using a everywhere you could otherwise use i, your loop variable.

Use descriptive names. I generally avoid i and similar, even for loop variables. First, i without declaration is 1i, the imaginary number in Matlab. Second, it gets a little tedious/confusing in nested loops to go i/j or i/ii or whatever. As with note 1, I declare my samples to be nSamples, and my for loops are generally for currentSample = 1:nSamples. This can blow up column widths, but the code is so much easier to read and the loop variables are so much easier to manage that I figure it's worth it. One loop can loop through your currentSample and your other loop can then run through currentColumn or whatever.

Vectorize. Vectorizing will always speed up your code. Matlab is terrible, terrible at doing any kind of looping. They have algorithms that run vector operations faster than if you looped over it. In C languages there shouldn't be much of a difference, but Matlab isn't C and it doesn't run in real time. I clocked your code at about 140ms to execute when I made a fake data set of size randn(3723,8) and used that for your code. When I used vector operations I got that down to 8ms, and that includes the loop required to do the lag filter. If you did just the complimentary filter, then you can take that loop out and the time drops to 0.8ms. This means that, even though I'm still running a loop, my vectorized version is 16x faster than your unvectorized version. Without the loop it's 160 times faster. I wanted to harp on vectorizing a little because I had simulations as a grad student that ran 24 hours per day for up to 9 days. Every millisecond matters when you're on that time scale. You might not ever do anything that intense, but you'll almost certainly work on larger datasets at some point. This looks like a minute of data.

Not only is it faster, but it's also easier to look at. Consider the following, from your code:

```<code>for i=1:3723
    Acc(a,:)=M.data(i,6:8); % Reading Accelerometer data
    R_norm(a)=sqrt(Acc(a,1)^2+Acc(a,2)^2+Acc(a,3)^2); % Normalized accelerometer
    Racc_norm1(a,1)=acos(Acc(a,1)/R_norm(a));         % Angle from accelerometer in X
    Racc_norm1(a,2)=acos(Acc(a,2)/R_norm(a));         % Angle from accelerometer in Y
    Racc_norm1(a,3)=acos(Acc(a,3)/R_norm(a));         % Angle from accelerometer in Z

    Gyroscope(a,:)=M.data(i,3:5);                     % Reading gyroscope data
    gyro(a,:)=Gyroscope(a,:)*(1/t);                   % Integrating gyroscope data
    r(a,1)=sum(gyro(:,1));                            % Angle from gyroscope data
    r(a,2)=sum(gyro(:,2));
    r(a,3)=sum(gyro(:,3));
    a=a+1;
end
</code>```

and compare that with the vectorized form:

```<code>Acc = M.data(:,6:8);
R_norm = (Acc(:,1).^2 + Acc(:,2).^2 + Acc(:,3).^2).^(0.5);
Racc_norm1 = acos(Acc(:,1)./repmat(R_norm,1,3));

Gyroscope = M.data(:,3:5);
gyro = Gyroscope.*(1/t);
r = cumsum(gyro);
</code>```

A couple of things were used there - the colon operator to select 'all' rows (Acc = M.data(:,6:8)), the use of the element-wise operator, which is just a period before the regular operators (.^ .* ./), the use of repmat to get R_norm to be the same size as Acc. repmat is easy to use - the data set you want to copy, how many copies you want in the row dimension, and how many copies you want in the column dimension. Lastly, there's the cumulative sum cumsum to compound sequential sums.

So, in closing, this is probably way more than you were looking for, but former grad student to (probably) grad student, these are tips and tricks I learned along the way with Matlab.

Practice vectorizing code in everything you do. When you're working on small stuff it's easy to see if you've done something wrong. By the time you get to big projects, thinking in vectorized form will be second nature. If you wait for the big project to start trying to vectorize, you're in for a world of pain and sorrow trying to learn on-the-fly or (worse) trying to refactor a project.

Best of luck!

tl;dr - Come for the technical review, stay for the nifty tips!

Title: Complimentary filter issues

Body:
There are quite a few things wrong here. I'll split them into two sections: technical errors, and coding warnings.

Technical Errors:

You are not calculating your angles from accelerometer readings correctly. Consider the arguments in general - they are the normalized accelerometer readings on each axis. You then take the inverse cosine of these. So, if the accelerometer is sitting flat on a table, a_z = -1 (or 1, depending on the polarity/handedness of your sensor), and a_x and a_y are zero. You then take the inverse cosine of those values, to find that the angle of rotation about the x and y axes are +90 degrees and the angle of rotation about the z axis is zero. This doesn't make sense. Consider instead using the equations found here:

$$
\theta_x = \arctan{\left(\frac{X}{\sqrt{Y^2 + Z^2}}\right)} \\
\theta_y = \arctan{\left(\frac{Y}{\sqrt{X^2 + Z^2}}\right)} \\
$$

Here you can see that, if the accelerometer is reading 0 on the x/y axes and +/-1 on the z-axis, that there is no rotation about the x or y axes. This makes sense.

You are not using the gyroscope angles. The gyroscope outputs an angular velocity, not an angular position. In order to get the angular position, you need to numerically integrate the gyroscope readings. You seem to have this in your code: r = sum(Gyroscope)*(1/T);, but then you fail to use those angles in the complimentary filter. Instead you go back to the raw gyro outputs.

Your complimentary filter isn't a complimentary filter. A complimentary filter is like a lag filter. Each have the form: y = (k)*a + (1-k)*b;. In the complimentary filter, a and b are two different signals, and k is like a "blend" factor, where you take k% of one signal and add it to 1-k% of the other signal. You end up with 100% of signal strength if you do this. In a lag filter, a is the current sample and b is the previous output of the lag filter. The k and 1-k argument still stands, though, and you still wind up with 100% of signal strength. I'll split what you're doing into parts to try to make it more clear what you're doing:

You have:

angle=0.99*(angle+(gyro(a,:)))+(0.01*Racc_norm1(a,:));
ang(a,:)=angle;

Splitting this up a little, you could rephrase it by pulling the angle term out of its own definition and calling a different variable - prevAngle. Factor the 0.99 that it's multiplied by as well and you get:

prevAngle = angle;
angle = 0.99*(gyro(a,:))+(0.01*Racc_norm1(a,:));
ang(a,:) = 0.99*prevAngle + angle;

So here it's like you've got a complimentary filter in the form of:

k = 0.99;
angle = k*gyro(a,:) + (1-k)*Racc_norm1(a,:);

but, your lag filter is broken, because after that line you have:

k2 = 0.99;
ang(a,:) = k2*prevAngle + (k2+(1-k2))*angle;

which is the same another way of saying what you have, which is:

ang(a,:) = k2*prevAngle + (1)*angle;

Hopefully here you can see that, while your complimentary filter is setup okay and you retain 100% signal strength, your lag filter is broken and each sample increases in magnitude by 1.99. You should be doing k2*prevAngle + (1-k2)*angle, but instead of adding (1-k2)*angle, where (1-k2) is 0.01, you're instead adding 1*angle.

So, in summary, you are getting gibberish from the accelerometers, and combining that with gyroscope velocities with a broken filter.

Coding Warnings:

I'm really not trying to poke you in the eye/salt in the wound at this point, I'm just pointing out some flaws and hopefully giving some guidance that should speed up the work I'd imagine you'll be doing in the future. (Combination of IMU filtering and Matlab all sounds like a senior/grad project).

Don't use magic numbers. Your for loop runs to 3273. What is that? Why that specific number? You seem to have a grasp of the size() function. I'll point out that you can call size() two different ways - as you have, which is [m,n] = size(data), or another way - m = size(data,1) and n = size(data,2). You never use n, so I'm assuming all you care about is the number of rows. I generally get the number of samples/rows with a one-line call like: nSamples = size(data,1);. Then I can use nSamples instead of magic numbers in all other places and I don't need to go back and edit the code for different data sets. Manually re-coding for every data set is hazardous to your sanity and can give you lots of grief when you forget to change all of the magic numbers and then switch data sets.

Don't manually increment anything. You declare a=1; and then use the a=a+1; at the end of your for loop, using a everywhere you could otherwise use i, your loop variable.

Use descriptive names. I generally avoid i and similar, even for loop variables. First, i without declaration is 1i, the imaginary number in Matlab. Second, it gets a little tedious/confusing in nested loops to go i/j or i/ii or whatever. As with note 1, I declare my samples to be nSamples, and my for loops are generally for currentSample = 1:nSamples. This can blow up column widths, but the code is so much easier to read and the loop variables are so much easier to manage that I figure it's worth it. One loop can loop through your currentSample and your other loop can then run through currentColumn or whatever.

Vectorize. Vectorizing will always speed up your code. Matlab is terrible, terrible at doing any kind of looping. They have algorithms that run vector operations faster than if you looped over it. In C languages there shouldn't be much of a difference, but Matlab isn't C and it doesn't run in real time. I clocked your code at about 140ms to execute when I made a fake data set of size randn(3723,8) and used that for your code. When I used vector operations I got that down to 8ms, and that includes the loop required to do the lag filter. If you did just the complimentary filter, then you can take that loop out and the time drops to 0.8ms. This means that, even though I'm still running a loop, my vectorized version is 16x faster than your unvectorized version. Without the loop it's 160 times faster. I wanted to harp on vectorizing a little because I had simulations as a grad student that ran 24 hours per day for up to 9 days. Every millisecond matters when you're on that time scale. You might not ever do anything that intense, but you'll almost certainly work on larger datasets at some point. This looks like a minute of data.

Not only is it faster, but it's also easier to look at. Consider the following, from your code:

for i=1:3723
    Acc(a,:)=M.data(i,6:8); % Reading Accelerometer data
    R_norm(a)=sqrt(Acc(a,1)^2+Acc(a,2)^2+Acc(a,3)^2); % Normalized accelerometer
    Racc_norm1(a,1)=acos(Acc(a,1)/R_norm(a));         % Angle from accelerometer in X
    Racc_norm1(a,2)=acos(Acc(a,2)/R_norm(a));         % Angle from accelerometer in Y
    Racc_norm1(a,3)=acos(Acc(a,3)/R_norm(a));         % Angle from accelerometer in Z

    Gyroscope(a,:)=M.data(i,3:5);                     % Reading gyroscope data
    gyro(a,:)=Gyroscope(a,:)*(1/t);                   % Integrating gyroscope data
    r(a,1)=sum(gyro(:,1));                            % Angle from gyroscope data
    r(a,2)=sum(gyro(:,2));
    r(a,3)=sum(gyro(:,3));
    a=a+1;
end

and compare that with the vectorized form:

Acc = M.data(:,6:8);
R_norm = (Acc(:,1).^2 + Acc(:,2).^2 + Acc(:,3).^2).^(0.5);
Racc_norm1 = acos(Acc(:,1)./repmat(R_norm,1,3));

Gyroscope = M.data(:,3:5);
gyro = Gyroscope.*(1/t);
r = cumsum(gyro);

A couple of things were used there - the colon operator to select 'all' rows (Acc = M.data(:,6:8)), the use of the element-wise operator, which is just a period before the regular operators (.^ .* ./), the use of repmat to get R_norm to be the same size as Acc. repmat is easy to use - the data set you want to copy, how many copies you want in the row dimension, and how many copies you want in the column dimension. Lastly, there's the cumulative sum cumsum to compound sequential sums.

So, in closing, this is probably way more than you were looking for, but former grad student to (probably) grad student, these are tips and tricks I learned along the way with Matlab.

Practice vectorizing code in everything you do. When you're working on small stuff it's easy to see if you've done something wrong. By the time you get to big projects, thinking in vectorized form will be second nature. If you wait for the big project to start trying to vectorize, you're in for a world of pain and sorrow trying to learn on-the-fly or (worse) trying to refactor a project.

Best of luck!

tl;dr - Come for the technical review, stay for the nifty tips!


答:
I don't think people really "want" to use only cameras. If every researcher could afford the LiDARs they'd all put LiDARs on they robots for outdoor environment.

Cameras are pretty cheap and the only limit to range is the pixel/superpixel resolution that you can process in your algorithm/software.

Most researchers (including me) use structured light cameras (although they don't work outdoors, so we switch to RGB cameras on these sensors when the robot is outdoors). A solution to this light problem is that we also use stereo cameras (stereo vision/multi-view depth which is computationally expensive) for roughly determining depth, based on the processing capabilities of the controller/CPU. Another solution that I've yet to personally explore is to use multiple Kinects/Asus Xtions etc, where you get depth corroboration as well as multiple RGB cameras for outdoors.

LiDARs are typically very expensive (in the thousands of $$ for really good ones). Although this might change in the future with some companies coming out with $250 "LiDARs" like Sweep.

Also, LRF's/LiDARs have limited range and resolution (i.e., beyond a certain distance, they cannot resolve depth unambiguously and hence they return 0 values (I'm not sure specifically about LiDARs, but depth cameras have a maximum (above which) as well as minimum range (below which) they dont give you depth).

Hope this helps.


问:
Self learning maze solving robot using 8bit microcontroller?
I want to know if there is best algorithm and technique to implement self learning maze solving robot in 8 bit limited resource micro-controller? I was looking for some well optimized algorithm and/or technique. Maze can be of any type. Of-course first time it has to walk all the way and keep tracking obstacles it found.

I think best technique would be neural networks but is it possible to do this in such a short resources of 8bit? Any example online with similar kind of problem?

My wall detection is based on units, well, I have counted the wheel turns and it is almost 95% accurate in integers. For sensing the walls Ultrasonic range finding is used. Wheel can remeber its current position in let say, 3 feet staight, 2 feet right, etc.

答: You might want to have a look at my maze solving robot solution (http://www.benaxelrod.com/robots/maze/index.html).  I used a Lego RCX which is more powerful than an 8bit microcontroller, but is still pretty resource constrained.  I abstracted away most of the hardware problems to focus on the algorithm.  It uses a flood-fill or A* type algorithm.</p>


问:
Do multiple LIDAR systems in same area interfere?
LIDARs use a pulse of light to measure distance, usually from the time of flight to reflection and back. With a collection of these measurements they can determine their surroundings in two or three dimensions. LIDARs are used as one of the sensor systems for self-driving cars, in addition to cameras and other radar systems.

Robotic cars are still in the testing phase, but at some point in the future we can expect a busy intersection filled with them, trying to navigate their way through it. With multiple scanners per car, and possibly multiple beams per scanner, interfering signal sources could go over a hundred even in smaller stages.

When time of flight is used to measure the distance to the reflection, the interfering signals would produce multiple "distances", and it would most likely require multiple scans of the same point to average some kind of a reliable value from all the noise.

How do LIDAR systems differentiate their own signals from other sources? With the example of robotic cars, could this interference lead to an error state where traffic could gridlock from lack of valid data? Or is this even a problem?

答:
One could use lasers with slightly different wave length - just as different channels for Wi-Fi signal. Also there could be used some kind of wave modulation... but I don't think LIDARs use such solutions, since laser point is so small, that case of interference with other sensor is... kinda, rare event.

I experienced interference of distance sensors, but with ultrasonic measurement, when 3 robots with multiple (12) sensors were working in distance of ~3 meters between each other. Never had this problem with LIDARs, though.

Is this even a problem in robotic cars? It should'nt be. Error correction and having high quality enviroment maps are the main reasons of putting multiple LIDARs and camera systems on intelligent cars. Distance measurement fail of one sensor, or interference with other car's LIDAR system (which is, as written before, a rare event) should not cause system to collapse.

As You wrote, robotic cars are still in testing phase, so any interference between multiple sensors working on giant intersection, are yet to be (or hopefully not) problems and sensor engineers will have to face them.


答:
Like other already answered. Cameras typically are much cheaper than Laser  Range Finders.

When you talk about camera you mean the 2D cameras isn't it? There are some 3D cameras like the ifm O3D3xx family of cameras available. Those camera may not have the accuracy of a laser scanner but they provide 3D depth data in reasonable frame rates at a price point of ~1k


问:
Switching from wall power to battery and back again
I'm in the final phase of my BeerBot* project, and I'm looking for the best way to power it.

BeerBot will spend most of his life sitting in a docking station, keeping his battery charged and running off of wall power.  When called upon, he needs to be able to disconnect from the docking station and switch to battery power without interrupting power to his brain.  Upon returning to his docking station, he needs to switch back to wall power again.

I have a NiMH charge circuit, and I have a circuit for powering the robot from a wall outlet, I'm just not sure how to switch from one to the other without interrupting power.  For my testing thus far, I've just been shutting the robot down and manually switching between wall power and battery power, and connecting the battery to an external charger as needed.  This is obviously not a permanent solution, since BeerBot needs to be always at the ready - shutting him down to switch over to battery power every time I need a beer would defeat the whole purpose of BeerBot*.

So my question is, what is the best way to keep a robot powered from the wall, simultaneously charging the battery, and switching between wall power and battery power automatically when disconnected?  I guess this is analogous to the way a laptop works - switching to battery when unplugged and and keeping the battery charged while plugged in.

I don't care if it's a ready-made solution or a circuit I can build, I'm just looking for a good way to do this without frying my robot or setting my house on fire.  I'm mostly a software guy, so I know just enough about circuit design to be dangerous (and I've fried enough electronics to know that power supplies can be dangerous...).  I've been looking at power management ICs, but I'm thinking that might be overkill since I already have a charging circuit and a wall-power circuit, I just need a way to switch between them.  Can I just connect both and use a couple of diodes to keep current from flowing in directions it shouldn't, like this?

or do I need something more complex?

.

*If you're curious, BeerBot is a semi-autonomous beer-seeking robot.  He sits quietly in the corner listening for commands.  Currently his only command comes from a modified Easy Button on my desk, which sends a wireless signal to BeerBot.  When he hears the signal, he wakes up, drives autonomously to the refrigerator, opens the door with his robotic arm, uses computer vision to detect a beer bottle (placed strategically on the bottom shelf where he can reach), grabs a cold one, closes the refrigerator door, brings the beer to my desk, and returns to his corner to await my next request.  Phase 2 will incorporate a bottle opener.

答:
Basically the simple Diode-OR circuit, you just have shown would be enoguh, if you (or your circuits) can get along with the voltage drop on the diodes. It is about 0.3 V - 0.5 V depending on the diodes you choose. But there is one thing you have to make sure, so the switching between the power supplies will happen correctly.

The voltage from the wall supply should be larger than the voltage from the battery, ensuring that when the wall adapter is connected D1 will conduct and D2 won't.

Wall adapter is disconnected: $$ V_{out} = V_{battery} $$

When the robot connects to the adapter, where: $$ V_{wall} > V_{battery}(=V_{out}) $$
then D1 will conduct as the voltage on its anode (+) will be higher than on its cathode (-).

Now the output will be: $$ V_{out} = V_{wall} $$
so the voltage on the cathode (-) of D2 will be higher than on its anode (+), disconencting the battery.

This won't work if the two voltage sources are equal, slightly equal.

There are also available autoswitching power multiplexer ICs on the market, such as this one.

Note that, this is just an example and it does not support 12 V input. You can find one with the correct voltage and current ratings though.


答:
The Roombots example you posted does not use a level shifter because they are using the Create USB cable to talk to the robot. If you are planning to use this cable, you do not need the level shifter. If you are not planning to use this cable and instead will be interfacing directly to the Raspberry Pi serial pins (on the GPIO header), then the answer below applies:

Yes, you should use a level shifter between the iRobot Create and the Raspberry Pi, and you must use one on the input to the Raspberry Pi. The Create uses 5V logic levels, while the Raspberry Pi uses 3.3V logic levels. The Raspberry Pi output high (3.3V) is high enough for the Create to "see" it as a "high" input, so you don't necessarily need a logic level shifter for the Create inputs. However, a Create output high (5.0V) is higher than the processor on the Raspberry Pi can handle for long, and sustained use will cause the serial port on the Raspberry Pi to fail. The circuit in the drawing is indeed bidirectional, but only one of those directions (Create TX to Pi RX) is being used; you could just as easily replace the FET with a Schottky diode from source to drain and eliminate R2.

Please note that while I'm an iRobot employee, the postings on this site are my own and don't necessarily represent iRobot's positions, strategies, or opinions.

Title: Do I need the 5V to 3.3V level shifter?


问:
Estimating state of moving object from other moving object
What is the best way to estimate the state

```<code>[x-position;
y-position;
heading (yaw angle);
velocity;
acceleration;
curvature (or yaw rate)]
</code>```

of a moving leading vehicle with sensors mounted on a follower/ego vehicle?

The following measurements of the leading vehicle are obtained via radar sensors mounted on the ego vehicle.

x-y-position in the ego coordinate frame

heading in ego coordinates

relative and absolute velocity and acceleration

No information about curvature (yaw rate). This should be estimated which is possible using the lateral acceleration and longitudinal velocity.

For estimation I think of using EKF or nonlinear moving horizon estimation.

Considering that no prediction about the moving leader vehicle can be made because the control inputs are unknown. Only the measurments (update step) and the movements of the ego vehicle are available (incroporate in prediction).

What kind of model would be appropriate for the whole scenario?

just a model for the leading vehicle? (e.g. bicycle model)

just a model for the following ego vehicle?

or a combination of both vehicles?

Option 1 would be perfect in combination with a simple bicycle model if there was an outside observer who is not moving. Option 2 is not really an option because the configuration of the leader vehicle should be estimated. Option 3 seems to me the right way because of the following thoughts:

Looking from the ego coordinates: is it correct correct that a motion change of the ego vehicle will seem as if the measured locations of the leading vehicle changed? If so will I need a coordinate transformation or is it better to use a model in global coordinates, then transform the measurements (which are in ego coordinates)?. The approach using global coordinates seems counter intuitive because the final estimate should be used for the follower/ego vehicle as reference trajectory.

Can you give me a hint which coordinate frame (global or ego) to use, which model to use in the prediction step and if my thoughts on motion changes are correct?

Or do you know any sources that address this or a similar issue?

For the process model I thought of

```<code>x_k+1 = x_k + v_k * cos(heading_k)
y_k+1 = y_k + v_k * sin(heading_k)
heading_k+1 = heading_k
v_k+1 = v_k
a_k+1 = a_k
curvature_k+1 = curvature_k + a_y_k/v_x_k
</code>```

of course there should be some process noise added, especially for heading, velocity acceleration and curvature because these measurements are rather inaccurate.
For heading, velocity and acceleration I would use the previous estimates (or measurements) since no other source except the measurements from the sensors are available.
Curvature is computed using the acceleration in (global?) y-direciton and the (global?) velocity in x-direction curvature = a_y/v_x

The measurement model looks probably something like this:

```<code>y = [1 1 1 1 1 0;
     0 1 0 0 0 0;
     0 0 1 0 0 0;
     0 0 0 1 0 0;
     0 0 0 0 1 0;
     0 0 0 0 0 0]*x
</code>```

where x is the state vector [x-position; y-position; heading (yaw angle); velocity; acceleration; curvature or (yaw rate)]

The trajectory must be smooth and should be exactly like the driven path of the leader vehicle. So I think some sort of estimation will be necesseray in order to avoid following the measurements in straight lines, which would lead to an unsteady trajectory.

The mesurements of the heading, velocity and acceleration have a rather high variance depending on the situation.

答:
My current approach is the following:

transform the the noisy leader vehicle state from ego coordinates to global coordinates using the current pose of the ego vehicle $(x_{ego},y_{ego},\theta_{ego})$.

estimate an improved (less noisy) trajectory of the leader in global coordinates.

backtransform the optimized state estimates from global to ego coordinates using the corresponding ego vehicle pose.

It is possible to stay in the ego frame but this seems to need more effort, since it would be harder to tell if the leader or the ego vehicle moved. However, I was told the common approach is the solution in global coordinates.


答:
I am going to add another reason that frankly I was hoping someone else would bring up. Because why do we make robots in the first place? Emotionless machines to do our dirty work?

I think that the fact that a robot can rely purely on "vision" like we mammals do makes them more like us. So for me, lasers and sonars are cheating. What IMHO we should focus on in stead of cheating is making better cameras with higher frame-rate, higher dynamic range and less artifacts, and write software that can get the needed data from them. (Or, speaking in post 2012 terms, train our networks to get what data they need from them).


问:
Implementing pure pursuit problem in robot navigation?
I would like to implement pure pursuit waypoints navigation. we know that,

look ahead distance=look ahead gain*vehicle forward velocity

How can I calculate look ahead velocity gain/look ahead gain?

How can I calculate velocity profile for each waypoints?

答:
My understanding of the pure pursuit algorithm is that the look ahead distance is a fixed parameter.  In this original paper [1], there is a short discussion on choosing the look ahead distance.

I believe you should tune this to the typical speeds of your robot and the types of paths you will be following (i.e. very curvy or straight).

[1] Implementation of the Pure Pursuit Path Tracking Algorithm. R. Craig Coulter, CMU, 1992.


问:
Is it possible to detect road surface or navigation area using LRF data or other laser data in a Park?
I would like to detect road surface in a park. In the park, only small grass are covered with the both side of the road. That means there is road and the both side of the road are covered by small grass.
Is it possible to detect road surface (not grass) using LRF data or other laser sensors?
If not, why?
if yes, which is better-Camera or laser sensor?</p>

答:
Is it possible to detect road surface (not grass) using LRF data or other laser sensors?

Yes it is possible. A laser scanner will give distance measurements along a scan line. Presumably, the road surface is sufficiently smooth that it will be distinguishable from natural terrain. A quick way (certainly not the best way) to get this working for a prototype would be to use a Hough transform to identify lines in the laser scan, the idea being that a scan of the road will be a reasonably clean line and natural terrain will not. This of course requires the laser scanner to be downward facing (perhaps mounted on a mast), which seems like a waste.

Which is better-Camera or laser [range finder]?
Because you don't seem to care about exact distances between the robot and the grass, I would suggest using a camera, which will be significantly cheaper. As for which is better, that depends on what you are actually doing.


问:
Accelerometer deterministic errors
I am working on MEMS accelerometers, and I want to understand the difference between,

Cross axis sensitivity

Axis Misalignment

Non Orthogonality

In literature, people use it interchangeably.

These physical parameters cause deterministic errors, which I want to correct during calibration

答:
Cross-axis sensitivity: A reading on one axis creates a false reading on another axis. This could be because the signal traces are close together and capacitive coupling induces a voltage on the adjacent trace.

Axis misalignment: The x-axis of the sensor is not aligned with the x-axis of the package, so when you are expecting an x-axis reading because you moved the package along its x-axis, you instead get readings of not-quite-full scale on x and a smaller reading on the y- and/or z-axes.

Non-orthogonality: The sensor is deformed and the portion of the sensor that is supposed to detect acceleration on the y-axis is instead "bent" and "leans" toward the x- and/or z-axes. Same goes for the other axes.

So, let's use the example of sliding the accelerometer purely along the x-axis. You take measurements and find that you're getting a non-zero, positive reading on the y-axis in addition to a "roughly correct" reading on the x-axis. What is the cause?

Cross-axis sensitivity - could be the y-axis signal line is coupled to the x-axis signal line and the x-axis reading induces a voltage that is read by the y-axis ADC and returned.

Axis misalignment - The z-axis is reading zero (in this example), so it is pointing in the correct direction, but the sensor could be rotated about the z-axis relative to the package (an angle $\theta$), such that the y-axis points a little in the direction of the +x-axis. When the package is slid along the package's x-axis, the sensor's x-axis reads $\ddot{x}_{\mbox{package}}\cos{\theta}$ and the sensor's y-axis reads $\ddot{x}_{\mbox{package}}\sin{\theta}$.

Non-orthogonality - The sensor's x-axis is actually pointing correctly in the package's x-axis and the sensor's z-axis is correctly pointing in the package's z-axis, but the sensor's y-axis is "bent" and it's not perpendicular to the x- and z-axes. Now the x-axis is reading the correct value, but the y-axis is incorrectly reading some value because it's bent towards the x-axis.

Why do people use them interchangeably? Because you can't see behind the scenes and see what's causing the y-axis to incorrectly report readings. It could be any one of the three, or all three, or any other permutation.

:EDIT:

OP asked about mathematical modelling of the errors, and while I don't have any resources on these exactly, I can offer a couple things to think about that you could consider as "guidelines" for designing the tests to differentiate these errors:

Cross-axis sensitivity. Here the assumption is that there's some coupling between sensor axes internally. With the (almost certainly capacitive) coupling, there's an associated time constant. That is, if you could get the sensor to maintain a constant acceleration on one axis, if there is cross-axis sensitivity, the reading on the other axis should be time-dependent and should display a familiar shark fin shape. Keep in mind that a object on a circular path always needs a constant acceleration towards the axis of rotation (centripetal force), so a turntable would be an easy way to set this up.

Axis misalignment. If the reading on the un-actuated axis does not change with time (and know that the capacitance between those sensor lines could be very, very small - very fast time constant!), then check that the readings affect both axes equally. That is, when accelerating on the x-axis, you might get $\ddot{x}_{\mbox{package}}\cos{\theta}$ on the sensor's x-axis and $\ddot{x}_{\mbox{package}}\sin{\theta}$ on the sensor's y-axis. You have no way of knowing what $\theta$ is because it's supposed to be zero. BUT, when you re-orient the sensor and accelerate along the y-axis, you should now expect the sensor to read $\ddot{y}_{\mbox{package}}\cos{\theta}$ on the sensor's y-axis and $\ddot{y}_{\mbox{package}}\sin{\theta}$ on the sensor's x-axis. If the y-axis reading when testing the x-axis the same as the x-axis reading when testing the y-axis, then both axes are skewed and the sensor is rotated with respect to the package. Going back to the example where we're testing on the x-axis, the y-axis value should be smaller, and if you divide the y-axis reading by the x-axis reading, you get: $(\ddot{y}/\ddot{y})(\sin{\theta}/\cos{\theta})$, which is equal to $\tan{\theta}$. Now take the inverse tangent of the y/x reading and you'll get the rotation angle.

Non-orthogonality. This error is where one or more axes are bent such that they're not perpendicular. In this case, let's assume the sensor x- and z-axes are correctly aligned with respect to the package, but the y-axis is bent. In this case, in the same test as #2 above, you should find that when you accelerate the package along its x-axis, the y-axis is bent so it has a reading, but when you accelerate the package along its y-axis, the x-axis does not have a reading. This is because the sensor's x-axis is orthogonal to the package's y-axis, so there's nothing to sense. The sensor's y-axis is not orthogonal to the package's x-axis, though, which is why you do get a reading when moving along that axis.

To summarize:

If the false reading is time-dependent, it's a coupling issue. The rise and fall times give you the time constant, which in turn should allow you to model the coupling. Note that these rise/fall times might be very fast.

If a y-axis acceleration causes a reading on the x-axis that's symmetric to the y-axis reading caused during an x-axis acceleration, the sensor is rotated with respect to the package. Take the arctangent of the readings to get the rotation angle.

If the readings aren't symmetric, one (or more) axes are bent. Here you'd use the arcsine (or arccosine, depending on your definition) to get the bend angle, because the unaffected axis should read the full value.

You'll find this to be more complex in reality, because you could have all three problems on all three axes. A time-dependent coupling that doesn't start at zero indicates problem #1 with (#2 and/or #3). A related but not perfectly symmetric set of readings when swapping axes indicates problems #2 and #3 together. This should give you enough to get started designing your own tests.

Title: Accelerometer deterministic errors


问:
I want to know whether the Create2 can interface a LIDAR?
I want to know if the Create 2 can interface a laser radar?
For example an RPLidar.</p>

答: If you are willing to work at it, adding LIDAR to the Create 2 should be possible. If you read the iRobot Create 2 OI Specs, you will see that you can communicate with the Create via serial communication. If you look at the datasheet for the RPLidar, you will see that you can communicate with the sensor using serial communication. Because you cannot program the Create directly, you will need to use a microcontroller to interface the LIDAR and the robot.</p>


问:
How do I measure the distance that a cord (string) has moved?
For a pet project, I am trying to fly a kite using my computer.  I need to measure how far a cord extends from a device.  I also need to somehow read out the results on my computer. So I need to connect this to my pc, preferably using something standard like USB.

Since the budget is very small, it would be best if I could get it out of old home appliances or build it myself.

What technology do I need to make this measurement?

答: Maybe you could take one from an old computer mouse, and count the light pulses directly from the mouse board so you could tell the length of the cord.</p>


问:
Is there any error analysis of Irobot Create 2?
I am curious about the travelling distance/turning angle accuracy of Irobot Create 2. E.g., if the program let Create 2 go forward for 10 m, will Create 2 go forward exactly 10 m?

What is the possible error for Create 2 for both travelling distance and turning angle? I did not find related information in the Irobot create 2 manual.

Is there any one could help me with the above questions?

答: Ostensibly, the error in angular and linear velocity of the Create 2 is quite large--this is due in part to limitations of open-loop control of the robot based on motor encoders that introduce significant inaccuracy to the system. You can find many similar questions addressing this same concern.</p>


问:
Should a MG996R Servo's extreme position change over time?
This question is a follow on from my previous question, Overheating/Jamming MG996 servo.

I have recently purchased my first ever servo, a cheap unbranded Chinese MG996R servo, for £3.20 on eBay.

After mounting the servo horn and the bracket, I realised that I had not mounted the horn in a tout a fait 0° orientation, rather the angle between the bracket and the servo side was approximately 20°. However, after switching the servo on and off a couple of times, with each time allowing the servo to perform, say, about 10 sweeps each time, I quickly noted that the servo’s extreme positions were changing over time, so that the initial extremes and then the extremes after about 5 on and off cycles, had changed by about 15°, so that now, 0° and 180° the bracket is now parallel with the body of the servo.

I was quite surprised at this, as I had assumed that the 0° and 180° positions would be fixed, and not change over time, or vary each time that it was switched on and off.

Seeing as there should be a stop peg on the gear connected to the potentiometer inside, how is this even possible?

答: Is there anything with a weight (actually moment of inertia) connected to the servo? If so, it might be that the plastic "mounting" part is slipping with respect to axle. Axle shouldn't ever be changing extremes.</p>


问:
How to test how much current 9 servos can draw at a time?
Plus how should I use a multimeter to test it?

P. S.  Really sorry for a noon question.

答:
I assume that all the servos are identical, so it is enough to measure only one, and multiply the result by 9.

The best would be if you could use a lab bench variable power supply, like this. With one of these you do not even need a multimeter as these power supplies are able to measure the current they are sourcing. You simply just need to connect the "+" to the VCC of the servo and the "-" to the GND of the servo, set the output votlage and check the current.

If you do not have access to such a device then the following setup should be used.

As you can see the multimeter should be connected in series with the servo to measure its current.

You should connect to multimeter cables as it can be seen on the following image.

(source: engineersgarage.com)

You are going to measure DC current, and possibly it will be over 1 A, so choose the measurement range accordingly.
The red cable goes to the power supply Vout ("+") and the black cable goes to the VCC of the servo.

Make sure the all of your wires are suitable for the measurement, they won't melt or catch fire because of large currents. And if exists, check the datasheet of the servos about its current comsuption, just to know what range to expect.


答: Servos don't really have the punch power I think you are looking for, you mentioned stepper motors being geared up but low torque - there are many steppers available that do exactly the opposite e.g. high RPM internally but thanks to a gear head fitted directly to the motor cylinder the actual drive shaft has a much lower RPM with high torque.  You haven't mentioned if the arm is just to go from point A to point B or you want it to be fully articulated and controllable similar to the drawing arm in your diagram and you also have not mentioned your control device e.g. is it computer controlled or manual (such as a joystick). You also have not mentioned the most obvious choice for arm control which is pneumatic, have you ruled this out for a specific reason?  Finally, does it have to be an arm or just a mechanism to hit the puck as you could use simple x/y axis control e.g. left/right backward/forward this is the type of mechanism you would find in a plotter printer or controlling the crane arm in those arcade machines where you have to grab the toy!  a servo where X & Y meet could control the angle of the surface that hits the puck giving even more control and accuracy.  If you come back to me with more specific requirements I'll try and give a more specific answer!  Good luck.</p>

Title: 2DOF arm with quick movement: Stepper, servo, or DC motor?

Body:
To make a two degree of freedom arm capable of speeds needed to play air hockey, how should the arm be controlled? I'm wondering about speed vs accuracy.

The following image is from a project involving a 2DOF drawing arm:

For this air hockey project, the general mechanics of that arm seem appropriate. it can move the "hand" around a 2D plane. I also like how both motors are at the base of the arm, instead of having the 2nd motor at the elbow (which adds weight to the arm and slows it).

However, the drawing robot is slow.

Steppers:

I understand that in general, steppers are 'slow'.

But, steppers have accurate positioning, which is very important in a game of air hockey. I also know that the steppers can be geared-up, but then they lose torque. The steppers would need to handle the inertia of quick, back-and-forth arm movement.

Hobby servos:

I've used small servos for other projects, but the accuracy was poor. Most don't have a way to read the angle externally, and those that do, have noisy signals. I'm not sure how strong the hobby servos are, and if they can be accurate enough for this project. I understand that using digital servos improve dead band issues.

DC motors with external feedback:

The only other method I can think of for controlling the arm would be to use DC motors with sensors like as rotary encoders. I think I would need an absolute rotary encoder.  But they seem to be around \$50-$1000, which is a bit much for a solution I'm not sure will even work out. Perhaps there are cheaper solutions to motor angle measurement. I could just use a potentiometer, but then I'm worried about noise again.

It's worth noting that I don't know of any easy or affordable way to design my own drivetrain. All I have is a drill, and I don't know how I would mount shafts/bearings and such, even if the gears themselves were affordable.

This means that if I need to gear-up or down, I don't think I can unless it's cheap and involves simple tools.

So for the arm: DC motors with external feedback, servos, steppers, something else?...

Which method would be the best in terms of speed, and which for accuracy? I'm wondering which would cost less as well, but I understand that is a grey area.

I'm leaning towards servos out of simplicity. I'm may try digital servos with ball-bearings, in the hope they that will move quick enough, but be strong enough to handle the inertia of the arm.

(Note that a 2DOF arm is desired, and not something else like a 3D-printer x-y belt system.)