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 need to plot a real time signal, 140 points/sec, like an oscilloscope of sorts that traces 7 waves (20 values/sec each). It comes in as a UDP broadcast, this is the visualizer of the traffic. Ideally, this should "flow" to the side, like the output I currently get from the arduino IDE's serial monitor.
I plan to use Qt, which would give me both the networking AND the plotting. I will have an undecorated full-screen modal window (kiosk mode). Output is on an HDMI Touchscreen 1920 x 1080 (but I do not need to use the full surface for the plot, some 40% of it will be used by a GUI). I am thinking I could buffer the values and plot them out only 2-3 times/sec.
Problem is: I have a Raspberry Pi 3 for iron. Do you think a R.Pi can make it or am I just wasting my time with something too undersized for the job?.
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'm trying to create a robot using three HC-SR04 ultrasonic sensors and my Arduino Pro Mini but I've run into a few problems. In short the robot's function is as follows:
The robot is dual wheeled, with an H-bridge (SN754410) driving each wheel.
There's one HC-SR04 sensor on each side of the robot, the left one activates the left wheel motor when it detects a hand in front of it, vice versa for the right side.
i.e. To make the robot go forward, we place our hands near the left and right side of the robot, to make it turn right, we remove the right hand and keep the left one in place, vice versa for turning left, etc.
A third HC-SR04 is located the top of the robot, such that it activates a third motor when the user's hand is hovering above the robot.
My test code is as follows:
#include <NewPing.h>
#define SONAR_NUM 3 // Number of sensors.
#define MAX_DISTANCE 20 // Maximum distance (in cm) to ping.
NewPing sonar[SONAR_NUM] = { // Sensor object array.
NewPing(4, 5, MAX_DISTANCE), // Each sensor's trigger pin, echo pin, and max distance to ping.
NewPing(6, 7, MAX_DISTANCE),
NewPing(8, 9, MAX_DISTANCE)
};
#define ena1 10 //trigger for left motor H-bridge
//#define ena2 11 //trigger for right motor
//#define ena3 12 //for top motor
long sensors[3]; //array to store sensor distances
void setup() {
Serial.begin (115200);
pinMode(ena1, OUTPUT);
//pinMode(ena2, OUTPUT);
//pinMode(ena3, OUTPUT);
}
void loop() {
for (uint8_t i = 0; i < SONAR_NUM; i++) { // Loop through each sensor and display results.
delay(50); // Wait 50ms between pings (about 20 pings/sec). 29ms should be the shortest delay between pings.
sensors[i] = sonar[i].ping_cm();
}
Serial.println(sensors[0]);
if (sensors[0] > 0 && sensors[0] <= 20){
Serial.println("detected");
digitalWrite(ena1, HIGH);
}else{
Serial.println("NA");
digitalWrite(ena1,LOW);
}
}
As you can see, I'm using the NewPing.h library to collect the sensor data. After each iteration of the for loop, the distances detected by the sensors are stored in a sensor array. When a hand is placed about 15-20 cm away from a sensor, the arduino sends a digital "HIGH" trigger signal to the respective H-bridge, activating the respective motor (I only have one of these pins, "ena1", enabled in my code, the other two are commented for the test).
To test my code, I simply connected the H-bridge trigger pin "ena1" to an LED, this pin is activated by the sensor whose distance data is stored in variable "sensors[0]". However, after I compile and upload my code, I notice that the LED simply flickers faintly as I put my hand in front of the sensor. As if the LED is being turned on and off very fast.
The output from the serial monitor is as follows:
15
detected
0
NA
16
detected
0
NA
14
detected
As you can see, by putting my hand about ~15cm in front of the sensor, the sensor returns the correct distance and the "ena1" pin is set to high (as evidenced by "detected" being printed to the screen).
However, the sensor always returns a "0" value at the next iteration of the main loop (while my hand is still in front of the sensor), subsequently setting the "ena1" pin to LOW again, which might explain why the LED is being turned on and off so fast.
I'm not sure why this is happening... Interestingly, by removing the digitalWrite lines from the code, the sensor returns the correct values (i.e. no "0" value when my hand is in front of the sensor).
Any ideas on how I can fix this?
Thanks in advance!
This might be a hardware error. I've seen cases where, if the pins of the HC-SR04 were a brass (gold-ish) color, the sensor had a tendency to throw out a 0 for distance.
My suggestion is to get an other ultrasonic sensor, preferably with more silver-ish colored pins.
Your code looks good though!
Good luck!
I know that what I'm going to ask could sounds crazy, but I'm trying to figure out how to resolve a problem in a smart way.
It's quite difficult to explain my problem, that's why I made an hand-made draft downloadable from here :) https://dl.dropboxusercontent.com/u/5049281/static/Images_Impulse_Direction.zip.
images in that zip (copied by Spektre)
The setup can be approximated with a pipe endorsed on a rubber wall. The pipe is firmly connected (whit an unknown position and orientation) to a IMU equipped with an accelerometer and a gyroscope (sample frequency 110 hz).
I would like to discover the direction of the pipe axis (expressed in the IMU reference system) analyzing the data acquired during some taps at the end of the pipe in the same direction of the pipe axis. The taps are applied with the palm of the hand. In the figure the direction should be just on X axis.
I think that if the motion is just a translation (I could verify it checking if gyroscope data is close to zero), the acceleration (with the gravity removed) during the tap should have the same direction of the pipe axis.
Is there a smarter solution than just apply an high-pass filter to the signal an then save the direction of the sample with the higher magnitude?
Thanks for your help!