# Tag Info

23

There isn't a lot of information here. Let's fix the wheels as separated by distance $b$, and each wheel has orientation $\theta_i$ with respect to the line joining them. Then assume each wheel can be independently driven with an angular velocity $v_i$. If the wheels are independently driven, but fixed in direction, $\theta_1=\theta_2=90^\circ$, you have ...

16

The simplest controller is a linear state feedback controller. There are essentially 4 different states that you need a gain for. These are tilt angle, tilt rate, speed and position. LQR (linear quadratic regulator) is a method to design these gains (after obtaining a linearized state-space representation of your system). If you do not have a state space ...

9

I believe the most popular solution to this problem is an LQR controller. The problem you are trying to solve is the inverted pendulum problem. Using those keywords, you should be able to Google someone's open-source code. The next problem will be mapping most of the relevant physics quantities to your application (weight, motor torque, etc...)

9

To answer your first question: if you really want to find the true kinematic equations for differential drive, I wouldn't start approximating by assuming that each wheel has moved in a straight line. Instead, find the turning radius, calculate the center point of the arc, and then calculate the robot's next point. The turning radius would be infinite if the ...

7

The principle lying underneath the sphero robot's design and locomotion is shifting of the centre of mass of the ball and making it unstable which makes the ball roll [1,3,4,5,6]. A controlled and calculated shifting of the centre of mass to the appropriate position can achieve desired trajectories of the ball. Apart from the above said principle, a few ...

7

With Subsumption Architecture, you should carefully design your behaviors in such a way that if you assign task T priority n, then T should be what the robot should do if all tasks with higher priority than n are ignored. Let's order your example tasks, then figure out a way to implement it. Your tasks are evade, find and track. In general you would want ...

5

I put together encoders for this exact chassis. Rather than reflecting ones, I used slot ones. I thought I could work off the hole in the white gear, but it turns out the plastic is pretty transparent to IR, so I ended up using some black electical tape (high tech, I know) to make opaque regions on the gear. After building two encoders, I discovered ...

5

Typically, tracking the position and orientation of a vehicle is not accomplished by looking at the wheels — it's done with navigation sensors. If you were attempting to have closed-loop control (i.e. servo control) of your motors then wheel-mounted position sensors might be appropriate. But if the goal is to support "autonomous driving", then I don'...

5

Since I don't know your skills in control engineering/theory, I recommend you to start with a PID controller. It is a simple controller and you will find many code implementations of it. The drawback of the PID is that you probably will end up spending some time tuning the parameters by hand. Some years ago I used it to control a two wheeled Lego Mindstorm ...

4

You could use other ways of measuring orientation, such as an accelerometer, optical tracking of markers, or a depth sensor pointed at the floor.

4

If you really want to dive into the mathematics of it, here's the seminal paper that unified and categorized most models for wheeled robots.

4

One alternative to sensing the wheel movement is to actually track the vehicle movement over ground. I know that some people have done it using optical mouse sensors. The results will depend on the type of underground you are expecting. The upside is however that you track the actual vehicle movement, which is what you are really interested in.

4

short answer; no you really need to do things quite a bit differently. long incomplete answer; Let me give you some psuedo code appropriate for robotC, that puts you on a better path. First, do not use tasks - this is NOT what robotC tasks are for. They could be made to work, maybe, maybe not (and you need quite a few changes to even try). // global ...

3

You're describing an encoder. It will give you a signal every time the wheel turns a some amount of degrees. http://www.bot-thoughts.com/2011/03/avc-bot-wheel-encoders.html

3

