was anybody able to make this board to communicate with pixhawk via sbus?
I see some instructions here:
and I connected sbus out from PX4 to rc-0 pin. I set virtual channel configuration to SBUS.
I went to MP on pixhawk side, set BRD_SBUS_OUT=1 so it would pump out servo channels via sbus out, then set MNT)TYPE=1 for servo.
nothing works and there is no reaction on the gimbal. I am using both serial ports 2 and 3 for GPS. Port 1 has telemetry and 3DR radio on.
So I only have SBUS to communicate with this gimbal. Why it does not work?
From RCG Thread
STM32F427VI ARM microcontroller
STM32F100C8T6 ARM microcontroller
ST Micro L3GD20 / ST Micro LSM303D / Invensense MPU 6000
MEAS MS5611 barometer
New power supply based on TPS63061 DC-DC Buck-Boost
3 x UART
1 x CAN
1 x I2C
1 x SPI
2 x ADC
8 x PWM Receiver Inputs
8 Spare IO Pins
2 x JTAG connection specifically for the TC2030-CTX-NL 6-Pin cable
micro SD card holder
micro USB connector
yepper, did all that with 0 results.
what specific virtual channel on starom32 will have a control data from CH9 from taranis where I have potentiometer mapped?
in between I also tested the 0.70 and serial works with the old version. But with 0.70 I have no stable Pan axis anymore. I asked OlliW if he could eventually only rollback the serial part to 0.70, but no chance.
I looked in the changelog and eventually found the break in 0.78
- serial_transmit, remove numberofcharspercall
- serial handler massively revised (!)
Hopefully someone could get the code to 0.80.
It´s a pitty that communication protocol so often changes, also from your side. Olliw stopped the further development of the storm32 link feature because of this. Hopefully he will go on when 3.3 is final.
ok, I got it working fine from sbus directly from x8r.
for reason I cannot understand (yet) it does not work when connected from px4 sbus output. odd.
The SToRM32 gimbal's MAVLink interface is definitely a step in the right direction and it's actually already doing two-way communication but we just need to increase the number of messages that the two sides understand and make use of. So the gimbal has started sending attitude messages it seems sometime between 0.7 and 0.8 so we should enhance the ardupilot driver to consume those and send them down to the ground station so it can more accurately plot the area of the world that the gimbal is currently looking at.
I think OlliW would like faster attitude info sent from the autopilot as well so the gimbal can control itself better especially in yaw.
It`s very interesting indeed. I can see it will open a lot of possibilities...
Now if you find a way to use Serial5 port on this AUAV module I use or PX4 - it would be interesting to test it out. Can it be done in RC8, something to make this third UART useful?
I bet no one I using this Serial5 even on PX4 boards, not only AUAV x2.
it should be possible to attach a telemetry radio or 2nd GPS to Serial4/5 by setting the SERIAL4_PROTOCOL to "1" (for mavlink telemetry), "3" for FrSky telem, "5" for GPS, etc. The storm32 gimbal using mavlink must be attached to telem2 but we plan to make it detect which telemetry port it's connected to eventually. maybe that'll make AC3.3 although we're already massively behind schedule on this release.
it does not seem to work, not sure why, but I have tried and it never recognizes GPS on that UART. Is there a difference in how serial5 is used for FTDI console rather than serial4 port?
is there a way to override this somehow? I did set all other serial ports to 1 and only serial 4 to '5' so it would use it for GPS1 but it rejects to show it.
It's the issue I mentioned at a previous dev meeting about making Serial5 available, and the result was to keep it for debug. Not Serial4.
Ok, so just so we're all on the same page. Serial4 and Serial5 are squeezed together onto the same connector on the Pixhawk boards (see pin mapping here). Serial4 is setup so that if you plug a telemetry radio or GPS into that port it will work as Serial4 but without the CTS/RTS pins being available. Serial5 will likely never be made available because it's reserved as the debug port.
I've tested with an earlier version of AC3.3 that a GPS works on Serial4 and instructions are on the wiki here. I've just added the AC3.3 amendment which is to check that SERIAL4_PROTOCOL = "5" and SERIAL4_BAUD is "36".