Robotic Lawn Aerator - Part 2Follow article
Following on from the progress in Part 1, we have iterated and finalised designs for both the drill mechanism and the propulsion subsystem. Unfortunately, the lockdown in February 2021 meant that we could not proceed to manufacture. However, we did not let this slow down the progress and pursued alternative paths until workshop access is available again. This article will explain how we tied up some loose ends in design as well as run through a home experiment to demonstrate the workings of all electronics.
The vertical motion of the drill mechanism is guided by two linear rails. Jamming can happen if these rails become unaligned due to the torque induced by the rotating drills, which can consequently prevent the drill housing from lowering. To investigate this, FEA is used to test torsion induced displacement on the drill mechanism, where the torsion is a result of torque from the 4 rotating drills.
In FEA (Finite Element Analysis), the boundary conditions are a fixed base and an input torque is applied on the drill mechanism housing. With an input torque of 0.17125 Nm applied at the location shown in Figure 2, the deformation of the side walls is 2.11E-7 m (Figure 3). The FE result shows that in the condition analysed here, the drill mechanism would not encounter the kitchen cabinet problem.
However, a troublesome result from the FE model is that maximum deflection occurs at the housing and the side walls. In order to mitigate this to avoid any unwanted deformation is to add double the side walls thickness from 6 mm to 12 mm. By increasing the second moment of area of the structure, the amount of torsional deformation is decreased with the same torsional load. This is implemented into the final design because the cost of additional material to make the side walls is low enough to ensure no significant deflection is observed.
In addition to deflection, we also perform a stress analysis for safe measures. As seen in Figure 3, the maximum stress is found to be 32.5 kPa occurring at the point of the smallest cross-sectional area. However, this maximum stress is significantly below the tensile and yield strength of the material, so this should not be a problem for the mounting brackets used in our design.
The feedback we received in our first article was the possibility of incorporating some form of drill protection as part of our feature set. As the lawn aeration process requires drills to be lowered down into soil vertically, the drills could encounter hard objects embedded in the soil ie. stones, underground pipes, and concrete foundations. These drills can become blunt or snap under high rpm. Therefore, we investigated ways to automatically detect when these encounters occur and override and lift the drilling platform such that prolonged drilling into hard surfaces will not happen.
A method proposed is to use current sensors to monitor the current draw of the drilling motor. Figure 4 shows the drill mechanism electronics layout presented in Part 1 but added in series with the DC motor is a hall-effect current sensing module. If the drills are drilling into surfaces harder than typical soil, the torque increase will increase the current draw to the motor. This current increase gives us a good indication that the drill has hit a hard object and the Arduino board controlling the drill movement will override the current command to stop the drilling process.
Similarly, this current monitoring method will be implemented on the linear actuator controlling the vertical motion of the robot. This allows us to monitor the compressive stress experienced on the drill bit as it encounters resistance when it meets hard floors or stones while drilling downwards.
The required torque and current draw thresholds for both these motors were calculated based on the shear and compressive stress of known stone properties. Furthermore, experiments are being conducted now to identify a more accurate current threshold experienced by the motors by physically drilling into rocks. We expect there will be a deviation from our calculated and experimental values due to the internal resistance of the components, the limited sensitivity of our current sensor as well as a deviation in stone properties.
Mini drill setup
With the previous issues tackled, we were ready to manufacture the drill mechanism. However, the lockdown did not allow for this as aforementioned. Therefore, we developed a mini drill replacement setup to carry out some practical testing at home.
Figure 4 in the previous section presents the full schematic for the drill mechanism. In there, the key components are the stepper motor to operate the linear actuator, the DC gear motor to drive the drills and the Arduino to control the two motors. To scale this down for home experimenting, we replaced both motors with lower voltage alternatives and fitted appropriate supporting parts as shown in Figure 5. The point of the mini setup was to ensure our software works well on our electronics and to the Arduino, the two above setups are functionally the same. With the mini setup acting as the drill mechanism subsystem, we can proceed to incorporate it into the system-wise electronics to be discussed in the following sections.
From material analysis, the weight of the current RLA iteration is estimated at 14 kg. This translates to 3-3.5 kg equivalent of force distributed on each wheel of the robot. In the design presented in Part 1, this force directly acts upon the shaft of each motor. With the motors being important and expensive parts in the propulsion, decoupling of the weight is required.
FE analysis was once again used to gauge the severity of the bending due to the load and the effectiveness of the proposed solutions. The current driveshaft is 4mm, and for the redesign, it is replaced with a 6mm shaft. The bending of the shaft is directly related to the flexural rigidity of the shaft. By increasing the shaft diameter, the rigidity is improved and the bending is reduced by a scale of 5. However, to alleviate the remaining load on the motor shaft completely, a bevel gear assembly was created as a method to decouple the weight of the robot with the motor shafts. In this assembly, the motors were suspended over the base with struts. This relieves the stress experienced by the motor shaft and allows the transmission of rotational force to the wheels through a 90-degree orientation.
This solution also allows for better maintenance and protection to our more expensive components: a broken steel shaft can be easily replaced compared to a broken motor shaft. The motors can also be easily taken out for inspection without flipping the robot over or removing the whole subassembly.
In the last article, we managed to assemble the base plate with the propulsion electronics ordered. Following that, a test on four motors was conducted using Mission Planner to test on the skid-steering mechanism. However, there was an issue encountered where the right and left motors have different speeds while the input PWM is constant. The initial suspicions were either the motor controller could not output the same voltage value through the terminals or PWM value is not outputted at constant value through servo pins (Throttle Left uses servo 1 and Throttle Right uses servo 3) of Cube.
To test the first scenario, a multimeter was connected to both motor terminals to measure the output voltage. The radio transmitter is connected to the receiver to control the output voltage by toggling the throttle and yawing sticks. The servo pins were set to HIGH value to check if the motor controller is outputted at maximum voltage. From this, the motor terminals output 12V and this indicates that the motor controller is in good condition.
Next, a crocodile clip was connected to the servo pins of the Cube and a multimeter to see if it is outputting a 3.3V/5V pulse signal when the rudder stick is toggled. As expected, both servo pins were outputting inconstant PWM values which caused the abnormalities in motor speed. Nevertheless, the Cube could not be concluded as the root problem yet as it might be due to the software issues.
After further research, the issue was resolved explicitly by exploring other approaches. It has come to my realisation that the mapping of the PWM value of the rudder sticks in correspondence to the transmitter was mismatched. It must be mapped based on the minimum and maximum value of the radio calibration value. Since the calibrated value is between 982 and 2006, thus the central value is set to 1494. This applied to both Throttle Left and Throttle Right. One thing to note is that the throttle must be directly proportional to one another and this can be achieved by setting one of the throttles in reversed direction.
Software In The Loop
Even though we have the propulsion subsystem built, we could not do any field-testing due to the pandemic. So, similar to the drill mechanism, we needed to establish a suitable replacement to facilitate further testing.
At the heart of the propulsion system is the Cube Black flight controller (Pixhawk 2.1) running ArduPilot firmware. This combination is very powerful in terms of, given that you have carried out tuning, the Cube can control the drive system to navigate the robot to any input GPS coordinate you give. In other words, if you treat the autopilot system as a black box then when you feed in GPS longitudes and latitudes, you get out autonomous motion.
To replace this, we looked to a simulation called Software In The Loop or SITL. ArduPilot is an open-source software and the developers have enabled builders to download a copy of the source code, build and run it on their local machine to have a virtual vehicle that behaves identically to the real vehicle in theory. If we treat this as another black box then it again takes in GPS coordinates but instead of real motors and wheels turning, you get a simulated robot moving on your computer.
The goal is to have a replacement for the propulsion system so that we could test our software and because the two black boxes, Cube and SITL, take in the same input as well as have the same underlying code inside, we could expect one to generate reasonable outputs if the other was tested to be producing expected outputs.
With the above justification, we proceeded to install SITL according to the ArduPilot documentation and used it as a replacement to the propulsion subsystem to form the full system-wise electronic setup.
Merging the subsystems
The missing link
So far, the robotic lawn aerator is being functionally developed as two main subsystems: drill mechanism and propulsion. The decision was made to help assign tasks inside the team and split the workload as well because the two were not dependent on one another. However, the robot as a whole requires both subsystems and that work with each other in an organised manner. When the propulsion is moving, the drill should not be active and when the drilling is happening, the robot should standstill. In a typical mission, our robot needs to move to a waypoint, stop moving, drill, stop drilling, go to the next waypoint and repeat for all set waypoints. We call this “guided motion” (illustrated in Figure 10) and it requires subsystems to talk to each other.
As aforementioned, the Cube controls the propulsion and the Arduino is the brain of the drill mechanism. Establishing a link between the subsystems is essentially forming two-way communication between the controllers i.e. making the Cube-Arduino link. This was not straightforward and multiple methods were investigated. One method was to try to get the Arduino to interpret the MAVLink protocol used in the Cube but this was deemed too complicated and only unidirectional. Another method was to exploit the Cube’s ability to send a pulse as well as receive a start/stop signal. Despite being bidirectional, this fell short because it was unreliable due to the “hacky” nature of the wiring.
Taking a step back from the Cube-Arduino link, we realised both the controller has the ability to interface with a computer. Fitting a computer on a robot was not at all practical but thanks to the amazing technology that was the microcomputer, the problem was solved. As a result, rather than directly connecting the Cube to the Arduino, we used the Raspberry Pi, one of the most popular microcomputers, as the master controller to bridge the gap.
Special thanks to RS for providing us with a Raspberry Pi 4so we can greatly improve our control system. The Raspberry Pi is a credit-card sized piece of electronics that functions as a full-fledged computer. In our robot, the Pi is the master controller that instructs the Arduino and the Cube on what tasks to do and when to do them. This Cube-Pi-Arduino link allows the merger of the propulsion subsystem and the drill mechanism as shown in Figure 11.
Being two of the most popular boards in the hobby electronics world, the Pi-Arduino link is very easily established with several different methods in fact. The method of choice was the I2C protocol so we can free up Serial for the Cube.
On the propulsion side, the Pi-Cube connection is done via Serial communication. As mentioned, the Cube uses MAVLink protocol and this needs to be interpreted by the “companion computer”. Luckily, there are Python libraries available for doing just that on the Raspberry Pi namely dronekit and MAVProxy. With dronekit, you can send GPS coordinates to the Cube to instruct it to navigate to that location. With MAVProxy, you can broadcast the telemetry information to the Ground Control Station (GCS) running on a laptop making up for the fact that the telemetry port on the Cube is occupied by the Raspberry Pi. We do not dive into the specific implementation here but we recommend reading the ArduPilot documentation if you are interested in incorporating this into your build.
RLA Path Planner app
Introduced in Part 1 was the GCS of choice, Mission Planner (MP), which is powerful in its own rights but some features that we need were just not satisfactory. The first thing a gardener needs to do is to plan out a “lawnmower” path for the robot to follow autonomously. Evidently, in Figure 12, MP manages to formulate a grid pattern but all the waypoints (green pins) are on the border while we need them to be inside the lawn. Consequently, we had to develop our own app to use in conjunction with MP to get around this problem.
The app is called RLA Path Planner and its job is to take a lawn outline and plan out a lawnmower style path inside the outline which can then be ported to Mission Planner as a mission.
First, the outline of a patch of lawn is created inside Mission Planner which is called a polygon as seen in the top left of Figure 13. The longitudes and latitudes information of the vertices of the polygon are then exported to a text file. Then, the RLA Path Planner app imports these coordinates and plots them in blue on the top right image in the figure. In the same image, the black x’s represent a grid of equally-spaced nodes spanning across the bounding rectangle of the polygon. Next, the app runs an algorithm to check every node and only selects those that lie inside the polygon, highlighted as red x’s in the bottom right image. Finally, the red nodes are rearranged and exported as waypoints in a mission file which can then be imported in Mission Planner.
This functionality is then wrapped inside a user-friendly Graphical User Interface (GUI) shown in Figure 14. The entire app is written with the Python programming language - Tkinter library for the GUI and matplotlib library for plotting. Therefore, the app is packaged to a single ZIP folder with an executable file to ensure ease of installation. The download and instructions can be found on the team’s GitHub page along with a copy of the source code if you want to try it out yourself.
We were ready to put everything together and assemble the entire electronic system of the robotic lawn aerator, but the pandemic did not allow access to workshops so we had to find a workaround. Previous sections had been dedicated to justifying the replacements for the two main subsystems for operational testing purposes: the propulsion replaced with a SITL simulated vehicle and a mini version of the drill mechanism with lower voltages parts is used instead.
Shown above is the full wiring setup for the home experiment. Comparing it to the full schematic of the robot in the section before, some connections had to change. Instead of connecting the propulsion via Serial, the Raspberry Pi is connected to the SITL via the network because the vehicle only exists on a computer. The Arduino could be connected with I2C protocol but since Serial is freed up, it is used here for simpler wiring of only a USB cable. That being said, the home setup is made to be representative enough of the real scenario so that if the scripts and software work here, we can be confident that it will work on the actual robot.
The video below shows the process that a gardener would go through if he or she is to operate our robotic lawn aerator on a lawn. It goes through the usage of Mission Planner and RLA Path Planner software as well as demonstrates the Raspberry Pi is able to control SITL and the mini drill in the correct sequence. This concludes the work on software and electronics for our project. We believe that the successful home experiment validates our design and that when we fit the code on the real model, it will function as expected.
The previous section ties up loose ends on the electronics and gives a final demonstration of the entire system. To do the same for the design, we discuss the CAD model of the outer chassis that covers the electronics components and the drill mechanism. Considering the loads applied, the speed of the aerator would not give high-speed impact collisions. Instead, head-on collisions are considered to be of a high impulse, which would allow the force applied to be spread over a longer period of time.
With respect to the processes required, the chassis would be 3D printed in six parts, to allow for the limited sizes that could be produced each pass. In a larger manufacturing volume, the chassis would be manufactured using a faster process, like injection moulding for example. To allow for this, the model would be re-designed to fit this form, by combining all the segments and removing the 90-degree change in angle, to allow the mould to be removed after processing.
Despite having to constrain our work to our homes, we still managed to make significant progress since the last article. We finalised a design for the drill mechanism after solving the outstanding issues raised, assembled and tested a mini version of the electronics and put everything inside a chassis on our CAD model. As of writing this, the government is slowly easing restrictions that allows us to manufacture parts in the labs again. However, due to the limited time remaining in the project, we cannot tackle every aspect. Instead, we opt to focus on the defining feature of our robot - the drill mechanism. The next article will focus on the process of making this mechanism, the problems encountered and our solutions. We hope you have found this article informative and we look forward to making the next one.