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!
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
Following.Iāve got loads of Solos and not enough gimbals.
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