Issue details
I am having a problem controlling my Storm32 gimbal using the software payload controls (Mission Planner and QGroundcontrol)
I have tried the Mavlink config and the serial config, followed OlliW and Ardupilot documentation to the letter multiple times, cannot find a resolve for my issue in the forums, I would really appreciate any help on this. The strange thing is, someone was testing something using this autopilot while I was out of town and somehow changed the ardupilot FW to a VTOL TILTROTOR config and I didn’t realize it until after I got the gimbal working so when I wanted to go flight test the gimbal I noticed this, changed it to the Quad-X config through Mission Planner and now it doesn’t show any love no matter what I do to the parameters.
@rmackay9 Here is the post as you requested. An update on this, I’ve made some progress this morning this is definitely shouts as an Ardupilot issue to me because I changed a parameter, rebooted and it got stuck in an odd state ( I will attach a screen shot of this state) and had messages showing that it was talking to or at least recognized the Storm32 Board and I could control the gimbal through the payload control tab but when I rebooted again and all the normal things came up, the messages about the Storm32 are not there and I can no longer control the gimbal. I only get the “(MOUNT_x) is deprecated” messages when I attempt to move the gimbal. Also I changed the firmware back to 4.3.3 because thats what version it was when I had it working.
I had a peek at the tlogs but they’re almost completely empty. Actually Tlogs in general are not very useful, it’s the onboard logs that really help. Can you please download an onboard log from the autopilot? You may need to set LOG_DISARMED = 1 in order to create a log while the vehicle is disarmed. If the vehicle is armed of course then that’s not necessary.
@rmackay9 Sorry it’s been a couple days but I solved my own issue. I looked back at a video I filmed with my phone to show the gimbal working and video streaming down to the GCS and I realized I was on Arducopter v4.2.3 when I originally thought I was on 4.3.3. I still cannot get any version of 4.3 and later to work over UART or serial and the only solutions I come across are servo/RC controlled and I’m trying to fly without my RC controllers. @xfacta I have read through that thread and I have done the same thing on 2 different mRo APs that were(at one time) configured identically because I was flying them as a swarm.
I will give the double reflash method another try on a spare AP and see what happens, in the mean time my issue lies in Arducopter v4.3 and later. Maybe something about how he switched to rover specifically makes a difference because it’s not an air vehicle but that’s just a guess. @OldGazer If you could share what settings you have, anything that’s outside the ardupilot/storm32 documentation it would be greatly appreciated.
P.S. I’ve been very deep in Ardupilot lately and have several projects going so I’ll probably be here a lot lol but I really appreciate everyone’s help and insight.
Regards
Thanks for the feedback. Based on my recent experiences I believe the core of the problem goes much deeper. As a case in point, over the weekend I encountered a problem with a SIK radio and a MavLink OSD sharing a telemetry port. I had 3 platforms setup this way and all three were affected. The symptoms are the OSD will not display any data and the telemetry radio “hangs” during parameter download. As for gimbal control, Mavlink targeting does not work at all. RC Targeting is totally inaccurate and is prone to drift in Yaw. Oddly enough Mount Pitch does not seem to be affected. Another bad behavior is that going back to center from a Left or a Right Yaw the mount does not always return to center. I am not sure if this makes any difference, but the radio I am using is a RadioMaster T16S running the latest version of EdgeTx. Later today I will switch to a FrSky Tandem X20 and see what happens. If this behavior persists then it is obvious the fault lies with this version of ArduCopter.
OK, did some testing. I st my X20 up with the exact channel assignments of the T 16S. I bound my X20 to my Hex. Every thing worked including Mavlink Targeting. So I’m thinking the radio was the culprit… I powered down the Hex and turned the X20 OFF. I put the RC receiver in bind mode and bound the T16 to the Hex. Mavlink targeting did not work. I powered every thing down. I set the Hex receiver to bind mode. I powered up the X20 and bound it to the Hex. Mavlink targeting did not work.
One other behavior I noticed was SIK radio connections were not reliable causing parameter downloads to hang, and Set Mount, Set RC Targeting, and Set MavLink could not be executed.
Owing to the fact that Mavlink Targeting did work and then it didn’t leads me to believe that data corruption may be why things are going south and my primary suspect is in the serial port handler(s) in the firmware itself. The reason I believe this is the fact that not only are there new issues with SIK radio and OSD serial port sharing, there are also issues with the SIC radio connection.
So, I intend to wipe this Pixhawk again and flash an earlier version. If that works then 4.3.7 is bad…
@OldGazer I appreciate this information, I unfortunately won’t be able to test on my end for a couple weeks as I’ll be out of town for work but there seems to inconsistencies no matter what. I’m working a 1 watt telemetry radio that is incredibly robust so that hasn’t been an issue for me but the 4 different firmware versions all came up with different issues biggest one being that in 4.3.7 it doesn’t work at all.
I’m going to state a few things just to better understand You’re set up and use case. Correct me if I’m wrong on any of the following;
-You’re using your X20 and T16 to fly your vehicle and control your storm32 gimbal simultaneously.
You’re using a Pixhawk AP and sharing a telemetry port.
-Ardu firmware v4.3.7
-Controlling the Storm32 through UART from an AP telemetry port.
-MNTx_TYPE = 4 (Storm32 Mavlink)
-when you have it working you can use RC targeting and Mav targeting.
Have you ever tried over serial?( MNTx_TYPE=5 )
The OSD devices use Mavlink1 and the telemetry radios (preferably) use Mavlink2 so they should ideally be on two different serial ports.
You can still run them together by setting the port to Mavlink1 - the default was recently changed to Mavlink2 because the only thing using mavlink1 was the old OSD units.
SERIALx_PROTOCOL 1 or 2
Mavlink2 has many newer messages and functions over Mavlink1, and this may even be the source of the Sik radio problems since even more features now rely on Mavlink2.
OK, I think I have finally figured this gimbal problem out.
The key points are to make sure you have the mount type set to 5 (SToRM32 Serial), the servos and RCs are set to mount yaw and mount pitch as appropriate, and the serial port is set to 11500 baud, protocol 8 (gimbal).
I have my Tandem X20 setup with a Pot on Channel 10 for yaw and a slider on Channel 9 for camera tilt.
I have been testing this for the last couple of hours and every thing works, RCTargeting, MavlinkTargeting and Retracted.
@OldGazer That’s great to hear, I’m away from home currently but I plan to try this as soon as I get back. The Arducopter page talks about the UART control as if it’s not a serial connection so maybe that was my issue the whole time. Not sure if it’s a typo, misnomer or just misunderstood but what your saying makes perfect sense.
I might have to open another topic for this but it’s still under the same subject. You’re using an RC transmitter to control the gimbal, have to you tried with a gamepad or anything that doesn’t deal with individual servo control for the gimbal?
Like I said all I have over RC is a single kill switch that I use to either terminate or RTL for safety but otherwise I’m trying to build this as an almost entirely autonomous system and using a gamepad control would be great.
@OldGazer
Is you’re RC transmitter plugged into mission planner via USB and you control it through a telemetry radio or do you have an RC receiver onboard you’re vehicle with PWM connections to the RC input ports on the Storm32?
I am using an RC transmitter that is bound to a receiver. The receiver has an SBUS output that is connected to the SBUS input of a Pixhawk. The gimbal is connected to a serial port on the Pixhawk. My ground station is connected to the Pixhawk via 915mHz telemetry transceivers.
