Storm32 gimbal integration update

[Randy Mackay]

OlliW, Luis,

 

      I got the storm32 gimbal working today with master!

 

     To get it working I needed to:

·         connect the gimbal’s UART to Telem2

·         set SERIAL2_BAUD to “115”

·         set MNT_TYPE to “4” and reboot the Pixhawk

 

     I managed to control any of the 3 axis of the camera using using knobs on the transmitter (ardupilot’s mount library converts these to mavlink messages and sends down to the gimbal), and was partially successful at getting ROI (region of interest = point camera at a lat,lon,alt location) working.

 

     Some issues I found were:

·         if arducopter sends COMMAND_LONG messages at more than 10 hz the gimbal cannot keep up and it’s response slows as it seems to buffer messages.  I’ve slowed the update to 10hz.

·         tilt and yaw angle response seems reversed with pitch=-45 pointing up when it should point down and yaw +45 rotating left instead of right.  I’ve fixed this in the arducopter driver but I can switch it back if OlliW decides to reverse it on his side instead (which would probably be best)

·         providing yaw angle of 180deg correctly made the gimbal point backwards but providing -180 would make it spin around too far by 90deg.

·         the gimbal seems to be sending ACK messages with sysid = -1, compid = -1 (although this appeared as 4294967295) instead of using its own sysid,compid (i.e. 71, 67).  We don’t look at the ACKs anyway but probably best to fix this.

·         If connecting through the o323BGCTool with mavlink heartbeats enabled it loses connection after about 10seconds.  This is no big deal except the user must be quick to disable the mavlink heartbeats before attempting making any other config changes (and then must remember to turn it back on again later).

 

     I’ve checked some changes into ardupilot master and these will go out with AC3.3-rc1 (release candidate #1) in the near future.  I’m also working on a wiki page to make it clear how to connect the Pixhawk & SToRM gimbal.

 

-Randy

[Randy Mackay]

 

     Here’s the new wiki page.  http://copter.ardupilot.com/wiki/common-storm32-gimbal/

 

     It’s not exhaustive, not trying to recreate OlliW’s wiki, I just provided some links and highlight the critical bits that are special to the pixhawk+storm32 setup.

 

-Randy

[Craig Elder]

Thanks Randy and Olli.  That is looking great.

--
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/d/optout.

[Randy Mackay]

 

Luis mentioned that I was using an old version so I’ve re-tested with the latest SToRM32 firmware (v0.67e) and it fixes these issues mentioned earlier:

·         if arducopter sends COMMAND_LONG messages at more than 10 hz the gimbal cannot keep up -- FIXED

·         If connecting through the o323BGCTool with mavlink heartbeats enabled it loses connection after about 10seconds -- FIXED

 

These remain:

·         tilt and yaw angle response seems reversed with pitch=-45 pointing up when it should point down and yaw +45 rotating left instead of right (temporarily fixed in arducopter).

·         yaw angle seems incorrect.  Providing 180deg makes the copter move to 270.

·         the gimbal seems to be sending ACK messages with sysid = -1, compid = -1  instead of using its own sysid,compid (i.e. 71, 67).

 

.. This testing uncovered an existing bug in the mount code in which ROI for 3-axis gimbals was using absolute headings instead of relative.  With this fixed ROI now seems to work for SToRM (except for the yaw angle issue mentioned above).

 

By the way, when doing ROI with this mount and a 3-axis gimbal do we want the copter to point at the target or should it just let the gimbal do all the rotation?  I think we still want the vehicle to rotate so the gimbal will simply take out any yaw shakes.  People agree?

 

-Randy

[Luis Vale Gonçalves]

Hi Randy.

I believe the issue with 3 axis gimbals are: 

angle limits (physical due to the construction of the gimbal)

practical (if a gimbal rotates yaw to a certain angle, do certain parts of the vehicle become visible to the camera, ex: if my gimbal rates yaw 180º my battery becomes visible at the top of the image, or other cases landing gears may become visible in frame)

We can use the limits on the parameters to avoid both issues above, so that we could use the gimbal yaw limits if the angle desired would fall within the min/max range and if beyond that the vehicle would have to modify its heading to accommodate the angle. 

We could have in consideration the Yaw Pan Deadband before starting to modify the vehicle heading.

To the best of my knowledge no one is using a DJI Inspire with a PixHawk :) that would sort the issue with landing gears :)

