top of page
Search
  • Writer's pictureAlex Janis

Week 8: A Barrel of Graphs

WobbleBot is having a few issues. Firstly, it keeps falling over. I tried to solve this issue by changing the number of washers between the screw and the motor. This helped. Secondly, it keeps turning. The program is supposed to change the speeds of the respective motors when it turns in order to keep it going straight, but, for some reason, it isn't working. I tried to solve this issue by changing the values of the speed multiplier. Thirdly, the batteries keep getting warm and the pi keeps shutting itself down. I tried using different batteries but this still didn't work.


Also, when I run the program, sometimes this error appears when the robot falls down: "IOError: [Errno 121] Remote I/O error". When this happens, the program quits, but the wheels keep turning. I do not know what the error message means, but it has to do with the read_data function. When I looked up the error, it suggested you use the "i2cdetect -y 1" command. When I do this, I get a grid like this:

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

I am unsure as to what that means. One suggestion says that this could be caused by faulty wires. I replaced the old wires with new ones and this error did not stop appearing. It seems that it only appears when the robot is running on the floor and falls over. When I moved the robot around in the air, the error never appeared. It didn't appear when I put the robot on the floor but use my hand to prevent it from falling. In one test run, I let the robot fall over and the error also didn't appear. I didn't know what was causing it.


The robot also began jittering as it moved. For some reason, the robot would turn to the left, jitter around a little, then fall forward. I tried using 3 washers instead of 1 or 2. The robot still fell forward, but it took longer. Adding a 4th washer makes the robot fall forward faster than before. I went back to the original 5 washers and the robot stopped falling forward, It was leaning backward a little, but I thought that is because the battery was being held on by some tape.


After reinforcing the tape, I decided to continue my attempts to make the robot move in a straight line. I varied the speed of motor 2 (as it seemed that it was going slower than motor 1) and the value of the multiplier (this would change how much the robot would correct when turning). The values that seemed to work best was adding 7 to motor 1's speed to find motor 2's speed and using 1.05 for the multiplier. These settings resulted in this very successful test:



This week we also finished the testing on the TorsoBot. All we needed to do was analyze our results and graph them in MatLab. I had never used MatLab before, so I went through the tutorial online and downloaded the software to practice. Within a few hours, I felt that I knew enough to start modifying the code. First, I had to reorganize the data spreadsheets to have a column with the kicker angle on them. Then I added a variable to the program called kicker_angle which made an array of those values. Next, I created a variable called kicker_angle_ave (ie average kicker angle). This variable found the average kicker angle for each trial. Then, I graphed the average speed against the average kicker angle and removed large outliers. Finally, I used the scatter3 function to plot the average kicker angle against the average speed against the average torso angle. This created a 3D graph. However, it was hard to distinguish the groups of kicker angles (as several data sets had the same kicker angle). So I graphed each set of kicker angles as a separate data set on the graph and changed the colors. This resulted in this 3D interactive graph:

This graph shows the colors of the different kicker angle data sets



In addition, we decided that we had collected enough data with the TorsoBot without the kicker. Our kicker data, as seen above, did not present a consistent pattern. For this reason, we wanted to collect more data on the robot. One of the other interns reprogrammed the robot's code with the kicker the day before, so I had to test it. It went fairly well and I discovered that it worked best with an angle less than 40 degrees. However, it still had problems. For some reason, after it stopped running, one of the servos would kick the leg. Even after shutting down the raspberry pi it continued to move. After I let it sit for awhile without power and retested, it seemed to stop doing that. But I still don't know what caused that. I tried changing how frequently the kicker activated because it seemed to be going to slow. It activated every two spokes when we needed it to be every spoke. This was an improvement.


Next week I will be focusing on finishing up the TorsoBot!


3 views0 comments

Recent Posts

See All

Week 9: Final Week

I began a new project of transferring Dr. Adamczyk's handwritten notes into a completely textual Pressbooks format. The notes contained...

Comments


Post: Blog2_Post
bottom of page