I use the RS3 for various purposes, two of them are:
Vehicle-based continuous mapping
Watercraft-based single-beam bathymetry
I would love to have the ability to pipe external rod height values into the RS3, so that those values are added to the internal rod height values and tilt compensation applied out to those distances.
Yes, I can do this using 3rd party SW/HW integrations (I have PixHawk) but it would be much easier to simply have a NMEA input which is heights only.
Something like NMEA Message $SDDBT would suffice.
Please, consider this addition to either the RS3 directly, or Emlid Flow as an input, as this would be really helpful for real-time and simplification of basic continous topo data collects.
Thanks
(and if anyone else wants this feature, please join the conversation and add your voice to support it).
Hi geohawk,
recently we managed to get the RS3 up and running on a mobile robot.
The two main issues you need to understand are:
the NMEA messages, as far as I understand, provide the location/tilt/heading of the antenna, ignoring the pole or the frame used to attach it to the robot. They just talk about the antenna inside the RS3.
You will need to determine the location of the âtip of your poleâ using the math described in the PDF linked in this page. This accounts for the pole height NMEA specification | Reach RS3
Does it make sense?
Btw, even if this is a solution, it would be great to have all this computed for you by the device.
Thanks for your reply.
Iâm not sure you fully understood my request.
The NMEA message support Iâm requesting is for a single message in, not out. Youâre referring to NMEA messages which are being transmitted, not received by the RS3 rover.
As I stated, I understand how to apply the corrections externally. What I am requesting, are for corrections to be applied by Emlid, for varying rod heights, which are received.
Iâm not confused on NMEA formatting, messages or how to read/write them.
As I stated, I would vastly prefer to have this handled by Emlid for quality control purposes.
The single main reason, is KISS: Keep It Simple Stupid, which sound mildly derogatory, but really just means the fewer pieces of equipment running, the less probability for catastrophe or mistakes to be made in the field.
I appreciate your input, and itâs great to âmeetâ you!
Do you understand my request for native handling of varying rod heights for continuous topo?
Wouldnât it be nice if Emlid handled that natively (whether via Emlid Flow on a mobile device, or the RS3 natively)?
It would only require them to add a receive port for rod heights, and apply the tilt values to the internal heights plus those received heights.
I still donât think you get this Fernando.
The news you just supplied is regarding DATA OUT.
Iâm really focused on getting DATA IN.
Yes, I use variable rod heights when driving in a vehicle (e.g. UTV) with the RS3 fixed to the vehicle via bracket.
The suspension of the vehicle can alter the results by up to 30cm (or more at times ) and using sonic distance sensors (cheap, easy) under the rod measure the variability in that distance within a few cm.
likewise, when utilizing watercraft, sometimes a single beam sonar is useful for obtaining single measurements to the bottom from the water surface. This obviously will vary quite a bit.
However, the output of most sonar systems can be NMEA in the message I provided in my original post.
Feeding that NMEA string IN to the RS3 would enable the RS3 to do the *very simple) math of adding that distance to the known rod height (that which is input into Flow).
I understood your requirements. I just provided some info that may be useful even if not a complete solution.
Given the mobile app can enable NMEA messages (OUT) with tilt correction and that correction is available even outside the app, the RS3 must receive and store the pole height somehow.
Emlid people, how the app provides the length of the pole? Is this via an undocumented API or NMEA message? If that is the case it is just what geohawk requiresâŚ
Why give this as a solution, when it wasnât the criteria?
I explicitly defined an external solution as already achieved, but not fulfilling the request.
I donât understand how this was helpful in any way.
For me, it convoluted the original question, which was clear and delineated the need for NMEA input not output.
Why?
Also, this is not a solution that âjust what geohawk requiresâ. It is a commonly integrated system, applied in numerous field controllers. Itâs a common feature, actually.
The reason for that, is that many of us use it regularly.
I would like to skip the âman in the middleâ.
Your comments are most unhelpful, and at this point, I feel a bit arrogant, or snide.
If youâve never used RTK GNSS in this configuration, what compels you to answer a question you donât fully understand?
Thanks for sharing your detailed request regarding the feature youâd like to see in Emlid products. Currently, we donât have that specific feature available, but we truly appreciate your feedback. Iâll make sure to pass your suggestion along to our development team for consideration to be added in the future.
Thank you @victor.ferreira for both acknowledging my feature request and passing it along to the development team.
I truly believe that if you look into this, youâll find that adding such a feature adds a fair amount of capability to the product, with minimal development time (there is already support for incoming ports, and adding a single NMEA string is perhaps not the hardest thing to support).
Again, I thank you, and my very best to the Dev Team.
) and using sonic distance sensors (cheap, easy) under the rod measure the variability in that distance within a few cm.