Based on Wednesday Meeting, we decide to change our whole system design into a P2P Blimp-Laptop version, so that all controlling process happens on the ground i.e on the laptop. And blimp system is only for (1) get and send sensing data (2) receive laptop processed motor directives (3) control motor based on received motor directives.

The one that we debugged last night:

The advantage with this system design are:

1. all control code on the laptop can be written with python, instead of C
2. field testing and debugging process becomes quick, as can all of the control logic happens on the laptop

What we have achieved for (10/22/2021 2:51PM):

1. Seek and Catch Green Ball Capability Achieved (tested on blimp)
2. MoveToGoal Code Written (to be tested on blimp)

Update: What we have achieved for (10/23/2021 1:44PM):

1. MoveToGoal Code Capability Achieved (tested on blimp)

   --> this means all 3 capabilities (seek, move2ball, move2goal) are prove to run intergratedly and smoothly on the blimp system. all remaining are fine tuning.

   --> refer to Zhaoliang next blog post for the video and details

P2P Blimp-Laptop I/O

The current version modularized P2P Blimp-Laptop I/O is the following diagram:

LapTop Input-Control-Output pipeline

In our main.py, for every "loop forever" iteration ( takes 0.05 seconds, defined by waitTime), we finish one Input-Control-Output pipline:

1. Taking input:

   • (C) ESP32Cam HotSpot --> (python) read at local IP --> feed into Pytorch Green ball dectection model --> receive gbx, gby, and area
   • (C) ESP32_Master conducts serial port print of what's coming from ESP32_Slave, with line SERIAL_IN_START as where to start reading_ --> (Python) always read every line at the laptop-ESP32 port --> whenever detect SERIAL_IN_START, read next 8 line. Each are tx, ty, tz, rx, ry, rz, LIDAR_dist, and debugM

   Note:

   • (A bug that bothered us, now fixed) To avoid lagging, delay(50) should be there in ESP32_Slave, and the serial_port_in and serial_port_out() must sync in time--> ([Update on 10/23/2022 1:42PM] for more details, please refer to the integrated blog post to see the resulthow Zhaoliang and I solved this issue.)
   • To make ESP32_SLAVE talks first. In main.py, right before while Ture:, we need to one serial_port_out call on ESP32_Master first, to trigger ESP32_Slave to talk.

2. Feed input to control, and do the control:

   There is a big block of function called main_control(...) whose IO are

   pwm1, pwm2, pwm3, pwm4, dir1, dir2, dir3, dir4 = main_control(gbx, gby, gb_dist, tx, ty, tz, rx, ry, rz, LIDAR_dist, debugM)

   It takes all input, and outputs motor actions

   In this function, it contains THE control logic of blimps strategy.

   Note:

   1. This entire part can be written entirely using Python.
   2. main_control(...) has it own submodules for different actions. They are:
      • seeking(), Code: DONE, bug-free | Test on Blimp: DONE
      • move2ball(), Code: DONE, bug-free | Test on Blimp: DONE ---> Check the video
      • ----- **Update on 10/23/2021 1:44AM ------
      • move2goal(), Code: DONE, bug-free | Test on Blimp: DONE ---> refer to Zhaoliang next blog post for the video and details

3. Feeding output:

   • (python) we format the pwm1, pwm2, pwm3, pwm4, dir1, dir2, dir3, dir4 in string --> we write it to the serial port --> (C) ESP32_Master interprets it and send to ESP32_Slave

   Note: the format is pwm1, pwm2, pwm3, pwm4 each takes 3 position, and dir1, dir2, dir3, dir4 each take on position

   • 1, 22, 333, 444, +, +, -, - -------> b'001022333444++--'

Video

Thursday night flying test:

After we fixed the green ball feedback control delay bug:

Next Post Previous Post