Servers by jDrones

Can you use RTK without camera offset?

(MickeM) #1

Can anyone of you use RTK?
We use Hexaero Pixhawk 2.1 with Here+ GNSS RTK-setup on a multicopter.
There are offset-parameters for the distance between GPS and Cube.
But there isnt any offset-parameters for the camera.
In our case, the camera is around 20 cm under the Cube and also 40 cm under the GPS.
The multicopter also leans when flying
How do we get the right position of the pictures with cm-precision, if we dont know where the camera is?
How do you use RTK?

1 Like
(Andras Schaffer) #2

Camera offset can be set in the processing software. (But only vertical)

(hans bert) #3

i just wrote a simple python script that uses rtk positions, imu xyz and the camera position to tag raw images on the fly.

1 Like
(Tobias) #4

would you be willing to share your script?

(M) #5

what camera are you using, would it be compatible with sony wifi being able to transfer over wifi to a jetson or rpi?

(Andras Schaffer) #6

I’m interested as well. Did you add uav yaw as well into the calculation ?

(hans bert) #7

Hey,
its sony only.
its gimbal compatible (it can also calculate the offset if you use a gimbal for the camera and non for the gps)
it sets roll/nick/yaw tags (uses pixhawk after kalman fiter data) AND rtk gps coordinates.
uses the flash port for exact timing.
camera/gps offset, with (dynamic) or without gimbal (fixed)
interpolates between gps measurements (uses imu for improving)
max speed tested was around 1,4s per image, maybe more possible.
no wifi, all through usb. the images are saved on a sd card/usb stick connected to the processing raspi.
it is also compatible with a spectrometer or lux sensor for irradiance light sensors.

the negative:
i am no surveyor.
i am not a professional programmer.

the script is not yet reviewed an tested from external experts. i dont want to publish something untested.

i used almost the same approach like drotag but improved it further.

(Fi156) #8

Thats really interesting in comparison to Nathans (@Naterater) comment:


UBlox ZED-F9P L1/L2 GNSS Unit
(BennyB) #9

Hi

We use drotag at the moment. Do you have a similar hardware like Drotag then? Is it possible to test the script? I am not a programmer but a surveyor. We have a multirotor with Sony A6000 with a testarea eith surveyed markers.

(BennyB) #10

Hi

Wouldnt the easiest way be to have a camera offset parameter in mission planner. It would correct for IMU roll/yaw etc. and be able to choose to tag the images with the camera coordinates.

You are able to correct the coordinates in the processing software if you have strict vertical offset from the GPS antenna to the camera but that means you cant have any yaw/roll etc. So not really a solution.

(MickeM) #11

I am also in for the “camera offset”.

Today there is an offset for the GPS relative to the IMU. But does it calculate and add / subtracts the difference when leaning?

If so… the same can be applied to Camera offset relative to the GPS.

I did this picture below to show how I should “think” if I could made the code for the difference between standing straight on the ground (with camera offset-parameters x, y and z) and when leaning.

Angle = IMU angle

Diff = Camera Offset Z ( sin Angle )

Then the code adds/subtracts the Diff to/from the position and adds it onto the JPG or whatever.

(MickeM) #12

Hi again!

Do anyone know if this feature (Camera offset) is added or planned to be soon? It would be awesome! :slight_smile: I am building a new 1000mm X8 for RTK-mapping and it would be great if it works.

What other RTK-systems are there?

(Norimbo) #13

I didn’t get any answer about implementing this “camera offset” in the future versions of arducopter firmware and Mission Planner … I asked in several topics.


That’s a pity that you can’t get cm level accuracy in multirotor with Here+ GPS in photogrammetry. This problem will appear in any new GPS L2 with better accuracy. Software is not ready for hardware.

(curt carroll) #14

No It is not and this subject is mute (in my opinion) until it’s fixed. Ublox software needs Geoid models to get accurate vertically for a start. Also the hardware does not repeat vertically F9P included. Everyone reading this with RTK can and should watch the vertical on fixed ublox solutions move around beyond reported and advertised accuracy.
These 2 things prevent this topic from being important to me yet, though it should be and I am glad it’s being discussed don’t get me wrong. I am taking notes in hopes we get to the point of reliable, repeatable XYZ positions.

(BennyB) #15

I don´t think you will need any Geoid model. If you will use your Rover several kilometers from the Base it would be needed but how many fly your drone that far away? Shouldn´t be an issue as far as I know.