Base plates with integrated power-through are available for the gimbals. Otherwise the cheaper option is to hack the mount, and supply 4s lipo direct to the gimbal.
I’ll make sure to create a hack guide, if the first control-through-ardupilot tests are successful
I would like to support your development.
I have an older version of the Ronin Gimbal, the Ronin-SC, very lightweight and cheap.
I could send you that Gimbal (from Germany) or I could support you with some money to buy a new version.
Thanks very much for the offers! It looks like one of the original requesters is going to loan me the hardware for the initial development at least. Assuming that goes well I might ask you to help me with testing.
We’ve received a list of models that use the DJI R SDK protocol (which I hope to write a driver for) and it looks like it is only the RS2 and RS3 Pro (not even the regular RS3). So a much shorter list than expected.
My RS2 has arrived and I’m surprised to find that the DJI Ronin app is required but is not available through the google store. I’ve installed it manually from the .apk file on the DJI site (link to Japan DJI download area is here) and it seems to be working OK.
Did you only get the gimbal or the entire kit (ie the wifi image transmitting module RavenEye) ? And mine is the RSC2.
I haven’t spent much time on the technicalities of the RSC2/RavenEye as it just works…
At the moment there are no plans to support the DJI Osmo 6 (or similar) hand held gimbals because they have a very different interface from the DJI RS2/3 gimbals. I had a quick peek at the Omno 6 instruction manual and it appears they only provide a bluetooth interface (and we have no documentation yet on this interface) while the RS2/3 have a CAN interface.
Of course, if we somehow find information on the interface to these others gimbals I’m happy to try and write a driver for it.
A quick update is that I’ve gotten as far as wiring up the gimbal to an autopilot. So below is a picture of the wiring of an autopilot’s CAN port to the gimbal’s Ronin-S Focus wheel. This focus wheel attaches to a 6-pad port that is hidden under the foam grip. I wonder if it would be possible to directly use the gimbal’s 6-pin pad but in any case, the focus wheel is not terribly expensive and has a convenient 4-pin CAN connector on the bottom.
I am trying to control the RS2 Gimbal exactly like the DJI Assist app with Force Mobile via Bluetooth.
The RS2 Gimbal has one Bluetooth service 0000fff5 which receives and executes the command, I want to send continual write commands to control the movement of gimbal. I managed to find the UUID that performs a recentre and what makes it go to the right, left, up and down using a Bluetooth sniffer and Wireshark in between the DJI Assist app on an Android phone and RS2 to identify the service and the UUID or hex being sent to the RS2.
Device Service:
WRITEABLE WITHOUT RESPONSE service UUID (0000fff5-0000-1000-8000-00805f9b34fb)
I was wondering if you would help me discover if there is a correlation between the DJI R SDK Protocol and User Interface hex commands and if they are sent by the DJI Assist App via Bluetooth service above to the RS2 to control it.
You have experience via the CANBus side of things and thought you could help shed some light here.
Yes, unfortunately the DJI RS 3 Mini does not look like it has the interface needed for the CAN communication. However, even though “only” 2 of the Ronin gimbals could be used for this project, the ease of use and quality of these gimbals really out-perform anything else I have worked with. I have used the RS 2 gimbal small cameras (Sony A6000) and large 100MP cameras and it worked great for stabilizing both - so the use case is very broad.
A small update on progress writing an AP driver, I’ve connected an autopilot to the gimbal (see pic from me back in November) and using this lua script I can see CAN packets from the gimbal but their format does not match what I see in the SDK.
Here’s an example of one message
CAN1 port, FrameId:1062 len:8 0x55 0x45 0x4 0xDE 0xE5 0x6 0x13 0x03
All that I can make sense of so far is the start-of-frame packet appears to be 0x55 and the last two bytes are a sequence number (e.g. it increments with each message).
The most serious problem I face at the moment is that the SDK describes a serial protocol while the gimbal uses a CAN protocol. The SDK discusses how the gimbal should be connected to a CAN<->Serial adapter but still, it seems odd to me that it would add this extra step.
Anyway, I’m slowing plugging away at this… it’s just a bit harder than expected.
