Why does pitch get reversed for storm32 gimbals?

Hardware
,
13

this doesn’t make any sense to me

first, I think we MUST know for which combination of ArduCopter firmware version and STorM32 firmware version a certain observation is observed. Otherwise discussing a observation is useless.

I say this because I know for a fact that there had been combinations of ArduCopter and STorM32 for which the behavior was not at all like you describe, and in fact were working (except maybe that some signs were not correct). Sadly I can’t say myself which combination(s) this had been, since that’s quite some time ago when I did that testings. I also might not have tested the serial well, so I may speak only for MNT_TYPE 4, but I do speak for at least one MNT_TYPE.

I thus do not think that the above is a representative reflection, but either is maybe a Solo issue, or something important has changed in ArduPilot in the last year (I remember e.g. that a year, or was it 1 1/2 years, ago, with Mavlink2 coming, all sorts of problems occurred because the Mavlink2 implementation wasn’t fletched out, don’t know what has happened since then and if that ever was weeded out, Francisco/Oxinarf and Luis/Lvale had been involved in that discussion at the time)(I also remember that about the same time - at the request of ArduPilot devs - I made the recognition of Mavlink messages more flexible, conforming to the “standard”).

Your bullet 2 I would think is a smoking gun demonstration of a bug (or several) in the ArduPilot firmware … with STorM32 heartbeats disabled it really doesn’t do much. You probably could disconnect the STorM32 and would see the very same malfunctions.

Also bullet 1 should make you wary.

Btw, you know that you can disable the emission of the STorM32 gimbal attitude data, which would allow you to test your speculation in bullet 1.

Again, you maybe want to try betacopter and see how it does.

I think one also should settle on one MNT_TYPE and concentrate on it first.

My 2 cents. :slight_smile:

14

Which setting should they disable to stop the attitude data? Also, is leaving the mavlink system and component IDs default correct?

15

the parameter “Mavlink Configuration” can be set to “no heartbeat”, “emit heartbeat”, “heartbeat + attitude”. Set it to “emit heartbeat”.

I think that the default system and component ID are correct. It might in fact be that they have to be set to the default values, there might be some implicit dependencies in ArduPilot/MissionPlanner/… I’m not sure.

Generally, it’s a long while ago that I’ve played with ArduPilot’s STorM32 mounts, so answers to related questions, such as the previous paragraph, may or may not be correct. I think that e.g. Luis/lvale knows everything about it. Maybe you want to get his opinion too.

16

@LuisVale, any ideas on this?

17

On an off topic question, does anyone know where you can get the NT Storm with the motor controller /Encoders pre-wired?

18

so, I was curious now and did some bench testing, using a pixracer and a STorM32, and MissionPlanner. The firmware in the pixracer was ArduCopter 3.6 dev (so not Solo!).

many things work as expected, but not all, I’m not sure it’s correct or wrong though

first, I have to say that in some recent firmware version a bug has crept in, which makes the serial hang up as soon as the mavlink heartbeat is enabled. Will be corrected in the next version, and should not be present in somewhat older versions.

I connected the STorM32 to serial3, which I’ve set to 115, protocol 1. I did when basically 5 test, where in each test I tried the available settings for the parameter “Mavlink Configuration”, namely
"no heartbeat"
“emit heartbeat” (called hb in short)
“heartbeat+attitude” (called hb+a in short)
“h.b.+mountstatus” (called hb+ms in short)

1. STorM32 directly connected via a USB-TTL adapter to MissionPlanner, MNT_TPYE = 0

all three options hb, hb+a, hb+ms work as expected, that is:

  • MP recognizes a gimbal and connects,
  • one has access to the STorM32’s parameters
  • with hb+a the HUD shows the correct behavior, and with hb+ms the campointa/b/c fields show the correct behaviors

:slight_smile:

2. STorM32 connected to pixracer, pixracer to MP, MNT_TPYE = 0, Mavlink ID = 1, 67

all three options hb, hb+a, hb+ms work as expected, that is:

  • MP recognizes a QUADROTOR-1 and a GIMBAL-1, and connects to both
  • when GIMBAL-1 is selcted one has access to the STorM32’s parameters
  • when GIMBAL-1 is selcted when with hb+a the HUD shows the correct behavior, and with hb+ms the campointa/b/c fields show the correct behaviors

:slight_smile:

3. STorM32 connected to pixracer, pixracer to MP, MNT_TPYE = 0, Mavlink ID = 71, 67

