Started codebase for detection and path planning integration
Created classes for vehicle and track info
Worked on design report
TODO
Implement scheduling algorithm to ensure fairness
Just going to be keeping a counter for how long car is waiting without progress. System will choose the vehicle that has been waiting the longest to pass through the center lane
Test vehicles to correlate numerical values that we use to program the motors with actual speeds in cm/sec
figured out motor inconsistency was due to power issue
need to figure out how much power (v & i) the nodemcu needs to power the logic board and also be able to supply power for the motors
started testing wifi connection with python server
was able to send one message from python server to nodemcu’s builtin led light
tested latency and experimented on how to improve it
able to send multiple bytes in less than 1s to nodemcu (previous tests used strings and took ~6s to send)
experimented with simple socket server system with one server and 2 clients
designed communication structure and decided to send messages to clients separately as opposed to broadcasting to reduce amount of data being sent at a time
was able to send different messages to different clients
worked on design report
progress is on track
will continue to work on power issue and test cars
will soon test sending messages through socket server to cars to move motors
Simplified path planning – in this case, each set of vehicles are in their own track and only need to worry about starting or stopping
Added a L298N motor controller board for each vehicle in order to safely power the motors and NodeMCU chip
Adds a little extra cost to each vehicle but still under budget
Challenges:
NodeMCU ESP8266 chip posed major connectivity issues whenever we tried to upload code.
Everyone helped debug with different software tools, using different cables, different drivers, version of Arduino IDE and of esptool, etc.
Researched on alternative Wifi modules for project
Finally, ordered new NodeMCUs from another manufacturer and it worked
Programming the motors through the NodeMCU and motor controller board
Early tests have shown an unpredictability in controlling the vehicles. Some behaviors are unexpected or not exactly as programmed.
Still able to get metrics such as speed and stopping distance though
ArUco takes longer computation time when the tags are smaller
We determined the max size of our tags to be 5 in. x 5 in. Therefore, in order to meet the latency requirements of 200ms and to also keep the entire track within the field of view of the camera, the height placement of the camera is extremely important
A proposed workaround is having the camera placed at an angle instead of directly overhead the track. This would allow the tags to appear larger in the frames
We would need to perform some image warping, however, to get an accurate estimation at the vehicles’ positions.
Video frames of moving tags might be much lower resolution than pictures
ArUco marker detection is performing very well so far in preliminary tests of images of printed tags, but still unclear how its performance may change when using the video camera
Accomplishments:
Finalized implementation plan by defining metrics
Chose track size
Determined height of the camera above the track
Collected rough estimates of computation time of object detection algorithms
Figured out the accuracy of object detection framework for our problem setting
Collaborated with team to find alternatives and solutions for NodeMCU struggles. Settled on buying the boards from another manufacturer and that seemed to work.
Created a metrics document for the driver model
This related the vehicle speeds and the various distances the vehicle would travel in case it needed to come to a stop
Used the metrics to determine the size of our track
# of cars * (Total following distance between cars + Length of cars) = Circumference of one track
Performed tests with the vehicles in order to determine max vehicle speed and also a stopping distance
Worked on design review presentation slides
Slightly behind schedule with regards to the path planning algorithms. The major roadblock with the NodeMCUs and the construction of our vehicles was necessary to overcome in lieu of the design presentation (needed numbers for our presentation)
TODOs:
Need to do more research and start the codebase for the path planning
Non-cooperative case does not seem too challenging, but need to find a good solution for the cooperative case.
Collaborated with team to figure out the problem with the NodeMcus. Tried programming the NodeMcu via Platformio instead of the arduino ide to see if the problem was a software issue. It wasn’t
Tested object detection algorithm for accuracy and speed. Recorded worst-case metrics to use for the design of our pipeline.
Experimented with various setups/conditions such as number of cars the algorithm is able to detect within one frame and the height above the track with which the algorithm could still accurately identify the cars.
Camera and mount came in so put together the mount and set it up with the camera to demo and test the performance of the set up. (i.e test the resolution of the camera and how well it detects the markers/ the optimal height of the camera above the track
Simulate blurry frames (due to the motion of the cars) and test accuracy of the object detection mechanism under sub-optimal conditions.
