geezacoleman / OpenWeedLocator

An open-source, low-cost, image-based weed detection device for in-crop and fallow scenarios.
MIT License
342 stars 61 forks source link

logging causing substantial delay #114

Open geezacoleman opened 9 months ago

geezacoleman commented 9 months ago

Digging through the solenoid actuation code to try and improve speed, found that Line 143 of relay_control.py is causing a substantial delay.

Current line:

self.logger.log_line(line, verbose=False)

The way individual weeds and updates are logged currently is through the custom logger.py. It's a very inefficient way of doing it. Testing this section of code in owl.py it took on average ~10 ms to detect one weed, and over 400ms if there were at least 10 - 20 detections, effectively bogging down the code and reducing spot spraying performance.

# loop over the ID/weed centres from contours
startTime = time.time()
for ID, centre in enumerate(weedCentres):
    # if they are in activation region the spray them
    if centre[1] > self.yAct:
        sprayTime = time.time()
        for i in range(self.nozzleNum):
            # determine which lane needs to be activated
            if int(self.laneCoords[i]) <= centre[0] < int(self.laneCoords[i] + self.laneWidth):
                # log a spray job with the controller using the nozzle, delay, timestamp and spray duration
                # if GPS is used/speed control, delay can be updated automatically based on forward speed
                self.controller.receive(nozzle=i, delay=delay, timeStamp=sprayTime, duration=sprayDur)

endTime = time.time()
elapsedTimeMs = (endTime - startTime) * 1000
self.processingTimes.append(elapsedTimeMs)

if len(self.processingTimes) > 10:
    self.processingTimes.pop(0)  # remove the oldest number
rollingAverage = sum(self.processingTimes) / len(self.processingTimes)

Workaround

Deleting this line entirely from relay_control.py solves the problem but it means individual detections won't be logged.

Longer term solution

Replace all logging with the python logging module. Testing this method increased processing time above deleting the line entirely but even with many detections processing time remained below 1ms.

Issue first raised in Issue #100