Server Classes
Proxymow
Proxymow is the main class that does the heavy lifting for the server:
- implements the web server
- handles api requests
- communicates with the robot mower
- controls mowing operations
- hosts the virtual mower and virtual camera
- controls access to the shared camera
- processes operational instructions
Web Server
The user interface is a combination of:
- html/svg pages based on jinja2 templates
- jpeg images for various views of the lawn
- json metadata enabling features to display and synchronise their images and data
Html Templates
If no matching http route method exists, then Proxymow checks if the requested http route should be serviced with a template, or an api handler, in its default() method. If the http route resolves to a folder, and the folder contains an index.html file, then this file is rendered. This is how help files are served.
Model Context
The model_context module has a function matching each http route. Their job is to assemble data for the template. Global data is available to every template, and parent data is available to nested templates.
APIs
Proxymow hosts 2 apis: API and XAPI. API handles requests for current operations, whilst XAPI handles requests for the entire configuration.
Robot Communications
Communications with the robot mower are implemented with UDP packets via sockets. As the vision system knows where the robot is at all times, then we can afford to use a fire and get approach when sending commands. If our request is not received and acted upon, then in general it will just be resent.
Mowing Operations
Mowing operations are controlled by the governor() method which runs in its own thread. Here is a flowchart:
Virtual Mower
The proxymow ecosystem requires quite a lot of effort to set up. Cameras need to be installed, robots need to assembled, networks needs to be established, navigation strategies and mowing patterns need to be selected. The virtual mower, and the virtual camera, are facilities that provide stepping stones for testing some parts before other parts are available.
The virtual mower is a robot existing purely in software. This enables various aspects of the ecosystem to be tested, before a physical robot is available.
Likewise, the virtual camera simulates the image that a real camera would provide. The following table illustrates the steps that could be followed to get started.
| Step | Platform | Camera | Mower |
|---|---|---|---|
| 1 | Windows PC | Virtual Camera | Virtual Mower |
| 2 | Windows PC | Webcam | Virtual Mower |
| 3 | Windows PC | Virtual Camera | Hybrid Mower* |
| 4 | Raspberry Pi | Virtual Camera | Virtual Mower |
| 5 | Raspberry Pi | Virtual Camera | Hybrid Mower |
| 6 | Raspberry Pi | RPi Camera | Robot Mower |
* The hybrid mower is just a bare device (EPS8266\Rpi Pico) running the Proxymow Mower Micropython software. It computes and maintains its own position, and makes this available to the Proxymow Server in lieu of a robot pose calculated from a real camera image.
Shared Camera Access
In general a Raspberry Pi can only support a single camera. Therefore a methodology is required to allow this camera to deliver images to the governor controlling operations, and simultaneously other client processes like the vision feature, etc..
Proxymow implements a queueing system process_images() running in its own thread. Requests are placed on the input queue, and images are placed on one of a range of output queues. This enables the camera to be setup with different configurations, depending on the client request.
Instruction Processing
The server has an instruction processing method process_instructions(). This deals with various requests to start driving a route, set mower speeds, cancel or pause driving, etc.
Config
The Config class maintains a database of the configuration i.e. profile, mower, navigation strategy, etc. When the server is started, the configuration is read from an xml file (configs/config.xml), parsed and stored as key value pairs in an internal dictionary. The configuration is periodically written back to file in case of server failure.
It may be wise to make backups of the config.xml file, either automatically in a crontab job or manually. If detailed Fence adjustments are made, then these can be lost if the server suffers catastrophic failure.
For a multiple Proxymow-Server network then it may be worth considering maintaining a central config.xml file.