1 Like
Itās not clear to me how this equipment enables development of the serial driver for the gimbal.
the gimbal uses a serial port to get its xyz position input commands from the autopilot
the autopilot gets the goggles headtracking position commands over the VTX OSD link
the headtracking position command are generated by the goggle and transmitted to the VTX
you need all three to develop and test the system
Yes. But letās step back a little.
The walksnail head tracker system is currently designed to be self contained (doesnāt pass through the autopilot), with manual/autopilot control available via pwm if you want it. This is obviously intended to simplify integration across any flight stack/configuration, as itās completely agnostic.
Iām not against developing an alternative so that you can use the autopilot as a mitm, but the request, as per your heading, is to support implementation of the gimbal serial protocol, from the autopilot. This has nothing to do with head tracking or goggles or the walksnail vtx. Just the gimbal. But you havenāt asked for the gimbal.
It seems like youāre jumping to stage 2 without doing stage 1 first: the requested hardware doesnāt actually support the stated purpose of the request.
As an extra question: what protocol does it use?
the second item includes the 3 axis gimbalā¦
the gimbal can be controlled several ways, it has PWM inputs and it has a serial input.
-In the simplest case it can connect its PWM inputs to an autopilot conventionally for manual control via RC inputs to servo outputs
-on output poor autopilots (many copter targets) it can connect to a UART on the autopilot (we would need a driverā¦the point of this)
-it can connect to the VTX directly for this head tracker goggle (they will update all AVATAR google including the high end ones) but then the autopilot cant send OSD overlays, so we can develop code to take the Display Port back channel flow which has this data, and then send it out either PMW or Serail (with the new driver) to the gimbal
so we need a gimbal serial driver and then an extension to DisplayPort to get the headtracker data and route it to outputs or gimbal serial input
and once I get the protocol details from CADDX (or reverse them from iNAV) we may be able to also send the serial gimbal data over a servo output (like serial LED) and give people the option to use only one servo outputā¦maybe
also I a waiting for response back from CADDX R&D on if they are willing to give AP some or all of the aboveā¦but I have a friend that has worked with them and they are a bit fickle when you dont have a jillion Youtube subscribers
i have the gimbal i cloned you branch @hwurzburg i will try to build and test it soon
@hwurzburg Iād like to continue the work you started a couple of months back. Did you use something specifically for inspiration on how it should function?
Edit: nvm, I just saw your comments.
Here is the PRā¦ our Mount lead has a gimbal on the way and he is going to debug the driver I wrote soonā¦the driver uses iNavs gimbal driverās packet format and CRC so it should be working, but it has an unknown issue that I cant resolveā¦but Randy will soonā¦he done many gimbal drivers for AP
Whatās the issue, if Iām not overstepping? I can help debug it, as the quad with the gimbal connected is next to my desk.
doesnāt seem to be sending info to the gimbalā¦
Weāve got some kind of issue with the either the gimbal itself or with the format of the packets weāre sending to it from ArduPilot. Iāve received the packet format from Caddx and Iām pretty confident that Iām sending what the gimbal wants but it never responds.
I think the gimbal needs to be running version 3.4 (which can be downloaded from here) and the gimbal I have has an older firmware.
One reason to think this is true is the release notes which are with the firmware
My next steps are to get the USB->Serial converter and 3pin cable so that I can run the configuration software and check the gimbals version
@rmackay9 I have a USB TTL lying around (and a Windows VM apparently), Iāll update it to 3.4 and try the code again. Did you make any changes to @hwurzburgās branch?
thats strange since I have an older version than yours and it works fine with the CADDX moonlight VTX and goggles L doing headtracking and mode changes via the moonlightās serial port from the goggleā¦
@rmackay9 @hwurzburg we have liftoff (pun intended) with gimbal firmware V3.4! Please excuse the mess. I guess I need to setup the deltas in config, but otherwise it works. Iāll check out whatās marked as TODO in the code.
@hwurzburg mine also worked when sending the gimbal commands through the VTX (from the headtracking goggles), but sending them through your code, directly from the FC didnāt. It seems v3.4 was needed.
Now we only need to figure out how to read the headtracking info from the Goggles. Reading the iNav pull requests, the data is sent via the VTX messages somehow (Iām a beginner, mind the misused terms). We can pick those up and setup an RC switch for headtracking / manual control.
1 Like
How does one configure the gimbal position in the neutral RC position? Currently, the gimbal points forward when the RC signal is at minimum value, when it should point forward when at mid position. Is this configurable in ArduPilot or do we need to change the formulas in the code?
Edit: nvm, thatās what trim is for, itās perfect now. Whatās missing from the implementation in your opinion?
1 Like
Hi @blahlex, @hwurzburg,
Thanks very much for testing! This is fantastic news that itās basically working.
Iāve created a simplified version of Henryās PR here. This is rebased on master to resolve the merge conflicts in Henryās PR and it also:
- removes new aux switch feature to control the various new lock methods
- replaces the packet structure with a more manual method that will surely work on all platforms (I think the structure method may not work on Linux for example)
- simplified CRC calculation
There are some more things we need to do:
- angle reporting doesnāt work. I think the gimbal provides feedback but Iām not sure yet
- add back in HenryWās aux switch changes
Re the head tracker, I suspect this should be part of the CADDX driver. I would have thought that it was a new type of pilot input and should be fed into a separate autopilot serial port and would then work with all gimbals, not just the CADDX.
Anyway, the original work in HenryWās though so he and I should decide how we want to proceed. I was primarily trying to get the sending of angles working. my programmer should arrive within the next few days so Iām looking forward to that!
Hi @blahlex,
Iāve created a PR now which builds upon HenryWās PR and Iāve tested and it seems to work.
No pressure of course but if you have a chance to give it a try thatād be great. Confirmation from others that it works will help speed the changes into master (and then 4.6 hopefully)
@rmackay9 your PR works perfectly as well, I just built and tested it. I havenāt tried changing mount modes though.
1 Like