EvvGC-PLUS gimbal software now supports MAVLink!

[Matas Razgūnas]

Hello,

Here is another Gimbal software which supports MAVLink control and it is opensource!

Feel free to view code at https://github.com/DroneBuster/EvvGC-PLUS/tree/mavlink_1.0 later it should be merged with main repository.

I want to ask what values would be best for these:

static mavlink_system_t mavlink_sys = { 20, MAV_COMP_ID_GIMBAL };

static uint8_t system_type = MAV_TYPE_GIMBAL;

static uint8_t autopilot_type = MAV_AUTOPILOT_GENERIC;

static uint8_t system_mode = MAV_MODE_TEST_ARMED;

static uint32_t custom_mode = 0; ///< Custom mode, can be defined by user/adopter

static uint8_t system_state = MAV_STATE_ACTIVE;

For now this software is untested with Pixhawk but I will do so tomorrow. For now it works great with MissionPlanner :)

[Lorenz Meier]

Hi Matas,

Could you reference the electronics and gimbal hardware to use with this branch? We're happy to help you with th full integration.

-Lorenz

[Matas Razgūnas]

Hi,

For now I know only one source of boards: http://www.goodluckbuy.com/

This was quite popular project in 2013, but it died. Now someone wrote new improved code, but from 2013 interest decreased and boards aren't broadly available.

This board has quite few design flaws and I'm planning designing new one with better processor (Which has FPU because now other dev tried implement 2 IMU's but stm32f103 doesn't have required power) and new motor driver's circuit. Also I'm planing to add support for UAVCAN.

For gimbal hardware any Gopro brushless gimbal will do ok. 

[Matas Razgūnas]

Hi,

I tried to connect to Pixhawk and it worked! With MNT_TYPE set to 2(MAVLink) MissionPlanner detects gimbal and I'm able to switch with CTRL+X

But gimbal doesn't  receive any MAV_CMD_DO_MOUNT_CONTROL messages. When I switch to MNT_TYPE 4(Storm32) gimbal start receiving messages.

Also does autopilot send any hearthbeats? Or only GSC?

[Luis Vale Gonçalves]

Perhaps you could look at the SToRM32 gimbal controller to check what the board sends to the PixHawk. Will these boards enhance what the SToRM32's do (and for about 20usd with 2 external IMU's)?

[Randy Mackay]

Matas,

 

     Great news that you’re resurrecting this fully open source gimbal (both software and hardware).

 

     We should really rename the “MAVLink” gimbal driver to the “SoloGimbal” driver.  Although this driver speaks MAVLink, the solo gimbal is quite different from most gimbals in that the attitude estimation runs on the flight controller so the mavlink messages contain very low level gimbal IMU data.

 

     The SToRM32 gimbal driver is much closer to what I think a MAVLink driver should use so it makes sense that you’re having better luck with that one.  We can also write you a new driver specific to the EvvGC-Plus if you like.

     If you stick with the SToRM32 driver for now at least I think the gimbal will see heartbeats both from the GCS (normally sysid 255) and the flight controller (normally sysid 1) although it depends on the sys-id that the gimbal uses.  I should mention that one oddity of the SToRM32 gimbal driver is that it uses a sys-id of 71 – we probably should have instead used the sys-id of the vehicle.  The idea is that a gimbal is a part of a particular vehicle so it should share the same sys-id as the vehicle and have component id of 154 (search here for “MAV_COMP_ID_GIMBAL” http://mavlink.org/messages/common).  This was not all decided at the time we wrote the SToRM32 gimbal driver though.

 

     If you do consider changing the hardware you could also consider writing alternative (open source) software that runs on the SToRM32 gimbal hardware.  OlliW is a friend of this group and this is by no means a challenge to the great work he’s done.  I’m just suggesting that the SToRM32 hardware is a good starting point because it’s open, readily available and cheap.  There are other successful examples of open source projects (including ardupilot and the px4 stack!) that share hardware but then both compete and cooperate on the software side.  It’s your time and your choice though of course!

 

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

[Randy Mackay]

Luis,

 

     Yes, and we may have to change the SToRM32 setup instructions to ask users to change that sysid and component id – and maybe we should do that before the AC3.3 release (what do you think?).  At the moment, the gimbal driver is hard-coded to look for the SToRM32 using the sysid/component-id defaults.. but it will lead to problems in the future if for example we had two copters both with SToRM32 gimbals on the same network.  It’s currently an unlikely situation but this multivehicle setup I demo’d is an example of this:

          http://diydrones.com/profiles/blogs/multi-vehicle-testing-with-apm-copter-tracker-and-mission-planner

     If I’d had gimbals attached to two vehicles, both vehicle’s messages to their gimbals would have been acted upon by both gimbals.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Luis Vale Gonçalves
Sent: 26-Jun-15 11:05 AM
To: drones-...@googlegroups.com
Subject: Re: [drones-discuss] Re: EvvGC-PLUS gimbal software now supports MAVLink!

 

Hi Randy

 

I might not be fully understanding your consideration on the STorM32 sysid and componentid but you can change both to any value between 1 and 255.

[Matas Razgūnas]

2015 m. birželis 26 d., penktadienis 03:58:33 UTC+3, Randy Mackay rašė:

Matas,

 

     Great news that you’re resurrecting this fully open source gimbal (both software and hardware).

 

     We should really rename the “MAVLink” gimbal driver to the “SoloGimbal” driver.  Although this driver speaks MAVLink, the solo gimbal is quite different from most gimbals in that the attitude estimation runs on the flight controller so the mavlink messages contain very low level gimbal IMU data.

 

     The SToRM32 gimbal driver is much closer to what I think a MAVLink driver should use so it makes sense that you’re having better luck with that one.  We can also write you a new driver specific to the EvvGC-Plus if you like.

     If you stick with the SToRM32 driver for now at least I think the gimbal will see heartbeats both from the GCS (normally sysid 255) and the flight controller (normally sysid 1) although it depends on the sys-id that the gimbal uses.  I should mention that one oddity of the SToRM32 gimbal driver is that it uses a sys-id of 71 – we probably should have instead used the sys-id of the vehicle.  The idea is that a gimbal is a part of a particular vehicle so it should share the same sys-id as the vehicle and have component id of 154 (search here for “MAV_COMP_ID_GIMBAL” http://mavlink.org/messages/common).  This was not all decided at the time we wrote the SToRM32 gimbal driver though.

I tired but gimbal doesn't receive any heartbeats unless I select gimbal in mission planner (Via CTRL-X). Does Pixhawk expects heartbeats particularly from SToRM32 to resend GSC messages?  

 

 

     If you do consider changing the hardware you could also consider writing alternative (open source) software that runs on the SToRM32 gimbal hardware.  OlliW is a friend of this group and this is by no means a challenge to the great work he’s done.  I’m just suggesting that the SToRM32 hardware is a good starting point because it’s open, readily available and cheap.  There are other successful examples of open source projects (including ardupilot and the px4 stack!) that share hardware but then both compete and cooperate on the software side.  It’s your time and your choice though of course!

 

-Randy

How I haven't thought about this. This probably means I will have to start writing hal layer to support different boards :) For now I don't have too much time to work on this, because now I'm working on GSM telemetry for ardupilot.

[Luis Vale Gonçalves]

Randy,

I completely agree. It's better sooner than later.