as well as to the STorM32 GUI…
This is why I’m so confused. Setting the serial port for Mavlink2 solving all the problems just doesn’t make sense. Not that I’m complaining about it actually working properly. But if something is set incorrectly, and that makes it work correctly, there is definitely still a problem to address 
@olliw42 the guy who was having gimbal issues got it resolved. Turns out he didn’t have it configured for serial connection but for RC control.
All very encouraging, now if I can just get that t-storm32 built somewhere yehawwww
THX
good to know
now, the only explanation I see for why it is working is that the Solo smartshoot is NOT using the MAVLINK_TARGETING mode to control the gimbal, as I was assuming. This would fit also to the fact that the STorM32 ID 71 is used, and not 1, which is kind of breaking with Ardu’s “Mavlink gimbal rules”. I find the presumed bug, reported in the above and here https://github.com/ArduPilot/ardupilot/issues/7246, glaringly obvious.
So, guys: Which messages are used by Solo to control the gimbal?
now if I can just get that t-storm32 built somewhere yehawwww
the Eagle files for the v3.3 board and v2.x motor modules have been released
at rcgroups there had been some discussion about using an assembly facility, such as e.g. macrofab. It “just” needs to be attempted by someone. Maybe if you join forces with likes such as mike_kelly etc. it could lead to somewhere. The more participate, the cheaper.
It 100% is definitely using mavlink targeting mode.
It 100% is definitely using mavlink targeting mode.
thx. This of course makes sense. So, let me ask the reverse:
Does it use anything else than MAVLINK_TARGETING mode?
For instance, when the slider on the transmitter is moved, is this translated by whatever intermediate program into a mavlink message to the gimbal, or is the mount’s RC_TARGETING mode invoked?
During normal flight modes (not smart shots), the mount mode is RC Targeting using RC Channel 6 input. That input is derived from the paddle on the controller.
During smart shots, the mount mode is mostly Mavlink Targeting. There are a few specific instances where the user is controlling the gimbal during the smart shot and it switches back to RC Targeting. But for the most part, it is mavlink targeting. The smart shot sends MSG_MOUNT_CONTROL or MAV_CMD_DO_MOUNT_CONTROL with pitch and yaw angles, ignoring RC CH6.
many thx also for these clarifications
so, the main mystery, “How is it possible that the STorM32 works at all” remains.
It is simply a fact that (up to the latest release v2.33e) the STorM32 did use it’s own angle convention in the MAV_CMD_DO_MOUNT_CONTROL message.
This I think anyone can double-check/convince her/himself of by just sending mount_control messages “by hand”. So, how the heck can all those functionalities where a mount_control message is sent DIRECTLY (i.e. bypassing the mount code as in MAVLINK_TARGETING) be working ???
I would think that’s the question to which we can boil down the discussion.
Anyways, since the STorM32’s handling of the mount_control message is obviously wrong, this got corrected in the latest firmware release v2.33e of two days ago. This probably will momentarily add to the confusion.
BTW: In order to be sure about this claim, I just double checked also with the v0.96 code.
In the course of that I realized that there are differences between v0.96, and the latest firmwares. For reference I’d just like to list some further things:
-
The attitude and mount_status messages which the STorM32 sends out uses the angles in ArduPilot convention. The v096 does only allow attitude, mount_status and streams are available only in later firmwares.
-
The handling of messages is quite different for v0.96 and latest. For the latest firmwares it is as described in post 20. For v0.96 it is so:
It accepts messages when the msg system ID is different from the gimbal’s system ID, plus if either
- the msg has no target system
- 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
It should be noted that the v0.96 response rules were set in place a year and more before the ArduPilot routing rules came to life. It should also be noted that the condition msg system ID != gimbal system ID effectively prevents the v0.96 gimbal to work as a component.
You suggest moving to a NT IMU, loading the new v2.33e firmware and it should correct issues within the v0.96 firmware?
loading the new v2.33e firmware … should correct issues within the v0.96 firmware?
yes
You suggest moving to a NT IMU,
no
I’m not implying that it would correct issues seen with Solo and STorM32. No idea about the latter. What I’ve seen so far doesn’t appear to follow a pattern.
But isn’t the v2.33e firmware for the 1.3x storm32 boards NT module required? Just trying to figure out what I should do.
yes, for using the v2.33e firmware you need an NT imu module
I want to move this back out into the forum since I think we’re homing in on solutions rather than problems now.
Looking at the flow in the code, here’s what I see:
STOCK OLD ARDUCOPTER used on a stock Solo
-
Solo smart shots send MSG_MOUNT_CONTROL to ArduCopter (Sys ID 1, Comp ID 1). Example here in the multipoint smart shot: https://github.com/OpenSolo/shotmanager/blob/master/multipoint.py#L298
-
Mavlink DO_MOUNT_CONTROL message is received here in GCS_Mavlink: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/ArduCopter/GCS_Mavlink.pde#L1831
-
Then sent here to AP_MOUNT: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount.cpp#L573
-
Then sent here in MOUNT_BACKEND: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_Backend.cpp#L45
-
Then sent here in MOUNT_BACKEND to produce angle target variables: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_Backend.cpp#L8
-
Those variables are read by the update() method in AP_MOUNT_STORM32 here. But without
resend_now = true, it only updates the gimbal once per second which makes it jumpy: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L85 -
AP_STORM32 then ultimately blasts out it’s own MAV_CMD_DO_MOUNT_CONTROL message with the angle information, to include reversing, here: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L117
-
That message is sent specifically to the Storm32 Gimbal using SYS_ID 71 / COMP_ID 67 as defined here (https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_SToRM32.h#L20)
I think the fix here is to put resend_now = true; into the mavlink targeting case of ap_mount_storm32. There’s no sense in making it only set true when a message is received, because messages are received continuously anyway. So just setting it true should be fine. That will take care of the 1 second movements on the stock solo.
Is the SYSID = 71 and COMPID = 67 what your controllers use as default values? Do people every change them to something else? I guess the only use case to change it, would be if you have two gimbals? If there is a use case to change it, we should have a parameter for SYID and COMPID in ArduCopter.
ArduCopter master is very similar
-
Solo smart shots send MSG_MOUNT_CONTROL to ArduCopter (Sys ID 1, Comp ID 1). Example here in the multipoint smart shot: https://github.com/OpenSolo/shotmanager/blob/master/multipoint.py#L298
-
Mavlink DO_MOUNT_CONTROL message is received here in GCS_Mavlink: https://github.com/ArduPilot/ardupilot/blob/6c82f7671d8643c8ba21b596f9a9a5bf56a2f367/ArduCopter/GCS_Mavlink.cpp#L1657
-
Then sent here to AP_MOUNT: https://github.com/ArduPilot/ardupilot/blob/903ef4d065129f54354b06dc7cce72fafe4b231f/libraries/AP_Mount/AP_Mount.cpp#L578
-
Then sent here in MOUNT_BACKEND : https://github.com/ArduPilot/ardupilot/blob/c808ee2f497e7a7a6d570632a3224e655b377323/libraries/AP_Mount/AP_Mount_Backend.cpp#L45
-
Then sent here in MOUNT_BACKEND to produce angle target variables: https://github.com/ArduPilot/ardupilot/blob/c808ee2f497e7a7a6d570632a3224e655b377323/libraries/AP_Mount/AP_Mount_Backend.cpp#L6
-
Those variables are read by the update() method in AP_MOUNT_STORM32 here. But without
resend_now = true, it only updates the gimbal once per second which makes it jumpy: https://github.com/ArduPilot/ardupilot/blob/903ef4d065129f54354b06dc7cce72fafe4b231f/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L75 -
AP_STORM32 then ultimately blasts out it’s own MAV_CMD_DO_MOUNT_CONTROL message with the angle information, to include reversing, here: https://github.com/ArduPilot/ardupilot/blob/903ef4d065129f54354b06dc7cce72fafe4b231f/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L75
-
That message is being broadcast to sysid 0 and comp id 0 as seen here, which also seems dumb. https://github.com/ArduPilot/ardupilot/blob/903ef4d065129f54354b06dc7cce72fafe4b231f/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L10
The only difference I see is blasting everything out to 0/0 instead of 71/67. Should this be changed to use 71/67 like it used to be? And same question as with the old version, is there a use case for making sysid and comp id parameters? It also needs the resend_now = true thing. If this is what needs to be done, it’s fast and easy for both the old ArduCopter and master.
Where in master is the problem with the yaw? That is very annoying, since I’m sure you saw I had to make it send different messages to make the yaw work.
Alright, let’s try this again… There is so much going on in this, and so many people reporting various things, that it’s difficult to keep my head wrapped around what is really going on. But I think I have at least a starting point.
-
You must set the Storm32 controller’s mavlink system ID to 1 and component ID to 67.
The default SYSID is 76, and that freaks things out. I modified the old ArduCopter FW to use 1 instead of 76 for the Storm32. ArduCopter 3.5 will autodetect that you set the gimbal for 1. -
You must set the mavlink dropdown in the Storm32 controller for heatbeat. Don’t use the other options.
The other options like attitude status really aren’t used by anything and only serve to clog the mavlink traffic up, so don’t use them. You must not set it for no heartbeat or the gimbal will not be detected. -
Must set the MNT_TYPE parameter for Storm32 Mavlink (not serial)
-
Must set Serial4_Protocol for 1 (Mavlink)
-
On the old Solo ArduCopter FW, you must set SERIAL2_PROTOCOL for DISABLED.
On the that old stuff, there is no automatic detection of mavlink channels. It is hard coded to use the second instance of mavlink on a serial port. The first instance is always going to Serial 1 for the IMX. So the next has to be the gimbal on Serial port 4. That would make it the second mavlink channel. If you enable mavlink on serial 2, that would make the gimbal the 3rd channel and it won’t work. -
On ArduCopter 3.5, it will auto-detect the mavlink serial channel, so just make sure serial 4 is set for mavlink and you’re good.
Please try this with the attached ArduCopter firmware and report results. Thx
ArduCopter 1.5.4 Solo S32 Fix.zip (489.6 KB)
ArduCopter_3.5.4_Solo_S32fix.zip (679.8 KB)
1 Like
it is sad that you had decided not to listen right away, wasting people’s time
at least you now seem to have decided to take comments seriously, sadly not yet all
you want to delete the long analysis post 4 posts back, as it contains several serious inaccuracies, as well as the settings in the last post, at least those for old arducopter-solo fw
btw, using codes of others without reference is widely considered malpractice
in the arducopter-solo fw:
- remove also the other two lines, removing resend_now at two places, as I’ve suggested
- revert the change of SYS_ID, and keep SYS_ID = 71
- as I’ve explained, the handling of the has_pan as I’ve suggested and taken over by you, should be considered experimental. It is actually not really needed at this point, and should be removed.
in order to get it working on the old stock solo, there is one further point to be solved, namely the smartshot .py files, as I’ve also explained before. I can do that myself, or we can do it cooperatively.
WHAAAAAT? Ollie, this is why you didn’t get a lot of help from the dev team. You got insulting and irate with them for absolutely no reason. And now out of the blue you’re doing it to me too. All I’m doing is trying to help get your hardware to work. Nobody is ignoring you. But you’re doing a good job isolating yourself…
-
I deleted the above posts because they’re a waste of time to read and interfere with troubleshooting. Nothing to hide. You all already read them. They also had attachments that have been superceded.
-
Nobody is stealing your code.Ns nothing going on here is widely considered malpractice. Other than. Your crazy attitude. Inline comments with your name are not allowed. There is nowhere in ArduPilot where people put their name in the comments to demand recognition. My code is all over in many places without my name. You’re welcome to do a PR if you want your name memorialized as a contributor. But you’re refusing to do that and sent me code to put in for you.
-
I asked why that haspan was needed to begin with and you didn’t answer. Since I decided put the rest of that checking in, I out the haspan in too, since I assumed you had a reason. So don’t complain that didn’t use it, then complain that I used it. Make up your mind.
-
The system ID being 1 on the old firmware is what you suggested earlier in this thread. And it’s what it should be to begin with based on mavlink standards. Unless you now have a better reason to make it 71 again?
-
If you would prefer to do all of this yourself, please feel free. There are other things I could have been doing the last three evenings than trying to fix the drivers for your controller, which I do not even own.
fact is I worked out the issue(s) and solution(s), indicated and explained them to you including code, it is you who decided to ignore comments and explanations and to jump into the wild with inaccurate codes and guide lines, and yet you appear to think that this is proper, respectful cooperation. I don’t.
I had explained the has_pan situation. It doesn’t make sense to me to respond to later questions which ignore previously given info. I have never said that the ID should be changed to 1 for arducopter-solo. What many appear to fail to see is that what is considered “mavlink standard” has significantly changed over time, and was quite different at the times of AC3.3/AC3.4 than for AC3.5 and today, which makes that argument stale.
As I’ve explained to you solving all this is not my cup of tea. I’ve also explained to you that if you feel that you do that for me that then you totally got it wrong and shouldn’t do it at all. You really can’t blame me for having spend 3 days, since if you would have taken my suggestions instead of your diversions it would have saved also you time. I too could have doing many better things in the last two weeks than trying to weed out ArduCopter/Solo issues.
Given that Solo is a dead horse anyhow, I guess we should stop this here, and advise Solo users to look for gimbals with alternative controllers.
All the best, Olli
That is all untrue. Completely.
Im not going to argue back and forth about this since you’re being completely unreasonable and insulting for absolutely no reason at all… If you’d like to contribute towards your own driver for your own controller at this point, as the saying goes: PRs welcome. Have a lovely day.
In the meantime, I will continue to work with the others in this thread and on the Facebook groups to find a working solution.