Is it possible measure a robot car movement distance only with ultrasonic sensor ??
I working on robot car, in the picture you can see how i placed my ultrasonic sensors(red points) and my question is if i can get width value??
Yes it is possible.
The low cost HC-SR04 sensor, can measure objects from 2cm to 4-5m.
The sensor will send some pulses and measure the time, until the pulses returns. So you can just measure the time (short pulse = near, long pulse = far).
There is just 1 problem with your car:
- it must reflect your pulses. If you don't have any wall or obstacles, you will always detect the maximal pulse with.
If you are inside a room, you can detect the movement. If you are outside or in a big room (more than 8x8m), this is not possible.
Related
So I am building a donkey car in raspberry pi 4 2gb. I have installed the software and all libraries needed and made changes in myconfig.py. My car runs properly, but I couldn't calibrate it to turn properly (left and right) according to https://docs.donkeycar.com/guide/calibrate/. If anyone could help it would be great.
code changes in myconfig.py
# #CAMERA
CAMERA_TYPE = "WEBCAM"
IMAGE_W = 200
IMAGE_H = 120
DRIVE_TRAIN_TYPE = "DC_TWO_WHEEL_L298N"
DC_TWO_WHEEL_L298N = {
"LEFT_FWD_PIN": "RPI_GPIO.BOARD.16", # TTL output pin enables left wheel forward
"LEFT_BWD_PIN": "RPI_GPIO.BOARD.18", # TTL output pin enables left wheel reverse
"LEFT_EN_DUTY_PIN": "RPI_GPIO.BOARD.22", # PWM pin generates duty cycle for left motor speed
"RIGHT_FWD_PIN": "RPI_GPIO.BOARD.15", # TTL output pin enables right wheel forward
"RIGHT_BWD_PIN": "RPI_GPIO.BOARD.13", # TTL output pin enables right wheel reverse
"RIGHT_EN_DUTY_PIN": "RPI_GPIO.BOARD.11", # PWM pin generates duty cycle for right wheel speed
}
This question is probably best asked in the robotics stackexchange or the donkeycar discord. But to answer your question, a differential drive robot (you've chosen the DC_TWO_WHEEL_L298N drive train, so I am assuming you have two motors connected to the L298N) does not need to have it's steering calibrated. So you can ignore that calibration step. The robot is steered by varying the throttle to each motor. For a left turn, the left motor is given less throttle, so it's wheel will turn slower than the right wheel; that will cause the robot to turn in a leftward arc. A right turn is similar but the right wheel turns slower.
I have tried varying the duty cycle of the servo motor but it only turns 180 degrees clockwise and anti-clockwise.
You need some measurement device to read the angle, if you want to stick with that servo. With the angle you can implement a closed-loop transfer function to approach the angle you want.
Servos as the FS90R are "continuously rotation servos" and the control signals sets the speed (exactly: the driving current, giving the torque) and direction. For example, see this fine explanation.
If you want to control the angle directly by the control signal, you need "the other" type of servo, described earlier in the linked Wikipedia page.
So, I need to build a simple gimbal with three servos to control pitch, roll and yaw. I have a 9dof imu which can give me the euler angles in degrees. Can I just connect these angle errors to servo outputs? As in with 1 degree error, the servo should rotate 1 degree, or do I have to use some form of pid control? I have worked with controlling regular dc motors with pid so that the bigger the error, the faster the motor should rotate to compensate. But it's not like I can adjust the speed the servo rotates at.
I recon there would be a problem when the angle error becomes very high in a small amount of time since the servo would take more time to reach the desired position instead of when the error is very small.
I did a similar project. It isn't perfect, but good enough. Cheap servos can't really be precise because of the cheap potentiometer inside and the horrible plastic gears.
There wont be much error overtime because common servos use a potentiometer and not a rotary encoder. Thus a PID is almost impossible.
I am using arduino and accelerometer MMA7341 to measure the acceleration in x direction of an oscillating metal table. But the mounting of the accelerometer is tilted by a small angle (say Q) . Is it affect the acceleration?. If it is affect the acceleration in x direction , how can correct it without changing the tilt of the acceleration sensor.
"Tilt" and "acceleration" are both the same, from the perspective of most sensors, since both measure a force, rather than an actual angle (tilt) or change in velocity (acceleration).
What you should do is make sure the object on which the sensor is mounted is "level", within the best of your ability to determine such a thing, and use the values from analogRead() or whatever else your device provides, as the "0" values.
For the MMA7341 you'll also need to calibrate your analog signals, or else use a high precision reference as input to the Aref pin, assuming you're Arduino exposes that pin.
I think this depends on what you are measuring. THe MMA7341 looks to be able to be used for acceleration as well as tilt. If you are measuring acceleration then the mounting position doesn't matter since acceleration is a change of velocity and the velocity delta will be constant regardless of orientation.
If you are measuring tilt then thats obviously different. You could theoretically measure the initial tilt and then compensate for that in your code if you wanted to of course.
I would like to create a digital (square) signal on my sound card. It works great if I generate high frequencies. But, since I can't output DC on a sound card, for lower frequencies the resulting digital bits will all slowly fade to 0.
This is what the soundcards high pass does to my square wave:
http://www.electronics-tutorials.ws/filter/fil39.gif
What's the mathematical function of a signal, that, when passed through a high pass will become square?
Ideally, the solution is demonstrated in gnuplot.
The sound card cuts out the low frequencies in the waveform, so you need to boost those by some amount in what you pass to it.
A square wave contains many frequencies (see the section on the Fourier series here). I suspect the easiest method of generating a corrected square wave is to sum a Fourier series, boosting the amplitudes of the low frequency components to compensate for the high-pass filter in the sound card.
In order to work out how much to boost each low frequency component, you will first need to measure the response of the high-pass filter in your soundcard, by outputting sine waves of various frequencies but constant amplitude, and measuring for each frequency the ratio r(f) of the amplitude of the output to the amplitude of the input. Then, an approximation to a square wave output can be generated by multiplying the amplitude of each frequency component f in the square wave fourier series by 1/r(f) (the 'inverse filter').
It's possible that the high-pass filter in the soundcard also adjusts the phase of the signal. In this case, one might be better off modelling the high pass as an RC filter, (which is probably how the soundcard is doing the filtering), and invert both the amplitude and phase response from that.
Some of the previous answers have correctly noted that it is the high-pass filter (AC coupling capacitor on the soundcard's output) is what is preventing the low frequency square waves from "staying on" so they decay quickly.
There is no way to completely beat this filter from software or it wouldn't be there, now would it? If you can live with lower amplitude square waves at the lower frequencies, you can approximate them by sending out something like a triangle wave. From a transient analysis perspective, the theory of operation here is that as the coupling capacitor is discharging (blocking DC) you are increasing its bias voltage to counteract that discharge thus maintaining the square wave's plateau for a while. Of course you eventually run out of PCM headroom (you can't keep increasing the voltage indefinitely), so a 24-bit card is better in this respect than a 16-bit one as it will give you more resolution. Another, more abstract way to think of this is that the RC filter works as a differentiator, so in order to get the flat peaks of the square wave you need to give it the flat slopes of the triangle wave at the input. But this is an idealized behavior.
As quick proof of concept, here's what a 60Hz ±1V triangle signal becomes when passing through a 1uF coupling cap on a 1Kohm load; it approximates a ±200mV square wave
Note that the impedance/resistance of the load matters quite a bit here; if you lower it to, say, 100ohm the output amplitude decrease dramatically. This is how the coupling caps block DC on speakers/headphone because these devices have much lower impedance than 1Kohm.
If I can find a bit more time later today, I'll add a better simulation, with a better shaped stimulus instead of the simple triangle wave, but I can't get that from your average web-based circuit simulator software...
Well, if you're lucky you can get one of those $0.99 USB sound cards where the manufacturer has cut corners so much that they didn't install coupling caps. https://www.youtube.com/watch?v=4GNRzwfP7RE
Unfourtunately, you cannot get a good approximation of a square wave. Sound hardware is intentionally slew rate limited and would not be able to produce a falling or rising edge beyond its intended frequency range.
You can approximate a badly deformed square wave by alternating a high and low PCM code (+max, -max) every N samples.
You can't actually produce a true square wave, because it has infinite bandwidth. You can produce a reasonable approximation of a square wave though, at frequencies between say 10 Hz and 1 kHz (below 10 Hz you may have problems with the analogue part of your sound card etc, and above around 1 kHz the approximation will become increasingly inaccurate, since you can only reproduce a relatively small number of harmonics).
Tp generate the waveform the sample values will just alternate between +/- some value, e.g. full scale, which would be -32767 and +32767 for a 16 bit PCM stream. The frequency will be determined by the period of these samples. E.g. for a 44.1 kHz sample rate, if you have say 100 samples of -32767 and then 100 samples of +32767, i.e. period = 200 samples, then the fundamental frequency of your square wave will be 44.1 kHz / 200 = 220 Hz.
I found an application that I build on it.
http://www.blogger.com/blogger.g?blogID=999906212197085612#editor/target=post;postID=7722571737880350755
you can generate the format you want and even the pattern you need.
The code uses SLIMDX.