Month: February 2022

This week, my main focus is expanding our efforts on the arduino, and providing an arduino script that would be controlled using serial communication with python script. The system works well with a single sensor single vibration unit model, I was able to control the vibration and the on and off of the sensors through writing serial messages to the arduino. Furthermore, I was able to write a basic python script, that would communicate with the arduino to turn on the vibration unit whenever the sensors senses object <30cm, and turn off otherwise. We ran the script on raspberry pi and it worked well. I also tested connection and controlling multiple sensors with the same trigger pin, and it also worked.

One particular challenge I noticed was using pulseIn to receive multiple sensor information at the same time. In which I will have to read the source code and implement my own pulseIn

Next week, I will be increasing the scale of the arduino system to include all sensors and vibration units.

This week, I focused on working with the integration of OAK-D depth camera and the Raspberry Pi. We have successfully connected the Raspberry Pi to CMU-DEVICE and installed proper environment to run sample scripts from OAK-D documentation.

Next week my work will focus on finding appropriate NN model for the OAK-D camera as well as explore the necessity of running the system in headless/standalone mode.

This week we made the milestone of successful integration of our sensors, actuator, and controller boards. The system is minimally functional in that

• raspberry pi can take in data from depth camera
• Arduino can make the coin motor vibrate with different intensities given multiple ultrasonic sensor reading
• through serial communication, raspberry pi can send Arduino control data while Arduino can send raspberry pi sensor data

Next week, we will look into belt design, plan out more details in our design report, and do more system integration and algorithmic modeling incorporates different data cohesively.

 

This week I mostly worked with Ning on Raspberry Pi integration with the Oak-D depth camera.  We first successfully registered our Raspberry Pi as a CMU device and managed to SSH into it from laptop, then downloaded all the Oak-D dependencies to run its “Hello world” script and was able to activate the camera and take in data with Raspberry Pi. I also started integrating oak-d skeleton code to the raspberry pi main file. Meanwhile, Alex helped me set up VS Code ssh integration to allow a smooth experience with editing Raspberry Pi files.

Next week, I will further integrate Oak-D pipeline into the raspberry pi main and look into belt design with the team.

This week my work is mainly on learning to work with the Luxonis OAK-D depth camera. I have successfully run a program of object detection with pre-existing NN models (on my PC; re-establishment of the proper environment on the Raspberry Pi is expected). I also worked on the initialization of Raspberry Pi 4 with Kelton and discussed the block diagram of our system with the team.

Next week my work will be focused on finding (or possibly designing) appropriate algorithms for our purpose, as well as integrating the OAK-D depth camera with Raspberry Pi.

This week, we reviewed our design process, and tested on an order of items that we received. The main progress includes the following:

Through talking to professor Gary and TA Joseph, we have added the use of arduino uno into our project. We will be using the arduino board to control both the ultrasonic sensors and the vibration motor disks. The updated design can be seen in the design review presentation, in which we will provide a detailed design on what our block diagram is now.

We have been able to test with both a single ultrasonic sensor and a single vibration motor disk with the arduino.  We have found that the sensor we have purchased seems to work best within a 4 meter range. We did some real life testing with walking obstacles, and concluded that 4 meters is a reasonable range for our product. The vibration disks can operate from 2.2v to 3.8 volts, providing different levels of vibration. We tested with 3 levels of vibration using PWM pins on the arduino board, and we can make clear distinctions between the different levels of feedback. We therefore believe that this is enough for our users to receive different information on the level of threat present.

Setting up the main OS and testing the raspberry pi4. We were able to install the raspberry pi OS and test out its basic functionalities, mostly revolving around building python scripts needed. We also tested the serial communication between the raspberry pi and arduino. On a side note, when we were working with the raspberry pi4 in lab 1304, we were unable to properly connect the device to open network using CMU or CMU-DEVICE. For some reason, the internet always redirects us to the CMU-IT service network and we can’t navigate to outside networks such as google or Github, next week we will try to set up the environment with a home wifi instead.

We also did some basic video processing test with the OAK-D camera to see that it operates correctly. Ning Cao have been looking through the documentation to find out how we can best use the existing camera modules and processing power to our benefit

Overall, we have been focused on a proof of concept test this week to make sure that we have chosen the correct components and our general design idea can be achieved with what we have. We are in schedule as we have finished most of our setups and unit testing according to plan. Next week, we will be mainly working in three areas: sensor and vibration disk control with arduino(Xiaoran), raspberry pi integration(Kelton), OAK-D camera integration(Ning). Our individual reports will further illustrate our plans.

 

 

 

 

 

 

This week I was focused on testing and integrating Arduino with the HC-SR04 ultrasonic sensor and the vibration motor.

From the ultrasonic sensor test, I got a sense of the frequency and format of the collected data  and decided that it is feasible to process the data points with methods like moving average to adjust data rate as to suit transmission to Raspberry Pi while discovering that our original range specified in quantitative requirement has to be reduced from 5m to 4m due to the sensor’s tested accuracy. The sensor can provide feedback at a rate of more than 100hz, which is way more than what we need(our team will likely work with 20hz or 30hz). Furthermore, I tested the connection with 3 different sensors at the same time with a motherboard, and the connection is able to process data from all 3 sensors according to will, which proves that our original design with multiple sensor is feasible.

Meanwhile, for the vibration motor, I was able to control its vibration intensity with Arduino’s analog pin which is otherwise not feasible with Raspberry Pi. I tested runing several different disks with different intensity at the same time, and it was sucessful.

Another concern that was addressed this week was the pin assignment for the arduino UNO. We were originally woried that the UNO will be insufficient for our number of sensors and disk motors, but after examining the size of the motors and sensors, we have decided to limit the number of sensors used to 6 maximum. In which case, we will need 1 DIGITAL for sensor control(we operate all 6 sensors at the same time), 6 DIGITAL PINS for sensor feedback, 6 PWM pins for vibration motor control, which is exaclty the number of digital pins provided by the UNO model. Thus we will be sticking with the arduino UNO board.

Next week, I will integrate the control interface for multiple sensors and vibration motors in arduino. Further more, I will work with Kelton to implement a basic control script in python to run the sensors and vibration disk through communication between the raspberry pi and arduino.

This week my work is centered around reviewing our design and checking if any technical incompatibility arises while building.

First, I drew the detailed block diagram, incorporated our revised requirements and designs based on TA and professor feedback (e.g. using Arduino to gather sensor data and control vibration motor while using Raspberry Pi for depth camera and control logic) into the design review slides. Then to verify design with the newly arrived parts, I helped Alex with how to test HC-SR04 ultrasonic sensor with Arduino and set up Raspberry Pi with help from Ning.

Next week, I will work on connecting Raspberry Pi online to test its integration with Arduino and the Oak-D depth camera.

This week, apart from peer-reviewing other projects and deciding the proper items to purchase, I’ve looked at tutorials for Raspberry Pi, primarily with regards to how to communicate with I2C and GPIO interfaces.

This week, I have primarily been involved in deciding with the team what to purchase, and studying the OAK-D depth sensor camera modules online. We will be using the camera to process ground level information, and I am looking into online resources to help us utilize its functions