soph week 5/12 - 5/16
wanted to further simplify my code, even though it was already pretty simplified. also added a few things.
directional movement changes
previously, my code looked like this:
void forward() {
digitalWrite(MOTOR_A1, HIGH); digitalWrite(MOTOR_B1, HIGH); digitalWrite(MOTOR_A2, LOW); digitalWrite(MOTOR_B2, LOW);
}
void right() {
digitalWrite(MOTOR_A1, HIGH); digitalWrite(MOTOR_B1, LOW); digitalWrite(MOTOR_A2, LOW); digitalWrite(MOTOR_B2, LOW);
}
void sstop() {
digitalWrite(MOTOR_A1, LOW); digitalWrite(MOTOR_B1, LOW); digitalWrite(MOTOR_A2, LOW); digitalWrite(MOTOR_B2, LOW);
}
void left() {
digitalWrite(MOTOR_A1, LOW); digitalWrite(MOTOR_B1, HIGH); digitalWrite(MOTOR_A2, LOW); digitalWrite(MOTOR_B2, LOW);
}
while there is nothing wrong with this, it was quite cluttered with all the digitalwrites, so i decided to simplify it.
using a function to control the motors, i was able to set a value (high or low) to each motor without having to continuously write âdigitalwrite(motor____, high/low).
void controlMotors(int a1, int a2, int b1, int b2) {
digitalWrite(MOTOR_A1, a1);
digitalWrite(MOTOR_A2, a2);
digitalWrite(MOTOR_B1, b1);
digitalWrite(MOTOR_B2, b2);
}
with this, i could just set low or high for each state:
void forward() {
controlMotors(LOW, HIGH, LOW, HIGH);
}
void right() {
controlMotors(HIGH, LOW, LOW, HIGH);
}
void sstop() {
controlMotors(LOW, LOW, LOW, LOW);
}
void left() {
controlMotors(LOW, HIGH, HIGH, LOW);
}
void backwards() {
controlMotors(HIGH, LOW, HIGH, LOW);
}
in addition, i got rid of my old star function and âstartRâ function as the right button for some reason didnât work (probably cause i wired it wrong on my pcb).
button changes
since the right button was always âonâ for some reason, i decided that it wasnât necessary, and just removed it. also, since my code for the buttons was all over the place, i decided to consolidate it into a single function.
void buttonhandling() {
if (digitalRead(BUTTON_L) == LOW) {
can_start = false;
Serial.println("startL");
startL();
}
}
this keeps the same idea nad attack pattern of the button, but consolidated
sensor changes
with my old code, when the sensors got activated, the motors moved backwards for a set amount of time. however, it sometimes wouldnât be enough time, and would end up moving forward too early / turning too early.
to fix this, we used a while loop and waited an extra second before starting the turn. in addition, more functions were created to further neaten up the code.
old:
void sensorhandling() {
// NC pin. HIGH PUSHED, LOW NOT PUSHED
if (digitalRead(SEN_L) == HIGH && digitalRead(SEN_R) == HIGH) {
backwards();
}
else if (digitalRead(SEN_R) == LOW && digitalRead(SEN_L) == HIGH) {
backwards();
delay(300);
right();
Serial.println("turn right");
delay(200);
}
else if (digitalRead(SEN_L) == LOW && digitalRead(SEN_R) == HIGH) {
backwards();
delay(300);
left();
Serial.println("turn left");
delay(200);
}
else {
forward();
Serial.println("forward");
delay(500);
}
}
new:
void sensorhandling() {
// NC pin. HIGH PUSHED, LOW NOT PUSHED
if (digitalRead(SEN_L) == HIGH && digitalRead(SEN_R) == HIGH) {
backwards();
}
else if (digitalRead(SEN_R) == LOW && digitalRead(SEN_L) == HIGH) {
while(digitalRead(SEN_R) == LOW && digitalRead(SEN_L) == HIGH) {
backwards();
}
delay(1000);
turnRandom(left);
}
else if (digitalRead(SEN_L) == LOW && digitalRead(SEN_R) == HIGH) {
while (digitalRead(SEN_L) == LOW && digitalRead(SEN_R) == HIGH) {
backwards();
}
delay(1000);
turnRandom(right);
}
else {
forward();
}
}
with all of these coding changes, my setup and loop was simplified drastically, now looking like this:
void setup() {
Serial.begin(9600);
pinMode(MOTOR_A1, OUTPUT); pinMode(MOTOR_A2, OUTPUT); pinMode(MOTOR_B1, OUTPUT); pinMode(MOTOR_B2, OUTPUT);
pinMode(SEN_L, INPUT_PULLUP); pinMode(SEN_R, INPUT_PULLUP);
pinMode(BUTTON_L, INPUT_PULLUP); pinMode(BUTTON_R, INPUT_PULLUP);
}
void loop() {
if (can_start) {
buttonhandling();
}
if (!can_start) {
sensorhandling();
}
}
testing shenanigans
we finally decided to get our sumobot assembled and i could finally test my code just to find some problems while testing. we encountered quite a bit of problems that we had to fix.
however, if anyone saw my pcb schematic that i made for the sumobot, you may have noticed that i donât have a common ground.
pcb problem
well, we all didnât notice this until we started to test the sumobot where we saw that the sumobot only got power when the lever roller switches werenât pressed down for some reason. despite this, it worked to some degree for some reason (probably using a digital pin on the metromini as ground?)
after some re-looking on the pcb document, we noticed this problem. however, rather than re-milling a pcb, we decided to just make a new trace for ground.
with this fixed, we started testing again.
minor setback
one of the main issues that we wanted to address was the lack of turning by the sumobot. while this was a quick fix of changing the delays to allow the backwards(); function to further back up, i accidentally broke one of the two sumobots.
for some reason, i just forgot to react or protect the bot in case it fell of the table, and it ended up falling off the table.
while this was easily fixed by reprinting the base and re-cutting the acrylic piece, it was a minor setback, and i started testing code on the second sumobot that miles made.
testing problems cont.
right away, we noticed that one of the major problems was that the robot when crossing the white line (as the lever rollers canât detect color but rather when it isnât pressed), it was unable to bring itself back up.
me and miles spent quite a while debugging possible fixes to this problem, some of which included:
- increasing the amount of times moving backwards off the edge
- implementing a âbunnyhopâ mechanism where it âjumpsâ, detaching the switches from the edge.
- adding a ramp to the sensors so it wouldnât get caught on the edge.
while the first two mechanisms didnât work, miles eventually noticed that due to the â90°â angle with the rollers, it wouldnât get back up as it was stuck in a perpendicular angle from the edge and the roller. to fix this, he suggested making a ramp to put onto the sensors to prevent it from getting jammed.
cardboard ramps to prevent jamming on the edge
we decided to just use cardboard for a quick fix. combined with some hot glue, this ended up working amazingly.
finally, we wanted to not have a set amount of turning delay, as it led to predictable movements and the sumobot staying on one side of the arena.
turning fixes + problems
originally, i was going to use a random function to generate a random number for the delay value, something like this:
long x;
void setup() {
Serial.begin(9600);
}
void loop() {
randomSeed(micros());
x = random(500, 1501);
Serial.println(x);
delay(500);
}
however, while setting this up in the sumobot i realized that every time the sumobot was run, the same values were showing up.
startL indicates that it has been rerun, and you can see that the same values show up.
this was because i had the seed where the random numbers would come from in the setup, where it would only change if it was re-uploaded. to fix this, i moved it to when the button gets pressed, which led to randomness every time like i wanted.
different numbers... wow!
with all of this, i believe our sumobot is done. potentially gotta fix the problems where it gets stuck for a bit (if possible), but thatâs all.
sumobot results
the orange bot (the one that miles claimed) got second, losing to tims and benji with their extremely fast, suicide bot.
while we are given an extra week to revamp and improve our bots (as a few didnât work as intended), we likely wonât be continuing our bot, marking the end of this project..
long post. thanks for reading it if you did.