to conclude things from my side:
A) I wish to seriously apologize for any wording which may have been considered insulting. I do however stand to the contents.
B) I’d like to share my findings about Solo and STorM32 (copying from PMs), just in case it may be beneficial:
I got the smart shots working on ardupilot-solo1.5.3 or at least for cablecam/multipoint at the moment; it needs some changes in the .py files, which I have only done momentarily for mulitpoint.py. It is not yet working perfectly, because the ardupilot AP_Mount class for StorM32 sends the mount control to the gimbal only every 1 sec when in mavlink_targeting, so the pitch is quite stepy. It’s easy to correct. I think I know very precisely what needs to be done, in arducopter-solo.
This video I did some days back:
Ugly, I know, but it shows a two point cable cam with camera interpolation in pitch and yaw. This is with stock cube, arducopter-solo 1.5.3, Solo App, and works with any STorM32 (it needs adaption of the smartshot .py’s, but that’s needed anyhow, and is simple since it’s just drag&drop). It clearly shows that everything is working fine except of these “pitch jumps” every 1 sec. This is obviously due to the fact that arducopter sends out a message to the STorM32 only every 1 sec when in MAVLINK_TARGETING.
There are various different approaches one can take, from very simple to “smarter”, depending on preferences, and how much one would be willing to invest.
The most simplest solution would be to simply change the define AP_MOUNT_STORM32_RESEND_MS from 1000 to e.g. 100, or maybe even 50. https://github.com/OpenSolo/ardupilot-solo/blob/master/libraries/AP_Mount/AP_Mount_SToRM32.h#L23
Alternatively one could insert a “resend_now = true;” in here https://github.com/OpenSolo/ardupilot-solo/blob/master/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L61
One could do somewhat better. One could e.g. add a uint16_t _counter and emit a message every 5th or so update. Or one could e.g. track the last angle values, and trigger a send then they have changed. This would reduce the workload to what is needed. Or one could add a bool _anglesupdated which is set whenever a new angle is set, so that the update() knows of it. … Each of these would be few more, but straightforward lines, which I could provide. Many, simple options, one just needs to decide.
If one wanted to, one could also discuss weeding out other issues (for each I could provide code). E.g. a proper handling of the has_pan_control() flag. As I see from the shotmanager .py’s Matt also stumbled across the fact that ArduPilot does not suppress a yaw pan of the camera, as it is supposed to when has_pan_control is false. This discussion would be benefitial also for any future ArduPilot versions (3.6).
I think the simple changes to avoid the 1sec pitch jumps would already be a significant step forward.
To give … an idea of what we are talking about, a code suggestion
AP_Mount_SToRM32_new_lastmethod.zip (3.3 KB)
One can trace my changes by searching for //OW. I here choose the “track changes” approach, since it affects only the two files (the “anglesupdated” approach would need also changes in the backend) and yet it should be good a keeping the traffic low. I also added the suggestion for dropping the yaw response in case of has_pan_control = false, which will work for Solo in mavlink targeting, but I’m not 100.00% sure if it’s correct in all possible situations.
Would these changes apply to ArduCopter master too? I’m not sure. ArduCopter master has some additional issues/bugs not present in ardupuilot-solo, and some of them I just can clearly “see” but do not see the origin in the code. That’s why I’m only talking about arducopter-solo.
Master has some additional issues. I have looked carefully at the mavlink messages which the STorM32 receives, and in master the routing definitely makes it get additional messages. Unfortunately, from looking at the code it is not at all clear to me why this is so. And there are further issues. So, I don’t think that one can simply extrapolate from ardupilot-solo to master.
In addition to the changes in ardupilot-solo, one needs also changes in the smartshot manager’s .py files. That’s mostly because ardupilot-solo uses the “old” mount messages while master uses the “new” mount messages, so there is no way out (unless one would backport the “new” messages to ardupilot-solo, which one probably doesn’t want to do). In the course of that I’ll also clean up the py codes a bit, which will remove some few bugs&inconsistencies. I’ll certainly provide these files too. They’re easy to “install”, they just need to be copied over to Solo. The bottom line, without these files it’s pointless trying to test the new .px4.
One unavoidable consequence will be that one needs different .py files for arducopter-solo and for master (I’ll abstract it to a point that it is a change in only one place). Or: there is a means for the scripts to detect which version is installed, and to adapt itself to this. The latter I have not yet figured out however.
15.Dez.-20.Dez.