MAVLINK message for camera position

[Jaime Machuca]

I would like to have some feedback about the gimbal position to know where the camera is currently pointed to. With the position, altitude and gimbal angle, along with the camera parameters it could be possible to calculate the viewing area of the camera. I don’t think currently MAVLINK has a message to send this information, can some one point me to what needs to be done in order to have this information downlinked? I would be interested in helping make this happen, but I am really new to this code. Any help getting started is welcome.

Jaime Machuca 

[Randy Mackay]

Jaime,

 

     Yes, I can imagine how that could be useful.  I’m not sure if you’re talking about plane  or copter but for copter most people are moving to brushless gimbals.  With these types of gimbals the position of the camera is only known to the gimbal which has its own IMU.

 

     The VR Gimbal is open source and they have plans to add support for Mavlink messages so cooperating with them might be a good idea.  Alternatively you could try and get the info from a Martinez gimbal but I’m unsure what interfaces they support.

             http://copter.ardupilot.com/wiki/common-vrgimbal/

 

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jaime Machuca]

I am using a tarot gimbal, and I use the APM to tilt the gimbal with the gimbal outputs. The IMU on the tarot just keeps it level, so I can calculate the position from the servo outputs. This only works if the gimbal is set to control the position proportionately to the control input. If it's set to control the speed of the movement then it won't work.

Best regards,

Jaime Machuca

Sent from my iPad

[Gary McCray]

I agree with Jaime,

It is true that he IMU on the Brushless gimbals (camera mount) card keeps the camera level.

But external inputs are applied as offsets to actually point the camera to the location desired.

In fact this is a superior solution to pointing the camera relative to a rolling and pitching platform.

And it actually makes the solution for where the camera is actually pointing simpler not more complex (because the offsets are relative to a level platform).

In fact it should be entirely a product of applied inputs and thus not actually necessary to solve on board at all.

It could be solved in Planner, pre, post or during flight (assuming camera offset inputs are part of the flight information either auto or manual).

Best Regards,

Gary

[Robert Lefebvre]

Yes, this is true.  The APM can send an aiming target to the gimbal, and the gimbal will do the rest. So one could assume that the camera is aiming at the desired point.  But there are two problems to this:

1) The IMU systems in these gimbals is not good.  They will often have errors if you are flying dynamically.  Yawing seems to cause the most problems.

2) The camera can get knocked out of position due to low holding torque, but this should not happen during normal operation.

--

[Gary McCray]

Hi Robert,

I have seen the inadequate performance of which you speak as well.

The GoodLuckBuy types are basically awful, inadequate gimbal motors, inadequate gimbals and inadequate controllers.

I've got to think that some of the better ones aren't as bad: Maybe a Vrbrain controller, T-Motor Gimbal motors and - - a Zenmuse Gimbal?.

Unfortunately the other end of the price spectrum.

What the world needs is an honest brushless gimbal.

Best Regards,

Gary

[Jaime Machuca]

I think regardless of the precision of the IMU on the gimbals, which is bound to get better with time, It should be possible to downlink the commanded camera position. Besides, I don’t really need to know exactly what the camera position is, I just want to get an idea of where it is during flight so that in mapping missions I get an idea of what I am covering. I think for a first approach this would be a start. 

Like I said, I would just need some pointers on where to start, what would need to be changed, extended, and I can try to get this working.

Jaime Machuca Mercado

CTO | Droidika | www.Droidika.com

Mail. Ja...@Droidika.com

Tel. +52 (33) 3777 5327

Cel. +52 1 (33) 3945 3350

[Jason Short]

On the Tarot we are shipping with absolute position enabled from 0° to 90°.

The output from the PWM to control angle is something like 1000 to 1500 PWM.  There is no closed loop communication with the gimbal, but if it is working at all it will be pointing at the angle specified. The next step is Serial protocols and custom firmware.

Jason

On Feb 19, 2014, at 11:46 AM, Jaime Machuca <ja...@droidika.com> wrote:

I think regardless of the precision of the IMU on the gimbals, which is bound to get better with time, It should be possible to downlink the commanded camera position. Besides, I don’t really need to know exactly what the camera position is, I just want to get an idea of where it is during flight so that in mapping missions I get an idea of what I am covering. I think for a first approach this would be a start. 

Like I said, I would just need some pointers on where to start, what would need to be changed, extended, and I can try to get this working.

Jaime Machuca Mercado

CTO | Droidika | www.Droidika.com

