• forces full rebuild if changed

• need to send frame from server to client (right now one-way traffic)
• perhaps add/start another thread in run method which has client listening for traffic from server
  • client-side recv should have another callback which stores the "current" frame
  • like is already being done, the backend code can add a route which when GET requested returns the most recent frame

• if I run python code first, they work fine when i run my code...

• client should be able to connect whenever while server should be system proc

• already handled in comments
  i.e.: Networking, I2C address, Web app, Camera

https://answers.opencv.org/question/197414/sendreceive-vector-mat-over-socket-cc/

• already have api to make camera loop, but not actually grab frames
• setShouldRecord()

• allows testing of UI key listener
• allows resiliency if server not immediately available

• see branch feat/network/server-to-client-23
• create and set a checksum but not using it ....
• split up compilation into smaller libraries (i.e. high & low level) so that changes to client/server dont recompile base & packet
• currently limited to packets of size uint32_t (which is large = 4,294,967,296B = 4.294,967,296GB) but theoretically can have more data then this (not likely)
  • consider upgrading to uint64_t which has max value of 18,446,744,073,709,551,615B = 18,446,744.073TB = basically infinite)
• server -> client "camera pkts" should contain more than just the camera stream
  • add fps, frame width/height
    • camera class should have getters (and setters?) for these values
    • use getters in setGrabCallback() in main to set in Camera packet
  • would need to split camera frame into uchar buffer & its size so client know how to split data accordingly
  • allow for more unseen future data to be easily added
    • i.e. battery, distance(ultrasonic sensor), etc
  • would need to create a client recv callback to handle the interpretation of the packet

• use case: net_agent run function takes bool for printing

1. move forward until too close to obstacle
2. sweep camera/ultrasonic servos back and forth until find free path forward
3. turn in that direction (might need to add static pivot to motor)
4. repeat from step 1

• use a callback (more versatile and reusable for other projects)
• should accept char buffer or opencv image object
• tcp server should set the callback such that it can send the frame to the client

• either burn distance into video frame or display on website
• if display on website, need to change networking code
  • possibly add another socket for server data

• test loop (one at a time):
  • swing left right (reset mid)
  • swing up down (reset mid)
  • move both at same time
  • have servo move to specific location once (or a couple locations)
• server functionality: arrow keys should increment position a tiny bit each sec pressed
• add slider or +/- button to change the servo's increment speed

• Some are already installed: wiringpi
• i.e. CLI11, pistache, raspicam
• hard to then collect and package
• make it so compiled code does not expect these compiled static libraries to be local

• can read in an already saved jpg image and try to route it