I have been working with Gremsy to improve AP’s support of their gimbal and it’s at the point where I’d like to get feedback from any willing beta testers on the improvements.
- Startup message displays the gimbal hardware and software version (appears about 10 sec after startup so it is slightly easy to miss)
- “Mount Lock” auxiliary switch option allows the pilot to specify whether the gimbal should maintain a body-frame heading or an earth-frame heading while under pilot control. Set RCx_OPTION = 165 and pull switch high to “lock” to earth frame heading
- MNT_ANGxxx parameters are defaulted to the gimbal’s angular limits (set using gTune). Note that if you’ve already set this manually this defaulting will have no effect.
- DO_GIMBAL_MANAGER_PITCHYAW command supports specifying angles in body-frame or earth-frame
- Smoother movement during pilot input especially when using rate control (e.g. MNT_JSTICK_SPD param is non-zero)
- Gimbal motors are turned off if the gimbal is set to RETRACTED mode
How to Setup:
Download and install Gremsy gimbal firmware 7.7.1 (or higher) on your gimbal. Please note that you may need to re-calibrate your gimbal afterwards
Using gTune, confirm the the “REDUCE DRIFT by DRONE” for “PAN AXIS” is enabled as shown below. This causes the gimbal to consume the autopilot’s attitude information so that it knows “earth frame” (e.g knows where true North is)
Install “latest” ArduPilot firmware on your autopilot using MP’s Firmware Install screen (press Ctrl-Q to switch to “latest”)
Configure ArduPilot as described on the wiki but with these changes:
- set SERIALx_OPTIONS = 1024 (“Don’t forward mavlink to/from”) to stop the autopilot<->gimbal mavlink traffic from being forwarded to the autopitot<->GCS link which can overwhelm it
- set MNT_TYPE = 6 (Gremsy)
- no need to set SRx_xxx parameters
- set MNT_JOYSTICK = 100 if you want to control the gimbal’s attitude using rate control (e.g. RC stick inputs will control how quickly the angle of the gimbal changes)
- set MNT_RC_IN_PAN, ROLL and/or TILT to the RC channels you wish to use to manually control the angle of the gimbal
- set RCx_OPTION = 163 (Mount Lock) to allow controlling whether the gimbal locks on an earth-frame vs body-frame heading when under pilot RC control
How to test:
- Set the Mount mode to “RC Targeting” and confirm the gimbal moves correctly with RC input.
- Pull the “Mount Lock” auxiliary switch high and confirm when the vehicle is rotated, the gimbal stays locked onto the earth-frame target. Next pull the “Mount Lock” low and confirm the gimbal rotates with the vehicle
- set the Mount mode to “RETRACTED” and confirm the gimbal relaxes allowing the camera to be moved by hand
- Right-mouse-button-click on the Mission Planner map and select “Point Camera Here” and confirm the gimbal points in the correct direction
- Setup an Auto mission with DO_MOUNT_CONTROL with roll, pitch (-ve is down, +ve is up), yaw angles. Switch the vehicle to Auto and confirm the gimbal points in the correct direction. Note that if the command is the first command it will run without the vehicle being armed. Set MIS_RESTART=1 to force the mission to be re-run from the first command whenever the vehicle is switched to Auto mode
- Setup an Auto mission with DO_GIMBAL_MANAGER_PITCHYAW (use “Unkown”, “1000”). First column is Pitch angle (-ve is down, +ve is up), 2nd column is Yaw
Of course please be careful with this firmware because both the AP firmware and the Gremsy gimbal firmware are works-in-progress and haven’t gone through the normal beta testing that we do before stable releases.
BTW, I’m also happy to look into other gimbal issues people are facing and perhaps I can resolve some of these as follow-up changes to the Gremsy driver changes.
For reference the Pull Request for this change is here.
Any chance this would work with the MIO?
Yes, it works with the MIO as well. Sorry I didn’t include a link to the MIO v7.7.1 firmware but I have now.
this is great I have been hoping gremsy would get some support as they are one of the only gimbal suppliers with a nice range of sizes! I will be testing this at the end of the month currently out on a assignment.
Ok, so I’ve got the preview firmware installed on a Gremsy MIO and loaded the customized ArduCopter build onto a Cube Orange. I built this from the rmackay9:gremsy-driver2 repository since the link in the original post doesn’t appear to be live.
I can see the startup message, so communication between the flight controller and gimbal should be configured properly. Though I can’t seem to control the gimbal at all - RC targeting and “Point Camera Here” have no effect. Setting the mount mode to “Retracted” doesn’t disable the motors either.
Any thoughts as to what I may have missed?
Txs very much for giving it a try and sorry about the firmware link. I’ve fixed the link now.
My guess is that there’s something on the gimbal side that’s causing the problem. For example even though it’s clearly communicating over MAVLink it’s still taking target angles from the RC.
I wonder if maybe upgrading the firmware has wiped all the parameters from the gimbal and it won’t move at all. Could you perhaps try controlling it with a regular RC somehow? I guess to do this you need to change Settings, Controls to “SBUS”
By the way, on my PixyU, I’ve got the Settings, Controls set to “SYNC”.
I’ve asked my contact at Gremsy to test with the MIO.
Thanks Randy, looking forward to seeing if Gremsy has better luck.
I think you’re onto something regarding a gimbal-side issue. If I revert the parameters and mount type to support the MAVLink control I was using previously, there’s still no response from the MIO that’s been updated to the preview firmware. I popped in another MIO that’s still on an earlier release and that works fine.
I didn’t see anything in the updated gimbal’s settings that looked like it was wiped or reverted at first glance, but I’ll keep digging in the meantime.
We have several T3v3’s in regular use with AC. I can’t offer to help test beta firmware on these machines sadly, but it’s great news this is being worked on.
Does anyone know if it’s possible to read the current angles from the gimbal, rather than just setting them? e.g. if controlling pan / tilt via a separate SBUS receiver, is there any way of getting the mount angles on the ground station?
With 4.1.5 <= ArduCopter <= 4.2.1 you can use the mount_control.cpp mavros plugin (master) to do that. It reads controlls the setpoint and reads back the current angles and publishes errors on the ROS diagnostics topic.
But you do need to keep it MAVLink only, no SBUS.
With the new Gremsy driver the gimbal’s actual angles (not the targets) are sent to the GCS using the GIMBAL_DEVICE_ATTITUDE_STATUS message. I don’t know what will happen if you try to control the gimbal with a separate RC though.
Getting ROS involved to retrieve the actual angles seems like a long way around to me. It looks like the SToRM32 mavlink driver doesn’t retrieve the actual angles but there’s a to-do in the code to do it so I’ll take care of that after we complete this Gremsy driver.
@juzzle1 You can take a look at our gSDK based on MAVLink.
To control gimbal with external RC and keep MAVLink connection to retrieve gimbal attitude, you need to set gimbal to rc input
@amilcarlucas @rmackay9 @Minh_Le Thanks for your replies. This level of integration is really fantastic!
@rmackay9 It seams like the mavlink stream from the gimbal currently prevents GCS failsafe triggering.
I think I have a fix locally, will post the results later
Thanks very much for the feedback. It is certainly possible that a new MAVLink device could cause the GCS failsafe to not trigger. If there’s an issue I don’t think it will be related to this new driver but rather an existing issue.
For example, here’s what I see from MP’s mavlink inspector and there are a lot of devices so the SYSID_MYGCS and SYSID_ENFORCE parameter probably need to be set in order to ensure the vehicle’s GCS failsafe isn’t fooled by, for example, the Herelink receiver which would keep sending heartbeats even if I disconnected Mission Planner or powered down the herelink transmitter.
EDIT: I see you’ve raised a PR here and it does look like an existing issue and there are various solutions we can discuss on the next dev call.
We merged the Gremsy PR this morning so within a few hours testers can load “latest” to test. if using MP, go to the Install Firmware screen and press Ctrl-Q, then confirm the version displayed below each icon is 4.3.0-DEV and then push the icon to install.
Hi all, anyone else have a chance to test this PR on a MIO yet?
I’ve ping’d the Gremsy developer … he’s been fixing other little issues so I hope/expect he’ll get to this soon-ish.
People have probably already seen this but in any case, here’s a demo of what is in “latest” (aka “master”, aka “Copter-4.3.0-DEV”) on a Gremsy. By the way, this should work for all gimbals AP support (PWM, AlexMos, SToRM32, etc)
The next enhancements planned are:
- Lua scripting support
- Improve gimbal attitude reporting to the ground station
- dual gimbal support
- support for more types of gimbals
- GCS enhancements to ease gimbal control by the operator
I am running some bench tests on a Gremsy T3V3 and a CubeOrange. I have managed to get the gimbal to connect & mount to the Cube. Using MP I can also make the gimbal ‘look’ at a target using the ‘Point camera over here’ command so the AP talks to the Gremsy gimbal.
The issue I am having is the ‘Set Mount’ commands in MP appear not to work for me. This is probably linked to the Gremsy not showing up in the Mavlink Inspector as MAV_COMP_ID_GIMBAL. The Gremsy does show as ‘Mounted’ in the messages window.
Does anyone have a suggestion what could cause this and how to resolve the issue?
Thanks very much for giving this a try!
So it’s the “Set Mount” button that you’re trying to use I think. It may not be clear but all this does is change the gimbal’s mode using the drop-down just to the left of the button.
So for example, if you set it to “Neutral” it will simply move to the body-frame angles specified by the MNT_NEUTRAL_X (=roll), _Y (=pitch) and _Z (=yaw). Or if you set it to “RC Targeting” you should be able to move the gimbal round using the channels specified by the “MNT_RC_IN_xxx” parameters.
By the way, the intention is that “Retracted” mode will relax the gimbal but Gremsy hasn’t made the update to accomplish that yet.