RTK-FIX status indicator on automatous mower

I wanted a real time RTK-FIX status indicator on my automatous mower. This is a LED beacon that is visible in bright sunlight. If it’s ON then I have RTK-Fix if it’s OFF then I don’t. This uses a LUA script to control an AUX port for a relay. I used the AUX signal to control a LED driver circuit that controls the LED. If the signal is HIGH the LED is ON. I used a water-clear LED so it’s easier to tell when it’s ON in sunlight. The 3D printed “lighthouse” LED holder and LED driver PCB artwork can be found on my Thingiverse channel: OTandAT RTK Lighthouse Beacon for my Rover Mower by OTandAT - Thingiverse
Many thanks to Yuri Rage for his videos and examples. (I’m new to LUA)

local SCRIPT_NAME = 'RTKrelay'
local RELAY_NUM = 2
local MIN_FIX_NUM = 6   
local GPS_INSTANCE = 0  
-- GPS Instance RTK Fixed = 6
function update()
local fix_type = gps:status(GPS_INSTANCE)
    if fix_type >= MIN_FIX_NUM then 	
	gcs:send_text(0, "Relay ON")  -- delete if you don't want the HUD spammed with Relay ON msg.
    	relay:on(RELAY_NUM)     	
	else	
	gcs:send_text(0, "Relay OFF") 
	relay:off(RELAY_NUM)
        end 
return update,1000	
		end
return update(),1000

(hope the pic works)

1 Like

A couple of tweaks for efficiency’s sake (along with fixing the GCS message severity, correcting the syntax error on the last line, and making use of the previously unused SCRIPT_NAME variable). Now you won’t spam the GCS with text, even if you leave the send_text() calls intact.

local SCRIPT_NAME = 'RTKrelay'
local RELAY_NUM = 2
local MIN_FIX_STATE = 6
local GPS_INSTANCE = 0

local prev_fix_state = 0

function update()
    local fix_state = gps:status(GPS_INSTANCE)

    if fix_state ~= prev_fix_state then
        prev_fix_state = fix_state

        if fix_state < MIN_FIX_STATE then
            gcs:send_text(6, ('%s: Fix state (%d) below minimum'):format(SCRIPT_NAME, fix_state))
            relay:off(RELAY_NUM)
            return update, 1000
        end

        gcs:send_text(6, ('%s: Fix state (%d) good'):format(SCRIPT_NAME, fix_state))
        relay:on(RELAY_NUM)

    end

    return update, 1000
end

return update, 5000 -- 5 seconds to allow for GPS initialization

You shouldn’t need an LED driver circuit unless you’re using 12V LEDs or some sort of high current/super bright light. Direct GPIO output of nearly any autopilot should supply enough current for a single LED and properly sized current limiting resistor.

1 Like

Thanks for the code spiffing. Mine was crude and I was just happy it worked. It was my second day of learning the LUA syntax. I’ve been leaning from your examples and apricate the lessons. The photo of LED pictured did not do the brightness justice. I wanted an LED that I can see from across the yard (the one I have now can be seen from 40 feet in bright sunlight, I want better!) and just didn’t think the AUX port could/should supply the current needed. I’m did change the title back. I have not made an autonomous mower; I have made an automatous mower.

Automatous; adjective au·​tom·​a·​tous (-mətəs) : of, like, or suggestive of an automaton : automatic, mechanical

Automation/Automatous is the application of control theory and technology by which a process or procedure is performed without continuous human assistance. In an industrial context, it’s about setting up machines and control systems to carry out a series of tasks, following specific instructions. Essentially, it’s the execution of predefined tasks through automated control. My mower is basically a mobile CNC machine.

Autonomy/Autonomous on the other hand, takes things up a notch. It refers to machines or systems that can perform tasks and take action on their own, without requiring direct human instruction for every move. This involves self-learning through Artificial Intelligence (AI) and Machine Learning (ML) to adapt to new data or environments, allowing for a more autonomous decision-making process, often incorporating intelligent control solutions for enhanced autonomy. Maybe someday I’ll have an autonomous mower, but then it will probably do the laundry as well. (until it morphs into Skynet)

You should apply the same amount of pedantry to your electronics as your word choice :slightly_smiling_face:

Thanks for the input. I’ve never been able to find the current specs on the just the AUX signal outputs and because I’m not powering the AUX Vc, rail I decided just to err on the safe side for my beacon. As to the word choices, I’m just trying to be correct.

That looks a bit like CubePilot hardware. If so, here are the relevant specs:

https://docs.cubepilot.org/user-guides/autopilot/the-cube-module-overview

Thanks again, yes, I started there and though and did not find data specific to the AUX ports this phrase stuck with me. “the I/O PWM outputs can also be configured as individual GPIOs. Note that these are not high-power outputs – the PWM drivers are designed for driving servos and similar logic inputs only, not relays or LEDs.” SO, Orange Cube expensive, LED driver not…

A single, typical LED with a properly sized current limiting resistor would be fine (as I’ve used many times for testing, keeping the current draw to about 20mA).

Clearly these pins aren’t intended to drive entire strings of lights or get directly connected to relay coils.

Your approach isn’t wrong, it just seems a little like overkill, that’s all.

Another potential approach that wouldn’t rely upon LED brightness: Raise a little brightly colored flag with the cheapest of cheap servos any time the fix type is out of desired range. The script would be near identical, and the visual cue might be visible from a greater distance.

My own approach is to stop moving until the fix type is RTK Fixed. I use manual mode as the fallback, along with a spring-centered RC controller that reasonably ensures that a spontaneous switch to manual mode ceases motion. Once in the script-driven manual mode, I can drive out from under cover, and the script automatically picks up in auto mode when the GPS status recovers. Others use that script with a hold mode fallback and simply wait it out.

2 Likes

In my experience the GPS performs slightly better when stationary, so, upon detecting a poor GPS fix, I stop (using HOLD mode) and 19 times out of 20, after 10-30 seconds, the GPS fix gets better again, and I can continue on.

1 Like

Most of the time when my script kicks in, it the fix state improves before I have to bother noticing that it paused for a sec. Occasionally, I get under some thicker cover where a little manual intervention is warranted.

We are currently also monitoring the horizontal accuracy and mowing with fix state 5 if the h_acc is also <40mm. So our failsafe kicks in when fix state is 4 or less (which only happens if the rtk correction feed has failed for some reason) or fix state 5 or 6 and h_acc>40mm. Curious your thoughts on that approach?

I don’t think it’s a bad approach to monitor more information and act upon it. How is it working in practice?

Based on what I know of hAcc, I’d be hesitant to trust it. Both hAcc and HDOP are measures of quality but not necessarily true measures of precision or absolute accuracy.

My own observation has been that as long as I retain an RTK Fixed state, things seem to be mighty fine. But an RTK Float status quickly diverges from desired results. A solid handful of the MowStock folks use the same approach with success.