Why does pitch get reversed for storm32 gimbals?

Thank you Olli, looking forward to finding one of your new T Boards some day

Hi Olli!
I was reporting those issues with the heartbeat on that drives the solo crazy.
That solo is a stock one with the black cube and stock solo firmware (the last update).
And the Storm32 firmware was the last one (I
Updated two weeks ago)
I noticed the solo send unneeded mavlink messages through the serial port. Iā€™m a Completely noob about mavlink but I guess they are unnecessary because they are messages for other components, really donā€™t know if it works that way.
I also noticed the Storm32 responds to anything it receives. And when it receives something it doesnā€™t like it responds with the ā€œeā€™sā€ you mentioned.
On startup the solo sends a ā€œ0 0 0ā€ string to the gimbal before the first mavlink message (and its not a mount related message) so maybe that ā€œeeeeā€ response is what causes some problems.
I just fount a workaround, since the solo sends the MAV_CMD_DO_MOUNT_CONTROL no matter if the gimbal sent a heartbeat or even if itā€™s connected. Iā€™m just pluging the TX cable (TX from the drone) to storm RX and gnd. And the droneā€™s RX to a 3.3v pin on the Storm32 so the drone doesnā€™t receive anything. And it just works, the drone is happy.
I also have to say I have not experienced the reversed pitch issue, and itā€™s working with manual paddle and smartshots.

My question is If I upgrade to greencube and OpenSolo. Maybe this might not work anymore?

BTW that board is INSANE man! The second imu is a bless. Thanks for your time which is the most valuable thing a man has

[edit] In mission planner mount type is set to 4 (Storm32 mavlink) and serial protocol is set to mavlink1 the serial port is SERIAL 4

I noticed the solo send unneeded mavlink messages through the serial port. Iā€™m a Completely noob about mavlink but I guess they are unnecessary because they are messages for other components, really donā€™t know if it works that way.

if the target of these messages is broadcast then IMHO thatā€™s how it is supposed to be
(itā€™s btw the way why I stopped to support Mavlink officially, since when there are more components all sorts of crazy thing scan happen; I consider that a bad design)

I also noticed the Storm32 responds to anything it receives. And when it receives something it doesnā€™t like it responds with the ā€œeā€™sā€ you mentioned.

I donā€™t think thatā€™s correct. When Mavlink is enabled things are processed by the Mavlink parser, and responses are only in accordance with Mavlinkā€¦

The eā€™s can (should) happen only when Mavlink is disabled (= no heartbeat), since then all supported commands are digested. That is, if a valid Mavlink would come in, it would be digested by the Mavlink parser. So, the eā€™s mean that something was received, bu that this neither was a valid Mavlink nor any other valid message.

The point here is that with Mavlink disabled (= no heartbeat) the STorM32 doesnā€™t send out a heartbeat,. and that thus ArduPilot should not have assigned a channel yet ā€¦ thatā€™s at least my current understanding of it is supposed to work.

BTW, I did NOT use a Solo but a pixracer, the firmware was thus ArduCopter 3.6dev ā€¦ I corrected the above post to make that more clear.

I also have to say I have not experienced the reversed pitch issue, and itā€™s working with manual paddle and smartshots.

thatā€™s actually what confuses me, some reports report this, some donā€™t ā€¦ ?

Thanx for your answers. Now I understand better whatā€™s going on.
So the gimbal will understand mavlink messages even with mavlink turned off, that is great and itā€™s working for me.
About the pitch reversed, maybe itā€™s because the Storm32 is not really in mavlink mode with the heartbeats off. I can do a quick test tomorrow turning it on and see how it behaves.

I think this could be the smoking gun we have been looking for. Our problem was with implementing fully automated smartshots, not manual rc tilt commands. RC targeting has always worked fine with the Storm32 and our large Solo quad. I spent countless hours changing IDsā€™ and mount types like you did above, with same results.

It was only when performing a fully automated smartshot we observed the gimbal tilting opposite of what it should have been. When the camera is pointed forward the Mission planner reported the tilt angle at 90 degrees like the solo transmitter. However, when we would give a command to tilt the gimbal straight down to 0 degrees, as displayed by the Solo transmitter, the Mission Planner would report it as 180 degrees when the camera was pointed straight down.

Again, when using the paddle and moving the tilt manually the camera is pointed up and down as desired. It was only when performing an automated smartshot we observed the tilt going in the opposite direction desired.

More confusing though, when performing a ā€œPoint Camera Hereā€ within Mission Planner, the gimbal would point the camera to the region and height above ground specified, correctly! Message handling/type?

If fixed, we can have full solo functionality on almost any platform. Combined with Solex, youā€™ve got a DIY dream machine with almost any camera!

1 Like

@Israel_Bonilla

So the gimbal will understand mavlink messages even with mavlink turned off