all three options hb, hb+a, hb+ms work as expected, that is:

  • MP recognizes a QUADROTOR-1 and a GIMBAL-71, and connects to both
  • when GIMBAL-1 is selcted one has access to the STorM32’s parameters
  • when GIMBAL-1 is selcted when with hb+a the HUD shows the correct behavior, and with hb+ms the campointa/b/c fields show the correct behaviors

:slight_smile:

These tests I did to see if the STorM32’s Mavlink communication is basically correct

4. STorM32 connected to pixracer, pixracer to MP, MNT_TPYE = 4, Mavlink ID = 1, 67

once the pixracer has booted I can see a lot traffic coming from the STorM32, so the MNT_TYPE 4 must make it send a lot (no problem by itself)

things work nearly as expected

  • for all three options hb, hb+a, hb+ms MP recognizes a QUADROTOR-1 and a GIMBAL-1, and connects to both
  • when GIMBAL-1 is selwcted one has access to the STorM32’s parameters
  • with hb+a: the HUD of GIMBAL-1 shows the correct behavior
  • with hb+ms the campointa/b/c fields of GIMBAL-1 do move, but not those of QUADROTOR-1

the latter I find unexpected. I would have thought that when a mount is a component, that then its mount_status message would be recognized by QUADROTOR-1. The MNT_TYPE 4 does not emit a mount_status message to the QUADROTOR-1, so this would have appeared as the logical expectation.

EDIT: I note that 1 to 1 1/2 years ago this was working as expected, and was the reason for the option hb+ms. This allowed e.g. to see the MP’s gimbal point in the map !!
I probably have misinterpreted this, and this is the intended behavior for a Mavlink mount.

  • with “no heartbeat” I do see six ‘e’ coming from the STorM32, which means that it has received 6 characters from the pixracer. It’s not a disaster, but certainly not good as messages should only come from the pixracer once a valid heartbeat has been seen on that channel.

5. STorM32 connected to pixracer, pixracer to MP, MNT_TPYE = 4, Mavlink ID = 71, 67

once the pixracer has booted I can see a lot traffic coming from the STorM32, so the MNT_TYPE 4 must make it send a lot (no problem by itself)

things do NOT go well here:

  • for all three options hb, hb+a, hb+ms, MP cannot connect to either QUADROTOR-1 and a GIMBAL-1, it timeouts with the complain that just one heartbeat message was received.

not sure if that is the correct behavior.

  • with “no heartbeat” I do see six ‘e’ coming from the STorM32, which means that it has received 6 characters from the pixracer. It’s not a disaster, but certainly not good as messages should only come from the pixracer once a valid heartbeat has been seen on that channel.

fin

You may want to try to reproduce that with a solo

I would conclude that the best bet is to use ID = 1,67 (and not 71,67). Since no mount_status is send to the flight controller, it’s pointless to set anything higher than hb.

I finally note: The info in the wiki, http://ardupilot.org/copter/docs/common-storm32-gimbal.html, and in here, http://ardupilot.org/dev/docs/code-overview-adding-support-for-a-new-mavlink-gimbal.html, differ in the Mavlink system ID. It seems that in this regard indeed something has changed in ArduPilot some time ago.

1 Like
19

one note I forgot:

it’s also a while ago, but I believe to remember that in the code I found a mechanism which can block/modify the Mavlink communication in some ways - there is a related variable. I also believe to remember that I found it to be used by the Solo mount. At least I have a marker in my brain which says “Oh, they had to play dirty tricks with the Mavlink for the Solo gimbal”.

It might be worthwhile to track that down, as it could indicate that there is a fundamental difference between how Mavlink works for a Solo gimbal, and any other gimbal.

hope all that help you guys to better track down your issues :slight_smile:

1 Like
20

so, next step, I’ve analyzed in more depth the code for the STorM32 Mavlink mount (AP_Mount_SToRM32.cpp/h).

First, I looked up how the STorM32 handles messages, depending on the target systems and component IDs (as relevant for the MOUNT_CONTROL msg).

  • It accepts messages when
  • the msg has no target system
  • the msg has a target system = 0
  • the msg has a target system = gimbal system and a target component = 0
  • the msg has a target system = gimbal system and a target component = gimbal component
    Otherwise a msg is not processed.

EDIT: Note, that these rules hold for the latest firmwares, not for v0.96! The rules for v0.96 are given in post 50.

