GitHub: https://github.com/MAE156B-AFSTeam/Aerial-Farming-System

Firmware

The Farmduino itself is controlled by the Farmduino Firmware. This firmware includes roughly 90 files whose purpose is to accept G/F-code instruction from the Raspberry Pi, and output the necessary motor movement to accomplish the codes. The original firmware is constructed for independent movement of the X/Y/Z motors, while the second X motor does the inverse of the first. Our edited firmware restructures this so that all 4 motors may be independently called (now called X/E/Y/Z motors) and utilized. While more-or-less all files in the firmware have been edited, there are a few files key for understanding.

The first important file is the Config.h file. This file includes communications statements, but more importantly it includes variables for system operation. These include motor currents, bounds, speeds, enablement, and so forth, and also static dimensions of the system used for movement logic. This file is what is referenced in the web-app when changing system parameters. The ParameterList.cpp/h files are ID’s which refer to these configs. The pins.h file contains the pin numbers for Farmduino connected items, most importantly the motors, encoders, and the UTM itself.

Next there are the CurrentState.cpp/h files. These files store info on the current position and status of the system. Movement logic pulls values from this file, whose purpose is essentially to keep track of where the system is, and what input information is transmitted over the serial monitor.

Penultimately there are the Movement.cpp/h files, and the MovementAxis.cpp/h files. While these files control much of what happens, there is little necessary to be understood here. These files control the movement behavior as well as the movement command. First, necessary steps are loaded such as the movement speed, the movement direction, and so forth, then the moveToCoords() command is called. This command takes in the x/y/z position, movement speed, and homing boolean (false when not homing, true when so), then prepares and initiates motor movement.

Ultimately, and most importantly, there are the G/F-code handler files. These files are the link between inputting G-commands and outputting a call to the moveToCoords() command. The G-codes are movement commands, while the F-codes are movement commands coupled with function commands such as water for X amount of time, or moving to the tool-tray location to pick up a new toolhead. The G-codes include G00 (straight line movement) and G28 (homing).

Integration between Firmware and Positioning

The presently written firmware is, barring unforeseen problems, functionally complete. The firmware is ready to accept new movement logic and transform that into movement behavior through all 4 motors. What is incomplete in these files then, are the G/F-code handlers. Present progress hasn’t resulted in finalized edited code handlers which output accurate movement, though they are ready to accept new logic and control all motors.

When the independent positioning sketch is complete, this logic will have to be transferred to these handlers. The positioning sketch itself should be used as a vehicle for testing variables which alter movement accuracy. These variables include, yet are most likely not limited to: Change of wire length due to slack, helical pattern of wire wrap around the spool, and increasing circumference of spools as more wire wraps around them. Movement is based on moving towards inputted values, so so long as the code handlers are edited to calculate the correct input values for cable-driven movement, the correct behavior will result.

Integration from Firmware to Web App

Homing

Homing is essential to proper positioning of the end-effector, as it sets the initial values of the wire lengths for movement calculations. Homing was not finalized within the scope of this project, but a proposed mechanism is outlined.

As stated before, the G-handler for homing is G28. Within a cartesian system, this handler has a simple job. It runs each motor toward the home direction until the motors slip, and then establishes this position as (0,0,0). A cable-driven system may in principle employ this same process, with complications.

A logical place to store the end effector as home is directly at one post column, whether at the top of it or at the bottom. The top makes better sense operationally, yet has the downside that it requires holding force to remain. Depending on the coordinate configuration, this point may be written as (0,0,0) or (0,0,Post_Height) in Cartesian coordinates. Along with these coordinates, the cable lengths must as well be stored as a 4 item array. Movement in a cable system is of course dependent on modifying the cable lengths, so initializing the correct initial lengths is crucial to accurate movement. Movement is of the style that motors move until an initial rope length configuration (t,u,v,w) reaches the desired configuration (t’,u’,v’,w’).

The physical process may remain roughly the same. One motor may be spooled in until that corner of the end effector is in contact with the pulley. The rope length for this motor may be called 0. From here, the other motors shall be spooled in until they are taut. Two of the other cable lengths may be called the interpostal side-length, while the last is the interpostal diagonal-length.

This homing procedure is subject to sources of error which should be mitigated. First off, the position of the end effector is the center of the UTM-plate, while this homing procedure touches the edge of the plate to the pulley, leaving a gap of roughly half the UTM-plate’s width which must be accounted for. Secondly, It’s unlikely that the fitment of the UTM-plate into the frame’s corner is square, or that the frame itself is plumb, leading to inaccuracy. Most significantly, the ropes themselves will have some level of slack to them, outside of the totally reeled-in post. The slack adds additional length which can be calculated by Pythagorean theorem.

Homing is crucial to accurate positioning of the end-effector, as movement is based on distance from where home is thought to be, not the absolute distance from some theoretical point. Improvements to the G00 handler should be made in tandem with the G28 handler, as the inaccuracy of the former builds upon the inaccuracy of the latter.

Independent Positioning Sketches

An independent positioning sketch was developed in response to the inability to achieve necessary movement behavior through solely editing the firmware. The purpose of this movement sketch was to demonstrate the ability to move motors concurrently to allow for smooth vertical spooling and unspooling of the UTM system.

A chief difference between this independent sketch and the posited firmware code is the order of movement. Within the firmware, a desired location is meant to be calculated as a set of wire lengths, and the motors will spool such that they achieve these lengths. Within the independent sketch, movement is done by activating corresponding digital pins on the Farmduino microcontroller. This allows for concurrent actuation of the system’s stepper motors and results in a change in vertical position. The change in location resultant from stepping the wire lengths a fixed amount varies depending on the end-effector’s location within the workspace. To make this sketch more accurately reflect movement within the workspace, additional mathematics and control theory would have to be done to alter the step number for each wire length to achieve the same displacement regardless of location.