yes
you also could send Mavlinks through e.g. the USB
note that the Mavlink setting affects only the UART port, then Mavlink is enabled, then the UART will only accept Mavlinks, and reject any other data, all other ports are unaffected, and will do their best in digesting the incoming data
note also that with Mavlink disabled the STorM32 wouldnā€™t send heartbeats, so that other Mavlink devices may fail to recognize it (and ArduPilot is supposed to note route it)

About the pitch reversed, maybe itā€™s because the Storm32 is not really in mavlink mode with the heartbeats off.

I donā€™t think so. In my understand this was a bug in the treatment of the MOUNT_CONTROL message, which would be processed in either way

@cthill24
letā€™s hope this solves it

note pl that you also need to modify the code in the STorM32 Mavlink mount

I once read this 180Ā° paddle thing, but didnā€™t understand it (Iā€™m not a Solo user). Iā€™m not sure if itā€™s the same thing because this did read to me as if it could be an issue of how to count angles, e.g. Ā±180Ā° vs 0ā€¦360Ā°. But as said, I donā€™t understand it :). Letā€™s hope the best :slight_smile:

Following.Iā€™ve got loads of Solos and not enough gimbals. :grinning:

Well for me it makes sense that the pitch values needs to be reversed. Because, looking at the numbers, tilting the solo forward (nose pointing down) the angles on the Storm32 are positive, but in the solo they are negative, again this is with the black, stock, cube and the 3dr firmware. Maybe with the new greencube and open solo firmware those numbers now are positive as in the Storm32.

I think most of the conversation and work going on is for the green cube and master
not so much the stock cube and outdated 3dr firmware

Ok, today I did some storm and solo serial testing. Since Iā€™ve been on green cube Iā€™ve been using STORM32_SERIAL FOR MNT_TYPE. For some reason STORM32_MAVLINK didnā€™t work, and on stock cube this is verse versa. But Iā€™ve been having GPS issues with green cube using storm32 serial(very unstable). So looked in mission planner and gave mavlink2 a try under SERIAL4 PROTOCOL and it worked. So I tried changing the system ID to 1 but gimbal didnā€™t respond. It has to be 71. Did a short flight to see how stable solo was and I was surprised to see it was very stable. Not sure if my system is messed up, but to use storm32 mavlink on a green cube you have to use mavlink2 on serial 4 protocol. I will do a test for smart shots later to see if the pitch is reversed. It wasnā€™t when I was on stock cube but it could be different now.

It would be really helpful when you are posted an experience to add the type of Pixhawk you are using and the firmware you are using on it. Thanks

@olliw42 The two people working on this with their solos have done the following that seems to work without any malfunction or backwards axes. It eliminated all the attitude conflicts and major malfunctioning too. Storm32 set to emit heartbeat, and ArduCopter serial protocol set for mavlink 2. Why would mavlink 2 make it work properly in all respects?

Iā€™m running a pixhawk 2.1(green cube) with arducopter 3.5. Everything works on mavlink 2. Thatā€™s with using storm32 mavlink as mount type.

Thanks Jonathan that helps differentiate with the standard cubes.

@Pedals2Paddles @Jonathanhair07

REALLY ??? with MNT_TYPE = 4 ???

I would not have thought this possible. Because of exactly what I wrote here: https://github.com/ArduPilot/ardupilot/issues/7246. Is what I write there incorrect ???

Q: What had the STorM32 IDā€™s been set to?
(I repeat, it really would be helpful if always all relevant parameters would be listed, it makes it quite difficult to find ones way)

It seems I donā€™t understand nothing. Most weird.

The mavlink Iā€™d is set default. Here is a link to the video I got:
https://youtu.be/P8aWKaxsyis in the video you will see that pitch is not reversed and solo is using the storm32 to control pitch to make the cable cam smart shot work. I never had pitch issues since I starting testing 5 months ago. It seem like mavlink2 keeps the solo happy without issues, storm32 gimbal serial causes issues and doesnā€™t perform 3dr solo smart shots. Has to be set to storm32 mavlink with serial 4 protocol set to mavlink2, Baud rate is the same as before.

On another note. I played with rc pitch control while on MNT_TYPE= 4 and glad to see I can change the pitch speed and acceleration through that tab. Another solo owner and myself are both having good result with this configuration, but another owner is using a CCD3 atom imu and is having pitch reverse issues while using storm NT firmware. Iā€™m not sure what board he is using but I suggested that he switch to NT 0.96v to see if it fixes his pitch issues. Any thoughts?

I didnā€™t wanted to put that finding into doubt, Sorry if I came across wrongly.

But it really shakes to death anything I thought to now have understood.

Iā€™ve just released v2.33e ā€¦ might be that Iā€™ve broken things now LOL.

Finally a video!

there should be really no difference, absolutely not
you should compare parameters/settings carefully

Ok, Iā€™ll get him to connect to mission planner and see what we donā€™t have in common. Thanks