I firmly believe that’s the correct behavior.

Then I looked up how the gimbal system ID should be set, that is if it can be “any” value such as the default system = 71, or should be set to the ArduPilot’s system = 1. As mentioned before, there is a conflict in the wiki. From the code, in agreement with the wiki entry on Mavlink Gimbals, it should be set to system = 1. With system = 71, the RC_TARGETING and GPS_POINT modes would work, but not the MAVLINK_TARGETING mode.

Conclusion, set STorM32 System ID = 1.

The crucial point to note is that in the RC_TARGETING/GPS_POINT modes and the MAVLINK_TARGETING mode the MOUNT_CONTROL msg is fundamentally differently treated. In the former two cases a MOUNT_CONTROL msg with target system = STorM32 system ID and target component = STorM32 component ID is send to the gimbal, irrespective of the values of the IDs. However, in the MAVLINK_TARGETING mode the msg from e.g. a GCS must be both processed locally and routed to the component.

So, I looked up the processing and routing rules (https://github.com/ArduPilot/ardupilot/blob/master/libraries/GCS_MAVLink/MAVLink_routing.cpp or http://ardupilot.org/dev/docs/mavlink-routing-in-ardupilot.html). I considered cases that ArduPilot receives a MOUNT_CONTROL msg target system/components of {0,arbitrary}, {1,0}, and {1,gimbal component}. I noted that the rules do NOT cover the case {1,0}. So I checked with the code and from
https://github.com/ArduPilot/ardupilot/blob/master/libraries/GCS_MAVLink/MAVLink_routing.cpp#L126
it is clear that no target component and target component = 0 are treated equivalently, as expected by common sense.

Conclusion, the descriptions in https://github.com/ArduPilot/ardupilot/blob/master/libraries/GCS_MAVLink/MAVLink_routing.cpp or http://ardupilot.org/dev/docs/mavlink-routing-in-ardupilot.html are incomplete, and should be adapted.

The msges with {0,arbitrary} and {1,0} would be locally processed and routed to the gimbal, as it should be. The msg with {1,gimbal component} would NOT be processed locally but routed, which means that here MAVLINK_TARGETING would not work. This is probably the intended behavior, but I’m not convinced it’s the best intention. I don’t know with what target the Solo smart shot is sending the MOUNT_CONTROL msg to the gimbal, you guys may want to check this, but as much as I can tell this in general looks ok to me.

I’d like to recall that even when the STorM32’s heartbeat is disabled, some data bytes are send to it. From the processing and routing rules this should not happen.

Conclusion, there is something up in the ArduPilot code. Not critical, but.

Lastly, I looked very carefully at the -± sign handling. And as mentioned before, there is indeed a bug in the STorM32 code: For the MOUNT_CONTROL msg it does NOT do the sign changes internally, as it is supposed to do. This bug must have been there since a long, long time but showed up only know. In the AP_Mount_SToRM32 code this bug was handled for the RC_TARGETING/GPS_POINT modes by explicitly doing the sign change, but for the MAVLINK_TARGETING mode this didn’t work (since in this case the MOUNT_CONTROL msg is not handled by the mount).

Conclusion, there is indeed a bug in the STorM32 code with the result that in the MAVLINK_TARGETING mode pitch (and yaw) is treated with a wrong sign. THX Pedals2Paddles !!!

ToDo:
In the next STorM32 firmware version this bug will be corrected. At the same time, these three lines should be deleted:
https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L138-L140
Maybe anyone would want to place a corresponding PR (I can’t do PRs).

The disadvantage of this (correct) solution is that users of the old I2C-based STorM32, which is limited to the old firmware v0.96, would find their gimbal to not behave correctly anymore.

Thx for pointing me to this bug!
I would be glad to hear if that resolves the issues you have seen with Solo&STorM32.

Btw: For the STorM32 serial mount this reversed-pitch issue should not be present. So, you guys may test/use this. As mentioned before it has the bug that the MOUNT_STATUS message has uncorrected angles. One could correct this by placing the two “-” sign into the 1st and 3rd lines here
https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Mount/AP_Mount_SToRM32_serial.cpp#L273-L275

Cheers, Olli

1 Like
21

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

22

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

23

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 … ?

24

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.

25

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
26

@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:

27

Following.I’ve got loads of Solos and not enough gimbals. :grinning:

28

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.

29

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

30

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.

31

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

32

@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?