Kinematics of mobile robots For the figure on the left: I = Inertial frame; R = Robot frame; S = Steering frame; W = Wheel frame; $\beta$ = Steering angle; For the figure on the right: L = Distance between the wheels; r = radious of the wheel; Now we can derive some useful equations. Kinematics: $\hspace{2.5em}$ $\vec{v}_{IW} = \vec{v}_{IR} + \vec{\... 3 I can recommend an alternative which has worked for me quite well. I derived the dynamical model of a inverted pendulum, then linearised it around the stable operating point. With this simplified model I found the LQR controller which keeps my robot upright and tracks my desired linear and angular velocities. The robot working: https://www.youtube.com/... 3 I've calculated a max. traction force of 6.51N. Does this mean a torque force at the wheels of up to and including 6.51N can be applied, to drive the robot without the wheels slipping? ...$max(F_{t}) = μN$Yes, the traction force equation means that the wheels can push on that surface with up to and including that force (and the surface ... 3 Are the wheels essentially hollow except for the spokes? If they were, it would seem to me like adding a small hole a little offset from the front axle (the wheel without gears) would be a good place to put a light detector. Of course that would not work too well in the dark. Each spoke, or more properly tooth on the gear, while technically would be correct,... 3 :EDIT: Let me put some numbers on this. Let's say you want to get from any angle to vertical in half a second. Say for now (more on this unrealistic scenario later) that you want to get from "laying down" (90 degrees from vertical) to upright in half a second. This is just for the purposes of coming up with a spec. The position equation:$$\theta = \... 2 For a repeated calculation, it doesn't matter whether you find$\Delta\theta$before or after you apply$\theta$to the$\Delta{x}, \Delta{y}$calculation. You will always be alternating between a position and an orientation calculation. In a practical sense, it might be better to calculate$\Delta\theta$after you calculate$\Delta{x}, \Delta{y}$, since ... 2 Mathematically, the fact that you now have rotation (mostly) eliminates that parameter as a possible control parameter. Basically you'd have to redesign your algorithm to accept a large and variable angular velocity component while still using angular velocity in your feedback. The less noisy this is, the better the probable outcome simply because you're ... 2 You need some sensors to detect the state of the system. First linearize the system into a state space form, then consider what sensors you do have. Then check if it is observable. If it is observable, then you can feed the estimated states into your controller. Currently, it sounds like you are using the wheel position and back EMF (for velocity) as ... 2 If you managed to get it stable in a stationary configuration, I don't really see how it would be much more difficult to get it stable for a constant velocity. From a system model point of view it would effectively be the same thing bar some velocity offsets. If the transitions between velocities are not very large it should fall within the range of the ... 2 Yes, that's correct. A "good choice" for acceleration has nothing to do with velocity. Generally, acceleration limits are chosen based on motor thermal ratings. You should have some design load the motor should accelerate, that design load should require some quantity of torque, the motor constant relates torque to current, and then the current heats the ... 1 SLAM is only needed when you are also building a map. You already have a map so the problem is localization. To be exact the problem you want to research is Monte Carlo localization or particle filter localization. A fantastic book on it is Probabilistic Robotics if you can get your hands on it. Some slides describing the resources in the book can be found ... 1 Your signal actual going back and forth like that; it's registering with the microcontroller because you're at an intermediate voltage. As @TobiasK mentions, this is called "bouncing". You're trying to use this for controlling tires, so I would suggest you do a little math to determine whether or not a "subsequent" signal could be considered valid or not. ... 1 Well, if it is truly a caster wheel with two differential drives, then I'd just assume that the castor is not a constraint at all! It's a freely rotating wheel that should just follow the direction of motion induced by rotating the differential wheels. In that case, you can use this answer. 1 Well, I moved my answer here from the Engineering SE because it looks like your question is probably going to get closed there, just like it got closed at the physics site. Assuming everything about the vehicles is the same - mass especially, but also shape, center of gravity, etc., such that the entire problem boils down to tire grip, you will lose. See ... 1 "Is there a way to account for possible error in the speeds of the motors so that the robot can end up in a very precise location?" The other answers describe the approximate solution (encoders). It depends on what you define 'precise' as. For an Arduino budget project, it is probably precise enough. But typically, say you direct your Arduino robot to move ... 1 You're attempting to move a robot along a predefined path without the aid of sensors, so really we just need to convert the list of points into a list of pre-scripted actions. Convert input points to$({\Delta}x, {\Delta}y)$pairs Convert$({\Delta}x, {\Delta}y)$pairs to$(\Delta\theta, d)$pairs Convert$(\Delta\theta, d)$pairs to$(V_{left}, V_{right}, {...

Only top voted, non community-wiki answers of a minimum length are eligible