Visca protocol #8814
Visca protocol #8814
Conversation
|
I've just read the script of the devcall of yesterday, sorry I couldn't assist. I totally agree with the ideas you said there. In fact I thought on integrating it into AP_Mount at first, but I thought maybe you wouldn't agree to it. In fact I am also "polishing" a bit the alexmos protocol, because I am working on a video tracker based on raspberry pi 3, and I would like to integrate it all as a afordable solution for a "serious" payload on ardupilot. I used to work on something like that on a private company and I would like to share it to the open source as there is nothing similar right now. I also don't like the use of a whole new k_parameter because of this, I would be much neater inside AP_mount, and use AP_mount as a "full payload" I also thought on doing it inside the AP_Camera, but as it is now it is mostly for mapping, so that's why I thought on a new library. In any case, let me know the final decision about this and I will happily commit the necessary changes. Thanks, regards. |
|
thanks for getting back to us. I think moving it into AP_Mount as a new backend type is the right way to go. If you don't mind re-working it that way that would be appreciated |
|
Sure, right now I am on vacations, but as soon as I get back I'll work on it. Thanks. Regards. |
|
@tridge , I am again back from vacations and working on this, but I have to ways of aproaching it. If I define a new AP_Mount_Backend_Camera base class, and I inherit a particular Visca class from this one, which would be the neater solution, I need to modify a bit the AP_Mount class, because right now AP_Mount uses pointers to AP_Backend for working with all the different kinds of mounts (Alexmos, stm32...) and if I define a new Backend for cameras, I need to implement in AP_Mount this new pointer to AP_Mount_Backend_Camera for handling this. The other approach I have in mind, is make the Visca class inheriting from AP_Mount_Backend, as this class has most of the virtual methods I need for impement visca. The drawback of this, is that AP_Mount_Backend also has lot of methods refering to angles and such that I won't be using on Visca, and overall wouldn't be as neat as a new backend just for cameras. Please tell me which one of them you consider more appropriate, as I am not as familiarized with ardupilot for considering which one of them would be best, regarding memory usage and such. In both cases I would need to add a few parameters on the AP_Mount group, I hope it is all right. Thank you. Regards. |
|
I like the 2nd approach, making AP_Mount_Visca inherit from AP_Mount_Backend. If when you do it you find it gets all too messy then jump on mumble to discuss with one of the core devs |
note that there is a way to have params for a particular backend. See the AP_BattMonitor for an example |
|
Didn't know that about particular params for each backend, I will take a look. Thank you very much, I'll work on it. Regards. |
|
We're just waiting on @Davidsastresas to address some of the issues mentioned above.. |
|
I am sorry, I've been on other face of my project related to computer vision this last weeks. Just let me a few days and I will implement the changes requested by Tridge and Amilcarlucas. I've done a rebase to the branch and I will keep contributing the changes on the next few days. Sorry for the trouble. Thank you, regards. |
Davidsastresas
force-pushed
the
Visca_Protocol
branch
from
9c3cb1c
to
07e939c
Compare
Davidsastresas
force-pushed
the
Visca_Protocol
branch
from
07e939c
to
7e581da
Compare
Davidsastresas
force-pushed
the
Visca_Protocol
branch
from
c911b1f
to
9aa2281
Compare
Davidsastresas
force-pushed
the
Visca_Protocol
branch
from
9aa2281
to
6f0fab6
Compare
|
I've made a clean in the commits history because it was getting messy with all the undos. Right now has the same functionality as before all this changes, just supporting direct control zoom, +, - and stop zoom. I plan to add support for progressive zoom ( proportional to channel value ) and mavlink mode, with new mavlink messages and all, but by the moment is functional. I've moved it as another mount, inheriting from AP_Mount_Backend as suggested. The changes to the AP_Mount.cpp and .h have been minimal, so I think it is quite clean. I looked at the suggestion of @tridge of parameters for each backend as batt monitor, but, correct me if I am wrong please, that would require a bigger change in AP_Mount, as for making it clean I think would require to implement that idea of parameters for each backend for each current backend, not just for Visca, so probably the cleanest thing to do it would be to add another Mount_Parameters class or something like that. Right now It just needed 2 new parameters, and I don't thing it is gonna need much more. I've written this parameters under MNT2, so in the regular code, with MAX_INSTANCES = 1, the two visca parameters are not used. In any case, using this kind of high end zoom camera doesn't make sense without a gimbaled payload, so I think it will always work as secondary Mount. I didn't implemented the changes requested by @amilcarlucas as right now all the code is contained within AP_Mount, it is no longer under arducopter files so I wasn't quite sure of where to put the "IF VISCA_ENABLED == DISABLED". Right now, it could work putting the VISCA_ENABLED == DISABLED on Mount.h, most code related with visca would not be compiled but there would be small aditions under SerialManager that will remain, just the default baudrates and the enum kinds of serial and that. I wanted to ask you first about how to put this, if you consider all right to put VISCA_ENABLED == DISABLED on AP_Mount.h I will make the necessary changes, also if you consider another better approach please let me know and I will work on it. Also I wanted to ask, there are a pair of methods on AP_Mount_Visca.cpp that are inherited from abstract methods on Mount_Backend, that needed to be defined because they were pure virtual, but aren't going to be used by Visca. I've put on them just a "return" statement, and I've handled the parts of AP_Mount.cpp that makes a call to this method to not call it in case it is a Visca mount. I am not quite sure about this, I would also appreciate feedback on this. Also if you consider something should be different please let me know and I will work on it, I have still little experience on Ardupilot and hopefully after a few more contributions I will need less guidance, but right now I would appreciate all the suggestions you can made. Thank you. |
this SPI bus on this board can't handle 8MHz
the RCIN issue is not there in the final production boards
when we are looking for FPort input, we normally switch UART3 on the IOMCU to 115200 to look for inverted inputs at 115200 baudrate. We need to disable this switching when we have SBUS output enabled to prevent a change in the SBUS output baudrate Many thanks to afishman for finding this bug Fixes ArduPilot#15522
this fixes an issue seen on one board which caused a watchdog on high uart DMA load. We have reproduced the issue on another board by forcing a very high DMA transfer rate on the same DMA channel while also requesting very high transfer rates on the UART. The likely race is in the DMA transmit timeout code, and the simplest fix is to lock out interrupts during the DMA setup to ensure the tx timeout cannot trigger during the setup
…() and handle get_mount_type(), not supported by visca
… add to enum SerialProtocol
Davidsastresas
force-pushed
the
Visca_Protocol
branch
from
d1c6737
to
e7a0466
Compare
|
needs rebase and no action since 2018 - if it doesn't get reworked after this prod, i propose closing it as abandoned. |
|
If there is still interest in this I can re do it over updated master. Please confirm me it is of interest for the project and I will proceed. |
|
Iam still interested in this and would like to have a firmware with visca control for matek f405 ctr flight controller. Iam myself in the rapid response drone group where we use a lot of ptz camera on drones and controlling them is a nightmare sometimes, hope this project gets merged Thanks again for all contributors, have a good one 👍 |
|
I no longer have access to visca equipment, and I don't know how soon I will be able to test the rebase of this, so I think it is better to close it for now. Thanks and sorry for the trouble. |
Support for cameras using visca protocol, like the popular sony fcb block cameras. update rate in the scheduler has been set to 3 hz. By the moment it supports a 3 position switch for zoom+, zoom- and stop zoom.
For configuring in autopilot, select serialx protocol to 18, and baud rate according to the camera's one.
select VSC_CTRL_CH with the channel number of the switch desired for zoom and VSC_CTRL_MODE = 0 (default).
I plan to add in the next days support for more operation modes, and more useful mesages as day/night mode IR filter on/off, digital zoom enabled/disabled.... As well as update the wiki for the users to be able to use it.
This is my first contribution to ardupilot, I've tried to make everything as required in the wiki and according to the rest of the code I've seen, but please let me know if I need to change anything to fit in the existing code.
Regards.