Mail. Ja...@Droidika.com

Tel. +52 (33) 3777 5327

Cel. +52 1 (33) 3945 3350

<EmailSignatureDroidikaLogo.png>

[Robert Lefebvre]

Well, if you are using PWM to command the gimbal, you should have all the data you need on the RC output data?

[Jason Short]

yep.

On Feb 19, 2014, at 2:05 PM, Robert Lefebvre <robert....@gmail.com> wrote:

Well, if you are using PWM to command the gimbal, you should have all the data you need on the RC output data?

On 19 February 2014 14:46, Jaime Machuca <ja...@droidika.com> wrote:

I think regardless of the precision of the IMU on the gimbals, which is bound to get better with time, It should be possible to downlink the commanded camera position. Besides, I don’t really need to know exactly what the camera position is, I just want to get an idea of where it is during flight so that in mapping missions I get an idea of what I am covering. I think for a first approach this would be a start. 

Like I said, I would just need some pointers on where to start, what would need to be changed, extended, and I can try to get this working.

Jaime Machuca Mercado

CTO | Droidika | www.Droidika.com

Mail. Ja...@Droidika.com

Tel. +52 (33) 3777 5327

Cel. +52 1 (33) 3945 3350

<EmailSignatureDroidikaLogo.png>

[Randy Mackay]

Jaime,

 

      I think you should talk with Roberto, Emile Castelnuovo, and Matteo Murtas of the VR Gimbal team for the specifics of what they’re doing to add mavlink support to the gimbal.

 

     Personally I’m not familiar enough with the gimbal code to give direction but I can imagine it will work something like this:

               Pixhawk/AC connects to VR Gimbal using one of the available serial ports which allows 2-way MAVlink based communication (I don’t think it’s worth trying to accomplish this with an APM2 although you’re welcome to try)

               Pixhawk/AC is connected to the ground station using 3dr radio (or similar).

               When mavlink messages arrive from the ground station the Pixhawk/AC  decodes them (this is happening now of course) and if it sees any messages that are meant for the gimbal then it just copies the message out to the serial port that’s connected to the gimbal.  It could recognise the messages meant for the gimbal because they’ll be mavlink mount_configure, mount_control or mount_status messages….or maybe it’ll recognise them because the message has the  MAV_COMP_ID_CAMERA (not sure).  It would also need to parse messages coming in from the gimbal and copy them over to the serial port which sends to the ground station.  I think that AC will already consume any mavlink messages shoved into any serial port so it’s probably just about ensuring that it recognises the messages from the gimbal and does the copy as mentioned.

        

     Most of the general purpose mavlink message definitions are here:  https://pixhawk.ethz.ch/mavlink/

     You’ll find a list of all the ardupilot specific messages in the ../libraries/GCS_MAVLink/include/mavlink/v1.0/ardupilotmega directory.

     The arducopter code responsible for sending/receiving mavlink messages is in the GCS_Mavlink.pde file.

     Somewhat confusingly there’s also a GCS_MAVLink library which handles some of the non-frame-specific aspects of sending messages (i.e. buffering, etc).

 

-Randy

[Gary McCray]

Agreed,

The commanded output code should be equivalent to actual pointing and if it isn't, all your really looking for is error.

Basically no need to get it from Mavlink, just fix the gimbal and controller so it works right.

[Kevin Hester]

I haven't looked into the gimbal mavlink thing, but one more option for connection:

If you don't need messages from the gimbal to the GCS you could hook the serial tx from the 3dr radio to both the pixhawk and the gimbal (without having to forward anything on the px4).  Presumably the gimbal folks are going to pick a component ID that doesn't conflict with the APM (not that it really matters in this 'listen only' config)

[Roberto Navoni]

Hi Kevin Hi Jaime,

we are working hard on VR Gimbal code in last year .... we plan to add a lot of function and include the suport of mavlink protocol ... now we are consider to add the support of can bus on vrgimbal , too as on VR Brain 5.0 and use that bus for share messge between the gimbal and drone. 

So is yet possible to use ttl serial port that work fine ... on usb we have some problem in debug mode to solve ... the use of it introduce delay in the main loop so if you consider to interface the VR Gimbal use now ttl serial port.

At the moment we support a lot of mode : analog poti input , 4 pwm channel , ppmsum and in future mavlink ,too.

Now is possible to use : relative control position , absolute and also automatic follow frame  mode as for alexmos ...

best

Roberto