Posted on

Serris’ Status Update 2/29/20

  • 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
Posted on

Team Status Update for 2/22/20

  • Design Changes:
    • Decided on a Figure-8 track for our demo
      • 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
Posted on

Serris’ Status Update for 2/22/20

  • Debugging to get connection with NodeMCU
    • Server was not recognizing the board as an ESP8266 and couldn’t connect to the board to flash the firmware
    • Tried in Arduino IDE with the ESP8266 community board manager (also tried different versions)
    • Tried with other applications to flash firmware  (i.e. PyFlasher, Micropython) but was still timing out
    • Not working with motor controller so I tried uploading just basic code to the ESP8266 board
  • Thought it was a toolchain issue and started testing with different software tools
    • CP210x USB to UART bridge: tested the serial port with different versions to ensure tools were compatible
    • Since the board is made from Espressif System, tried their built-in toolchain (ESP8266_RTOS_SDK) but wasn’t working
  • New NodeMCU parts came and tested on those
    • Realized it was a chip issue and uploading code works fine now
    • Able to get code uploaded
    • Working on controlling motor direction and speed but running into inconsistencies
  • TODOs:
    • Finalize schematic between motors, ESP8266, L298N motor controller, battery
    • Control direction and speed
    • Connect and control through WiFi
Posted on

Kylee Status Update for 2/22

  • 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.
Posted on

Tito status update for 2/23

  • 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.
Posted on

Kylee Status Update for 2/15/20

  • Continued research on Intelligent Driving models
  • Refined demo idea from two lane circle to figure 8
  • Did calculations to determine sizes of track and lanes as well as the speed of vehicles.
  • Created and filled out design decision document
  • Wrote basic Arduino code to control the robotic cars through WiFi using the ESP8266
Posted on

Serris’ Status Update for 2/15/20

  • The parts we ordered last week came so I was able to start building our robot cars. We got 2 different frames (one with a chassis kit and one with individual parts); we wanted to compare the motors and movement of both builds. I built one car, connecting the NodeMCU and L293D IC motor controller.
  • Started coding in the Arduino IDE but my OS version was not compatible so I used the Beta version but it kepy crashing
  • I was able to get some motor functions but it was not consistent
  • Decided to look directly controlling the motors through MicroPython to skip the intermediate step
  • Installed the device drivers for the microcontrollers to be recognized
  • Running into issues connecting  to the correct serial port of my NodeMCU using MicroPython
  • Progress is as expected
Posted on

Team Status Update for 2/15/20

  • Created a table, listing all of our design decisions
    • For each decision, we specified why we chose it, alternatives we considered, why those wouldn’t work and how/why our solution is better
  • Did more research to figure out specifics of our implementation
    • Width and shape of our track given the dimensions and motions of our vehicles
  • As a team, we decided on how our cars would look like and what camera would be best for our project
  • Ordered our parts and starting to work on the hardware pieces that arrived
  • Our progress is what we expected to accomplish in the timeframe