Comment-out each of the servo movements in turn (one, then another, then another...) to see if that unsticks things.
No, it's referring to the fact that the pin is already LOW.
I see. Is the 2us not relevant to pausing/blocking before the next command? Can the pause be removed without the next command being too soon? Thank you.
hmm, did not seem to do much, just does the one servo movement that is there, initializes the robot (.init) then repeats over and over
I changed it to 0 and it did not seem to effect anything yet, but it might once I actually get this thing working, like you said could be that it'll update too fast
Absolutely it can be removed.
It's only there because of lazy cut-and-paste.
There should be a pause of at least 10000 times that delay between ultrasound pings.
Well yes I have been working with examples to get my bearings because im more well versed in python, but from what ive read around using python through arduino is not the handiest. I am trying my best to understand arduino/C++ more so that I can twist it to how I need it, that is why I am here to see why this loop just will not work
I tried putting my if statements into the function itself, but get the same outcome so must be the way im trying to loop it I suppose
// defines pins numbers
const int trigPin = 9;
const int echoPin = 10;
const int buzzer = 11;
const int ledPin = 13;
// defines variables
long DUR;
int DIS;
//int safetyDistance;
#include <BraccioRobot.h>
#include <Servo.h>
#include <Braccio.h>
Servo base;
Servo shoulder;
Servo elbow;
Servo wrist_rot;
Servo wrist_ver;
Servo gripper;
void setup() {
pinMode(trigPin, OUTPUT); // Sets the trigPin as an Output
pinMode(echoPin, INPUT); // Sets the echoPin as an Input
pinMode(buzzer, OUTPUT);
pinMode(ledPin, OUTPUT);
Serial.begin(9600); // Starts the serial communication
}
void loop()
{
Serial.println( "LOOP");
// Clears the trigPin
digitalWrite(trigPin, LOW);
delayMicroseconds(0);
// Sets the trigPin on HIGH state for 10 micro seconds
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(trigPin, LOW);
// Reads the echoPin, returns the sound wave travel time in microseconds
DUR = pulseIn(echoPin, HIGH);
// Calculating the distance
DIS = DUR*0.034/2;
MoveRobot();
//safetyDistance = distance;
//Serial.print( "duration ");
//Serial.print( DUR );
//
//Serial.print( " distance ");
//Serial.print( DIS );
//Serial.println();
//
//delay(50); //used for troubleshooting
//
//if (DIS <= 5){
// digitalWrite(buzzer, HIGH);
// digitalWrite(ledPin, HIGH);
//
//}
//while(DIS >= 5){
// digitalWrite(ledPin, LOW);
// MoveRobot();
// continue;
//}
//Serial.print( "duration ");
//Serial.print( DUR );
//
//Serial.print( " distance ");
//Serial.print( DIS );
//Serial.println();
}
void MoveRobot() {
if (DIS <= 5){
digitalWrite(ledPin, LOW);
Serial.print( "duration ");
Serial.print( DUR );
Serial.print( " distance ");
Serial.print( DIS );
Serial.println();
}
if (DIS >= 5){
Position pos, down, up, pos2;
// (M1, M2, M3, M4, M5, M6)
BraccioRobot.init();
delay(2000);
pos.set( 90, 90, 45, 45, 90, 20);
down.set( 90, 90, 22, 22, 90, 70);
up.set(90, 90, 90, 90, 90, 73);
pos2.set(90, 90, 10, 10, 90, 20);
// Move the robot to the position with a specified speed between 20-200 degrees per second
BraccioRobot.moveToPosition(pos, 25);
//Wait 5 seconds
delay(5000);
BraccioRobot.moveToPosition(down.set(90, 90, 10, 10, 90, 20), 50);
delay(5000);
BraccioRobot.moveToPosition(pos.set(90, 90, 10, 10, 90, 70), 50);
//Wait 2 seconds
delay(2000);
BraccioRobot.moveToPosition(up, 50);
delay(2000);
BraccioRobot.moveToPosition(pos.set(90, 90, 10, 10, 90, 70), 25);
BraccioRobot.moveToPosition(pos2, 50);
return;
digitalWrite(ledPin, HIGH);
Serial.print( "duration ");
Serial.print( DUR );
Serial.print( " distance ");
Serial.print( DIS );
Serial.println();
}
}
Which pins are you using for each of the six servos?
You've probably answered this, somewhere in the 50 posts, but I'll ask anyway. What's your power supply for the servos? And, did you post a schematic?
I found a possible conflict in pins:
HC-SR04:
const int trigPin = 9;
const int echoPin = 10;
const int buzzer = 11;
const int ledPin = 13;
ROBOT:
base.attach(11);
shoulder.attach(10);
elbow.attach(9);
wristRotation.attach(5);
wrist.attach(6);
gripper.attach(3);
I know you are asking @dilanasmaz, but we are seeing the same output, and my setup is a simulator (internet).
Gotcha. Sorry, Servos are my pet peeve right now.
I'll step out.
@dilanasmaz @camsysca
Servo preview... in pictures!
I have repetetive servo movement... it gets "stuck" when I go under 5cm... when it wakes up, I want the "24" will not happen... BLU LED is "buzzer" I also changed pin assignments
1 Like
And... it woke up... and no more 24! However... it really, really hangs when <5cm while the servos are doing their thing.
1 Like
Holy sugar (swearing not allowed right?) this man has done it, I don't know why I did not think the pins would be the issue, because its a motor shield that sits on top the Arduino Uno, but must be the default way the motor pins are set up in terms of the motor shield going into the UNO. Im not sure why that wasn't the first thing I checked considering that on my last arduino project, very similar issues except with DC motors, no sensor.
For a little background, the sensor is basically detecting a block, if no block is there, it goes to get another (ill be changing the if statement), if there is one, it stays chilling. Without the sensor I would just have to really time the blocks removal so it doesn't clash with the other robot(s).
In fact, it was you who kept searching, @Idahowalker who identified cleaning up the loop, @anon56112670 and @LarryD who pointed to a copy/paste/congenital flaw, @PerryBebbington who showed you "one post good, two post bad", and the only way I found the "pin in the codestack" is the same way the others (you included) did - I saw something that did not make sense. For the pins, it was the fact that they were not defined in the main sketch... even when the focus was on 24. Sometimes the clue is not the problem (trying to eliminate 24), rather, it is the solution not indicating its origin (the pin definition). You will find that being "focused" is sometimes detrimental - sure it is how we keep on a path of resolution, but those obvious fingerprints can lead one astray. I do not know if the word is "defocus" but... back in my day.. people called the misleading "focus" part "fingerprint troubleshooting"... where the students are looking for the teacher's fingerprints on the circuit cards disabled, or the mangled code to find the cause of the problem... my angle was to literally sniff the container. If I couldn't smell burnt stuff, I smelled for warm stuff. If all smelled good, I would recite the boot sequence from the tech-specs (the old way of saying "datasheet"), "power to the power, logic to the logic, output to the output" and "load the configurator the, configure the configureator, load the bootscript, configure the bootscript, boot"... so all those looong, boring, easy-to-forget things actually were noted for a reason. The art of coding has a scientific background, AND vice versa. Keep your mind open. Let the facts show themselves. Use your resources. Done.
Have fun!
2 Likes
Thanks again, not just to you but everyone. To be honest through this I did learn more about the structure compared to Python, how to write more efficiently etc. so although it was a small detail, it taught me so much more than if I had just found it straight up!!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.