Author:Military Drone Manufacturer TIME:2026-10-11
An RTK module buys a positioning component, not a complete mapping service. A finished mapping system also needs an aircraft, a suitable camera, a supported way to associate images with position, processing software and someone responsible for checking the output. Even a package called an RTK drone may leave subscriptions, processing and delivery outside the quoted price. When comparing a module with a complete aircraft, compare the work each supplier has agreed to finish. The useful dividing line is not the presence of an RTK label; it is the last usable item the order actually delivers.
A component order can be the right purchase when a competent integrator already owns the surrounding system. It is a poor substitute for a complete package when the buyer expects to unpack a box and receive a usable site map. These are different jobs, even if both quotations use the same positioning terminology.
For a concrete component reference, the G982-4G RTK module listing describes a receiver-based unit. Its photographs show an enclosure and antennas, not a complete mapping aircraft. They do not establish that every visible accessory is included in a current order. Ask for an itemized supply list rather than treating the picture as the packing list.

The diagram separates three purchasing boundaries; it is not an assembly sequence. A supplier may cover more than one, but the quotation should identify each. In particular, a software license and a completed processing service are different purchases. Neither should be inferred from the presence of positioning hardware in the box.

The G982-4G listing names a UM982 receiver. Unicore describes the UM982 as a positioning and heading module. That establishes what type of component is being referenced; it does not independently verify the board, enclosure, firmware or accessories supplied under another product name.
Keep three identities separate: the receiver component, the assembled module sold by the supplier and the aircraft into which it will be installed. A specification at the first level should not silently become a promise at the third. For example, a receiver interface description is not proof that a complete module exposes the same connection in a form supported by a particular aircraft.
The buying question is therefore narrow: who confirms support for the exact combination being ordered? Request that confirmation from the party responsible for integration. This is more useful than collecting a long list of receiver capabilities that nobody has agreed to deliver in the finished system.
RTK depends on correction information as well as satellite observations. A cellular connection can be part of the route carrying that information. Owning cellular hardware does not, by itself, purchase a mobile data plan or access to a correction provider.
Separate those commercial items in the quote. Name the account owner, service period, operating region and renewal responsibility. If the supplier provides initial access, establish whether it is a demonstration account, a time-limited subscription or an ongoing service charged separately. Do not send account passwords in a purchase checklist.
This also separates warranty from service support. A disconnected account and a defective module can interrupt the same project but require different remedies. The order should identify whom the buyer contacts for each. No particular carrier, correction provider or regional coverage is confirmed by the G982-4G photographs used here.

A position log and a folder of photographs are not yet a mapping project. Someone must be responsible for the supported relationship between image capture and position information. That includes the camera identity, timing information and the files expected by the chosen processing workflow. An RTK receiver alone does not establish that relationship.
Ask the integrator to identify the deliverable at this boundary: photographs with supported location metadata, a separate image-position file, or another documented dataset. Ask the processing provider whether that actual dataset is accepted. A generic assurance that the aircraft has GPS is not the same answer.
RTK and PPK should not be treated as interchangeable software labels. PIX4Dmatic documentation distinguishes real-time corrections from corrections processed afterward, and states that its PPK workflow takes previously corrected image positions from another processing step. If a quotation relies on PPK, identify the owner and cost of that earlier step rather than assuming the final mapping license includes it.
Receiver position, image location and the position of a feature in a finished map are related but different quantities. A good receiver specification cannot remove a poor photograph, an unsuitable reconstruction or a mismatched reference system from the rest of the project.
PIX4D distinguishes relative accuracy within a reconstructed model from absolute accuracy against a real-world reference frame. Its documentation also identifies image quality and scene content as influences on mapping outputs. This is why a module's positioning headline is not a project-wide promise about every surface in an orthomosaic or model.
For purchasing, put the acceptance claim beside the actual deliverable. A civil inspection record, a measured surface model and a visual site overview need not have the same requirements. Let the qualified project owner define the requirement and the independent evidence used to judge it. This article does not assign a numerical mapping tolerance or certify G982-4G performance.
A processing report is useful only when its measures are understood. PIX4Dmatic distinguishes camera-position information from checkpoint comparisons; its documentation explicitly cautions that image geolocation errors are not the accuracy of the reconstructed three-dimensional points. Request a report tied to the delivered dataset, not a screenshot borrowed from an unrelated demonstration.
A module can look inexpensive because the quotation ends sooner. That is not necessarily a problem. It becomes a problem when integration, service fees or processing labor are discovered after purchase. Compare offers by assigning each missing job rather than adding a speculative percentage to the component price.
| Responsibility | Order line must define |
|---|---|
| Hardware supply | List the module revision, named accessories, documentation and warranty contact. Mark customer-supplied items separately. |
| Aircraft and camera integration | Name the party accepting responsibility for the combination. Record what compatibility evidence will be delivered. |
| Recurring services | Separate cellular access, correction access, software licensing and any storage charges. State the term, not just the first payment. |
| Processing and checking | Specify who turns the captured data into the agreed output and who checks it against the project requirement. |
| Project delivery | Define filenames or formats, coordinate reference information, reports and the receiving person's acceptance responsibility. |
A blank responsibility is not the same as an included service. Write “buyer provides” or “supplier provides” beside each line, then compare prices for equivalent scopes. Do not count the same license twice if it is already covered by an existing agreement.
Start with the recipient. If a colleague needs a file that opens in a particular civil mapping application, that requirement belongs in the order. If the buyer only needs a module for a documented integration project, do not pay for a turnkey delivery package that is outside the job.
These are proposed order terms, not claims that any named product already includes them. Once the handover is clear, a module purchase and a complete-system purchase can be compared without pretending they deliver the same thing.
Choose the end of the job first. Then buy the component, integrated package or delivered service that reaches it. The lowest comparable price is the price for the same completed responsibility, not merely the smallest box.