Case study

Last-Metre Eyes: Viasat Space for Good 2026

Competition entry · submitted, not selected for Phase 3

My contribution: Sole entrant: concept, written answers, video and cards
Outcome so far: The written concept advanced from Phase 1 on 5 September 2026, and I submitted the Phase 2 video package complete and compliant on 27 September. The entry was not selected for Phase 3.
Where it stops: Nothing in the satellite segment was measured. The bearer in the demo was a mock, the Wi-Fi HaLow range is modelled from published wall attenuation, and the metrics are targets, not results.

In the write-upTwo segments The local link Impact metrics

Phase 1	Advanced	written concept, nine answers, 5 September 2026
Phase 2	Submitted	2 min 47 s video package, 27 September 2026
Drone BOM	A$1,084.84	as submitted, against my capstone A$1,100 budget cap; forecast, prices not re-checked
Local link	Modelled	Wi-Fi HaLow candidate, not measured

Card from the Phase 2 video showing the user journey: relay node switched on at the site perimeter, drone enters the structure, map reaches incident command, entry decision made

One of the cards from my Phase 2 video. The rest of the set is below. Open the full-size diagram (opens in a new tab)

Scope Systems concept, satellite backhaul, evidence boundaries

Phase 2 · what I submitted

Two segments, one interface.
The satellite side was never measured.

Last-Metre Eyes targets the last metres of a disaster search, inside collapsed or damaged buildings, where GPS does not work and the local cell network is often down at the same time. The concept splits the job in two, as a satellite cannot reach inside rubble and a drone cannot reach incident command on its own.

Two segments

The first segment is the drone, which navigates without GPS using visual-inertial odometry, stereo depth and D* Lite replanning. This is the aircraft I am building for my GPS-denied capstone, so the drone in the entry was hardware already on my bench.

The second is a one-button relay node at the site perimeter, where it has sky view. The drone sends its map, position track and detection events to the relay over a local radio link, and the relay backhauls them over Viasat's L-band network to incident command. Because the traffic between the segments is MAVLink and ROS 2 over IP, the drone stack is the same whether the backhaul is bench Wi-Fi or a satellite terminal, which is what made a mocked satellite link a fair test of the drone side.

The demo in the video ran real MAVLink traffic over a link shaped to published L-band latency and bandwidth, with the bearer labelled on screen as a mock.

Why the autonomy matters to the link

Remote piloting a camera through a collapsed building needs a broadband link that no satellite can push into rubble. Moving perception and replanning onto the aircraft changes what has to leave the site, from a video stream to an occupancy map, a position track and a short list of detection events, and that fits inside narrowband L-band capacity. That idea was the novelty claim in my Phase 1 answers.

Card titled Map first: the occupancy map of the demo survey is 42 kB, measured in the shot 4 demo, against roughly 20 MB for the same 32 seconds of HD video — The 42 kB is the map from the synthetic survey in my shot 4 demo. The 20 MB is a round figure for the same 32 seconds of HD video, so this card compares one survey and is not a compression ratio for the field. Open full size (opens in a new tab)

The link I could not measure

My Phase 1 answers referred to a local link between the drone and the relay but never said what it was, and a rubric review before submission had flagged that as the likeliest question from a technical judge. For Phase 2 I named Wi-Fi HaLow (IEEE 802.11ah) as the candidate, as it is sub-gigahertz, native IP and has Australian silicon from Morse Micro in Sydney. I labelled its range as modelled, because I did not own any HaLow hardware and buying it before Phase 2 would have broken the no-new-hardware rule I set for the entry.

Card titled The local link: Wi-Fi HaLow, IEEE 802.11ah, as the candidate drone-to-relay bearer, with the bench link through walls marked not yet measured and in-rubble range marked modelled — The in-rubble range is modelled from published attenuation of roughly 6 to 10 dB per concrete wall at 915 MHz (QUT, 2024). It is not a measurement of this system, and I have not checked ACMA compliance for this use. Open full size (opens in a new tab)

Naming a candidate I could later revise was a better position than leaving the central interface blank, although it means the strongest claim in the entry rests on someone else's measurements. A bench link through a counted number of walls at a known distance is the first measurement I would take.

Where it works, and what it costs

My navigation stack depends on cameras, and heavy smoke, dust or darkness degrade both the odometry and the stereo depth. I bounded the mission to post-earthquake structural search rather than claim active-fire interiors, with optical flow and a rangefinder as the position-hold fallback.

Card titled Where this works: post-earthquake structural search is in the envelope, active-fire interiors with heavy smoke, dust or darkness are out of it — The operating envelope as it appeared in the video. Open full size (opens in a new tab)

The A$1,084.84 is the drone bill of materials as I submitted it on 27 September 2026, against my capstone's A$1,100 budget cap. It is the forecast from my capstone cost register, including risk reserve, with some lines still awaiting landed costs at the time, and I have not re-checked it since. It covers the aircraft only, as there was no costing for the relay node or airtime.

Card titled Built from commodity parts: a flight-ready bill of materials of A$1,084.84 tracking to the A$1,100 cap, with OAK-D Lite stereo depth, ArduPilot, Raspberry Pi 5 with ROS 2 and D* Lite replanning, marked building, not yet flying — The bill-of-materials card. The aircraft was still being built, not flying, when this was submitted. Open full size (opens in a new tab)

How I would have measured impact

The metrics I submitted were time to first interior map, structures assessed per taskforce-day against the agency's own baseline, and responder entries avoided, counted from a trial log. None of them was measured, and the under-15-minute figure is a design target.

Card titled How we will know it worked: time to first interior map under 15 minutes as a target, structures assessed per taskforce-day, and responder entries avoided, all labelled targets and trial measures, not results — The impact card, labelled as targets and trial measures in the video as well. Open full size (opens in a new tab)

What I took from it

While I did not want to admit it, I was really down upon hearing the news of the Phase 2 results. By juggling school, work and this project, I knew one would diminish in its quality; however, I still really wanted to try as I found the whole project really fun. When I received the feedback, my mood lightened up as while the reviewers verified my concerns for my submission, they gave me some praise that I did not expect. In hindsight, I now see that too much time went into the drone build, and there were opportunities for me to re-record scenes to demonstrate a more confident delivery.

Overall, this has motivated me a lot to work harder on my UAV capstone project, and consider iterating upon it even after its planned completion in December. While I won't have the opportunity to have a Viasat representative to mentor me, I intend to work towards the capabilities I've planned for this project. It'll definitely take a lot longer considering I'm still a student, but something about this project motivates me intrinsically and I have a feeling I can actually pull it off.

After my TAFE capstone completion, I will work towards proving the complete system alongside some mock relays that I plan to develop myself. Furthermore, I will research into how I can make it more commercially viable, and establish further on what sets it apart from current solutions.

I still get really nervous while public speaking so I plan to expose myself to more challenges like VSFG 2027, and other events that will help me in that endeavour.

Thank you Viasat and HeroX for organising the whole challenge! I hope to participate again soon!

Problem

What needed solving

Enter a satellite-for-good challenge with a concept I could defend in front of technical judges: a disaster-response system that uses satellite connectivity where it actually helps, built on hardware I was already building rather than hardware I could only describe.

Approach

How the work is framed

I anchored the concept on my GPS-denied capstone, so the drone side is real work on my bench, and labelled everything else for what it was. The satellite link in the demo was a declared mock, the drone-to-relay radio was a named candidate with modelled range, and the impact metrics were targets, with every on-screen claim checked against a claims-to-evidence table before it went into the video.

Questions about this design? nathannoott@gmail.com

The résumé is the short version of this work: résumé overview, or the PDF.