[Luis Vale Gonçalves]

Hi 

Randy, as you've probably seen on the configuration app, the gimbal might work on different modes for each axis. These are Hold/Pan for each axis, where the Pan setting "follows" the nose (considering that the gimbal's zero is inline with the nose of the vehicle) and Hold maintains the gimbal pointed to the zero point.

I believe we should have this in consideration when sending commands to the gimbal.

On Friday, March 20, 2015 at 11:53:18 AM UTC, Randy Mackay wrote:

[איתי גיא‎]

HI Randy , 

could you please elaborate how the gimbal the mavlink and the pixhawk work together ?

Itay

[Oleksandr Chendekov]

Randy,

> By the way, when doing ROI with this mount and a 3-axis gimbal do we want the copter to point at the target or should it just let the gimbal do all the rotation? I think we still want the vehicle to rotate so the gimbal will simply take out any yaw shakes. People agree?

If talking about Copter or Trad Heli it's ok, and it may be an option or mode. But if we'll talk about plane we definitely need to yaw with gimbal.

[Luis Vale Gonçalves]

I believe one way to satisfy everybody would be to use the gimbal angle limits and beyond that then adjust the vehicle angles (yaw) to keep the ROI in "view"

On Friday, March 20, 2015 at 11:53:18 AM UTC, Randy Mackay wrote:

[Robert Lefebvre]

By the way, when doing ROI with this mount and a 3-axis gimbal do we want the copter to point at the target or should it just let the gimbal do all the rotation?  I think we still want the vehicle to rotate so the gimbal will simply take out any yaw shakes.  People agree?

It really depends what you are trying to accomplish.  If you want to satisfy the needs of serious aerial videographers, you absolutely must allow the option for free yaw rotation.  Many use two operators, one to fly the UAV, the other to operate the camera. Perhaps these people would not be expected to use this system, I'm not sure but, this is what they want and need so if you want them using this system, they need that option. 

[Jesus Alvarez]

We do that (the professional video stufff... )

And we are two operators, pilot (myself) and camera. In those situations, the gimbal is working in "speed" mode, not in position/angle mode.

[Luis Vale Gonçalves]

@Jesus

Even so, if the gimbal has physical limits, should the controller avoid damage to the gimbal, when trying to set impossible positions ? It doesn't matter if angle or speed setting for the gimbal.

IMHO, when 2 operators are present (assuming also two controllers), usually the vehicle and the gimbal are probably both operating in manual mode, so no need for the "intervention" of the flight controller. Better yet, does the flight controller even need to know there's a gimbal ?

When flying auto modes, then, I believe that the gimbal control can be automated. In the event that the vehicle can be flying auto and the gimbal controlled by a user, then the requests to the gimbal should be routed through the flight controller so that it can adjust it's attitude to better accommodate the gimbal requests.

[Doug Walmsley]

I vote yes to that.  However,  once the next point is accepted a slow yaw would be advisable to ensure you don't stress the gimbal to compensate in the event the airframe is pointing aft at the last way point and is now yawing to the next ROI which may be ahead flight path.

[Luis Vale Gonçalves]

Casually I looked at Dronekit-Android and noticed there might be requests to implement functions that we are also discussing here.....

https://github.com/DroidPlanner/DroneKit-Android/issues/44

https://github.com/DroidPlanner/DroneKit-Android/issues/77

On Friday, March 20, 2015 at 11:53:18 AM UTC, Randy Mackay wrote: