Arduino Day 4

3/11/15 - 3/13/15: Basic Programs with Sciborg

Before we got started with the sciborg programs, Amy wanted us to test out a way of calling functions using dot() and dash() on a single LED. We were given code that signaled “SOS” on a LED pin and were asked to comment the code.

After finishing, we realized that using dot() and dash() was quite handy. They allowed for a more organized method of writing code, and would be useful when segmenting major components of the whole program so we could understand it better.  

Task: Comment “Single Motor” Code 

After downloading the Bricktronics package, we opened the “Single Motor” example and started to comment on the code. The code basically initializes the motor (m) and the shield (brick) and sets the speed to the ratio of 75% of its total speed, lets it run for a second, then it run faster (255%) for half a second. After it finishes that half a second, the motor goes in reverse at 75% speed for a second, then goes faster in that same reversed direction at 255% speed for half a second. The loop then starts the whole process over.

Task: Get the two motors to run simultaneously at the same speed

To get the second motor started, we named and initialized the second motor, “n”. Afterwards, taking out the extraneous lines of code that made the single motor turn faster and in reverse, we simply had both motors turn forwards at 255% speed.

When the motors are set to speed 1 and speed 0, the wheels will not turn because there isn’t enough power put in the motors to make the gears turn the wheel. After numerous trial and error attempts with running the motor at speeds lower than 75%, we determined that our sciborg will run with any speeds great than 50%. If it is exactly 50% however, or anything lower, it might move forward a little, but it will inevitably come to a stop. 

Task: Implement a full “hard turn” in our sketch

A hard turn meant that we would have to create a program so that the wheels, at full speed (255%), would turn in different directions for a small duration of time in order for the whole sciborg to turn. This task was fairly simple, and we used the dot() function to help separate out the main piece of the code we wanted to implement. Inside of our void loop() function, we used a while (true) loop to continuously go through the code (though we don’t really need it since the void loop() already goes through the code for us already). We set the speed of both motors to 100, asking our sciborg to move forward for 3 seconds and then to turn “hard” for one second, setting the speed of one motor to 255% forward and the speed of the other to 255% in reverse, called by the dot function.

Task: To implement variations of “soft turns” in our sketches

From our “hard turn”, we found ways to implement softer turns by reducing the speed of the motors and by increasing the duration in which they turn. We also discovered that since our sciborg will never completely drive straight, we can implement more gradual turns by increasing the difference between the motor speeds by one, such as 164 and 165. 

For the softer turn shown in the video, the softer turn doesn’t just happen in one direction, but in both, which is why we decided to film the video of this attempt. All four of our softer turn attempts work though, allowing the sciborg to turn more gradually.

Task: Getting the Sciborg to Drive Straight 

This was a tricky task. It was not easy to get the sciborg to drive straight, and in order to complete this objective, we went through much trial and error, changing the speeds of the motor in our program and testing it out often. The make-up of the motors, gears, and wheels weren’t perfect, which is why we couldn’t expect the sciborg to drive straight and is why the this task, instead of being called “getting the sciborg to drive straight” should be called “making up for the wheels’ imperfections”. We noticed that if we increased the speed of both wheels to the max, it was slightly easier to get the sciborg to drive straight, because the maximum speed was minimizing the slight imperfections of the wheels. However, the problem with this was that the sudden burst in speed in the motors usually caused one of the wheels to “jump” a little upwards, setting it off in another direction, which is why we eventually lowered the speed, and to set the sciborg off in a straight direction. We tried many combinations of 1% higher, 1% lower speeds, but that didn’t help to balance the imperfections, because one wheel would eventually be slightly faster than the other and the sciborg would turn.

 

Task: 10 Feet Challenge

In this task, we were asked to program our sciborg so that it would drive exactly 10 feet and stop. In our code, we again used the dot() function, but this time so that the code could never escape from the dot() function and return to the start of void loop(). We knew that the two motors of the sciborg had to be turning for a certain duration of time, but it also had to just stop and remain stopped for the time after. So that’s what we did, where the void loop first goes through the for loop, and allows both motors to run at full speed (255%) for 10 seconds, and then escapes the for loop. Afterwards, the dot function is called and the program remains trapped inside the while (true) loop, where both of the speeds of the motor is set to 0, which isn’t enough power to cause the sciborg to move. We were lucky that our first trial of 10 seconds worked, and in hindsight, we could have taken out a few lines of extraneous code, such as the for loop and if the if…break structure, since the void loop() would have went through the same lines anyways.

Task: Comment “Motor Button” Code

Commenting the motor button was a bit of a challenge, because we had to understand the delays and the while(b.is_released()) {}; structures. We figured out through testing though that the first delay stops the program for 100 milliseconds to allow the processor to figure out the button is pressed, and the second delay stops the program for 100 milliseconds to figure out the button is released. Debounce, as asked by Amy to define it, is a way of allowing the processor to track whether or not the button has been pressed once. It checks the input twice within a short amount of time, and if there is no debounce, the processor will think the button has been pressed multiple times. I wrote this in the screenshot of the code above, but because it was too wide, the code wasn’t decipherable and I cropped the photo to include only the main parts of the code. While the button is released, the motor continues to turn forward, but when the button is pressed, the wheels stop, and when the button is finally released, the directions of the turning wheels are reversed.

 

Task: Make and run sketch of signal button  

In this final sketch, we modified the Motor Button program to have a turn and reverse. We created a dot() and a dash() function to help clarify our code. The void loop() starts with the sciborg moving forward, with speeds 155 and 154.75 respective to motor m and motor n. We were trying to adjust the speeds for our sciborg to drive straight. Then the code goes through while(b.is_released()) {}, which basically signals if the button is pressed, because if it was, this while loop wouldn’t be true and the void loop() would continue with the code. Both of the motors then stop, and the sciborg is moving backwards for 100 milliseconds, allowing the while(b.is_pressed() {} loop to escape. After the button is released, dash() and dot() are called for. Dash makes the sciborg move backwards for 2 seconds, and dot() makes the sciborg turn around for 1 second. The void loop then starts over again, allowing the sciborg to move forward until the button is pressed.

 

In order to improve the sciborg’s ability to move around a space, we would need to position the sensor that it would be near the middle of the sciborg’s height, allowing it to hit lower and higher places. We would also need to optimize the code so that the sciborg is able to move completely straight after finishes turning. We ran into a few problems as the sensor getting knocked off because the button wasn’t touched, yet the side of it was. We could probably try to incorporate the sensor as part of the main body as well, so that there isn’t as much surface area exposed of its sides. We noticed that the walls bumping into the sides of the sensor often knocked the sensor off, and if we could get the sciborg to drive straight after it has backed up from the wall and turned, the sciborg would be less likely to get caught by the walls on its sides.

We will finally move on to feedback and control! Stay tuned for the upcoming project with encoders and more!