Monday, March 7, 2016

Sciborgs Part 1

Day 12 (3/4/16)

Today we started out talking about robots and types of feedback and control.

Robots are not actually specifically defined, but they are mechanical devices that serves a purpose or purposes. The specific kind of robot we will be using for this project are called sciborgs. Sciborgs are robots made from lego pieces and motors and ours are controlled by an Arduino with a Bricktronics Shield. Ours looks like this:


Besides talking about robots and sciborgs, we also talked about different kinds of feedback and control. Feedback and control systems use a combination of sensing (measuring something), computation (taking the data and doing something), and actuation (something mechanical that moves). There are open loops that try to accomplish tasks but do not confirm or deny its completion, there are bang bang loops that either turn something on or off, and there are proportional integral derivative loops (PID) that have complicated feedback and control. Some examples of feedback and control systems are thermostats, automatic doors, and cars. Our sciborg will eventually become a feedback and control system that will be controlled by the Arduino.

After talking about sciborgs, Nanaki and I started practicing making functions in our code. The point of functions are so that you don't have to write the code directly each time. You can set up your code so that you only have to write it once and you can call the function elsewhere in your code to perform its task. We practiced with the LED and dot and dash functions to represent morse code. Here is what our functions looked like:



After we got comfortable using functions in the Arduino, we set up our sciborg by attaching the Arduino and Bricktronics Shield and plugging in the cables.

The first task we had to do with our sciborg was to make a single motor run. All we had to do was download the "single motor" example, learn what it did and run it. This part was simple. The motor was turned on at high power, then low power, then high power reverse and finally low power reverse and just repeated that pattern.

Task 1:

The trickier task was getting both motors to run at the same time. We ran in to issues with this portion. At first we thought that our code was wrong, but what I realized eventually was that the Bricktronics shield was not completely plugged in to the Arduino, so the connection was bad and the sciborg was not doing the tasks we wanted it to do. Ultimately, our original idea for the code was correct and we were able to get both motors moving. Here is what the code looked like:



And here is what the sciborg did as a result:





Task 2:

After we were able to get both motors moving at the same time and at the same speed, we were tasked with figuring out what the minimum speed was that allowed our sciborg to move. To do this, we used the "Both_Motors" code with just one section of the fixed drive commands for both motors. We used trial and error and plugged in different numbers until we got our results. It turns out that when you are holding the sciborg, the motors will spin the wheels (just barely) when the speed is set to 47. When the sciborg is on the table, it will move at a minimum speed of 66.

Task 3:

The next task was to have the sciborg make a sharp turn. This was done by setting one of the motors at full speed forward and the other motor full speed backwards. This causes the sciborg to turn around very tightly. Our code for this was essentially the same as our code for both motors with just the one section like we used to find the minimum speeds. This time, however, the speeds of each motor were different. Here is what the code looked like:



Here is what the sciborg did as a result of uploading this code to the Arduino:




Task 4: 

Our next task was to make the Arduino turn more gently. This time instead of setting both motors as complete opposites, we decided to set one motor to full power forward and one motor to medium power forward. Here is what our code looked like. As you can see it is almost identical to the code for the sharp turn:


Here is how our sciborg reacted with the specified directions:



Task 5:

Our final task was to see how long it took our sciborg to move 10 feet. We laid down two pieces of tape on the lab-room floor that were ten feet apart, set both motors to full power with no delay and timed it. Our sciborg took about 12 seconds to cross from one piece of tape to the other.

Our next job was then to program the sciborg to move at full speed for just 12 seconds and then stop. Here is what the code looked like for that:


Here is how the code worked when used by the sciborg:


Ultimately, the sciborg did not make it all the way to the tape in the 12 seconds that we thought it should. This is likely due to several reasons. First, when we timed the sciborg going from one piece of tape to the other, it is most likely that it did not take 12 seconds exactly. There is human inaccuracy when timing objects. Also, the sciborg did not travel in a straight line, and sometimes the motors would almost seem to catch. Each run was different, so there could be an error of +- 2 seconds for the time it takes the sciborg to make it 10 feet. There is no way we could make the sciborg stop exactly on the line when just using a time dependence (maybe using sensors?).

1 comment:

  1. The pattern of your comments is methodical and therefore very clear and easy to follow. However, when you mentioned how the fact that the bricktronics shield connection was what was causing the code not the work, you should have extended this to a brief discussion on the challenges of defining a clear process/methodology during engineering tasks.

    ReplyDelete