During April I spent my time trying to improve the accuracy and speed of the decisions that the robot makes. I looked for different ways to speed up a python program. I found two different modules that would help to speed up the program in different ways: multithreading and multiprocessing. Multithreading allows you to essentially pop in and out of subprograms at a faster rate without losing your spot. Multiprocessing allows two different scripts to run at the same time. I decided to go with multiprocessing because my program was already going in and out of subroutines, the robot movement caused rapidly changing data from the LIDAR and running two separate subroutines at the same time seemed to be more beneficial.
My robot kept on randomly shutting off and on. If it would not come back on, I gave it a little shake and then the power would come back on. As a result, I thought that it was because one of the connections was loose. After inspecting all the connections, I determined that it was the connection coming from the battery into the input of the DC-to-DC converter. I added a larger connector onto the end of the wire to give the clamp more material to grab onto. After I fixed the wire, I began to run into problems when interfacing to the Raspberry Pi. The Raspberry Pi kept on experiencing brown outs and would randomly stop receiving power from the DC-to-DC converter. I tried to use my oscilloscope, but it did not really help identify the problem. I then tried a second Raspberry Pi and the same issues occurred. I then validated the Raspberry Pi’s by ensuring that they still booted up properly when connected to a AC-to-DC power converter from the wall power outlet. Based upon this I surmised that the DC-to-DC converter was having problems keeping up with the amount of current that I was needing to run all my devices. Therefore, I ended up getting a new DC-to-DC converter that could better handle the amount of current required, the only downside is that the new DC-to-DC converter cannot do different output voltages where the old one could. This was not a problem for this project as I only require 5.1V. In May I am hoping to finish my robot by getting the multiprocessing completed.
0 Comments
During March I spent most of my time programming the LIDAR which directs my robot’s movement.
I ran into some troubles with finding a module that could communicate with the LIDAR. I needed to read commands from the LIDAR, then go do another task and then come back into the LIDAR module to give it the correct start bytes so that I could gather another set of data points. I needed to be able to remain connected with the LIDAR. I ended up trying three different modules and finally found one that allowed me to run it once, exit the function, run other code and then re-enter the LIDAR statement without running into connectivity problems. I could not just gather data all the time. I have to gather a certain set of data points, do calculations with them, decide what to do with robot movement and then start over gathering more data points. After I gathered the data points I needed to establish at what angle and distance objects were from the LIDAR mounted on the robot. It was challenging to convince the Python code to make arrays instead of lists. If the data was in a list form it was non-iterable and therefore a “for” statement could not be used to run through all of the data points quickly to divide them into their appropriate categories. I spent a lot of time trying to get the Python code to append the correct data points into the correct format in an array. I wanted the data points in a numpy array. Numpy arrays allow more mathematical calculations and resizing to be done than just a regular Python array or list. This took a lot of iterations to successfully store the data, retrieve and work with it, and get it into a format that I could use successfully and quickly. Getting the Raspberry Pi 4 to connect to the Arduino was quite easy. All that was required was a USB cable and a module that allowed the Pi to read the serial print screen of the Arduino. After completing both of these tasks I was able to do some math that allowed the LIDAR to be able to do basic scanning to move. There are still a lot of problems with turning. I am having a problem trying to get it to turn while trying to read the sensors. This is because it is in two different def statements and they can’t be run at the same time due to the fact that there are timing issues with the LIDAR. This is causing me to go through a lot of iterations to try to get something that will allow the robot to turn when the LIDAR senses something in front of it. It just occurred to me that I have not explained what all the pieces do. The LIDAR hardware, using a laser, determines what is around my robot and where by triangulating the position. The Raspberry Pi 4 does all of the mathematical calculations to establish where things are and then tells the Arduino where to move the robot. The Arduino controls the H-Bridge, using the data from the Raspberry Pi 4. It gets the H-Bridge to turn the motors depending upon where the Raspberry Pi 4 wants the Arduino to direct the robot. The DC to DC converter steps the voltage from the 12V battery down to what the Raspberry Pi 4 and Arduino needs so they don’t blow up. The motors to turn the two wheels need the 12V straight up. I currently can move the robot around, sort of, but I need to fine tune it a lot to get it to perform the way I would like. This is going to require a lot of programming to get it to function in the manner that I had envisioned. I have also noticed that some of the connections are faulty. I need to take apart the robot and redo some of the wiring. Of note, I have successfully run my mother over with the robot. No one was injured. Everything is a bit different this year. Thankfully, because I do enjoy it, Mech is still running. For me, as a grade 12 student, Mech is in the form of Special Projects 30, where you plan your own project. I was disappointed that only two other people were participating in Special Projects.
I had to think hard about what I wanted to do for a project. I didn’t want anything too simple, as I wanted to be challenged by whatever I chose to do. I also didn’t want to pick something that was impossible for me to complete in the one semester we have to work on and complete our Special Project. While looking for a project idea I found a LIDAR sensor. This sensor really intrigued me and I wanted to learn more about it. LIDAR sensors are used to find the distance of an object in a given range. In industry it is commonly used in self driving cars, 3D scanners, vacuum robots and things like that. I decided I would try to make my own robot using the LIDAR sensor to drive and maneuver it without hitting other objects. I first started by looking for a robot design on Thingiverse that I could use on my project. I am not the best at using CAD software, and wanted to focus on the LIDAR software. So, I looked for a robot that would work for my project that someone had already designed. I just had to purchase the necessary parts like motors and wheels and then I was able to 3D print the rest of the components to build the robot. I wanted as much time as possible to program. Building the robot itself went well. It was done rapidly after all of the parts were 3D printed and I acquired all of the stock components. During the build I noticed that the robot was not level due to the fact that the back of the robot was higher than the front. To make steering and maneuverability easier I am using two wheels and one ball bearing, they are different heights. This caused a problem for me. Even with adding an extra plate for the ball bearing at the back of the robot, the tires were higher and caused the robot to be sloped. This difference causes issues with the LIDAR sensor, as it is at a slant, causing discrepancies in the readings. To solve this, I purchased a second set of wheels that were larger leveling out the top of the robot. After ensuring that the motors worked with my H-bridge and Arduino nano I turned my focus to working with the Raspberry Pi and my LIDAR sensor. The first third party software module for running the LIDAR that I found was from AdaFruit. As soon as I began changing AdaFruit’s code to put more time between each reading the LIDAR would stop working as it was not receiving the start bytes at the correct time. I ended up switching to a different software module that allowed me to run the module once, do data calculations and then run it again. I still had a problem with the start byte error if I tried to do the data calculations within the same function that gathered the LIDAR data. I struggled with how to review the data and keep the LIDAR running properly. I noticed that if waited to review the data outside of the loop gathering the LIDAR data the start byte error went away. I then put my data into a separate list and performed the data calculations outside of the data gathering software module. My next step to take is to learn how to read the data and then determine where objects are based upon this data. This will allow the robot to know in what direction it needs to move in. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
April 2021
Categories |