Hi,
was anybody able to make this board to communicate with pixhawk via sbus?
I see some instructions here:
http://www.olliw.eu/storm32bgc-wiki/Configure_the_RC_Input#S-Bus
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?
Replies
Hi,
could anybody get new beta 82e firmware on Storm32 board to work reliably?
I get problems with a properly done tune as soon as I activate imu2 to 'full'. it starts vibrating where it worked before, cannot figure out why.
I generally wonder what is an overall perception of this 82 beta - is it worth to spend more time to make it tuned or would it be better now to revert back to 80 primary version as it seemed to be working more or less ok for me yesterday?
I sincerely believe that you can achieve good answers if asking at the SToRM32 thread at RCG.
Just a casual note: 0.82 is a beta version and as such requires correct testing and some debugging and reporting to Olliw.
If you can't, or want to "suffer" the pains of beta versions stick with the release versions.
I used tarot solutions and bgc before and never had that many issues to deal with.
OlliW is obvuiosly quite proud of what he makes but he is not able to provide any meaningful support not troubleshoot issues his boards produce. It was pretty much a huge waste of time compared to how older BGC boards work and what can be expected.
I spent probably 5 times more time trying to tune that storm32 board compared to old bgc board and it still acts erratic at some angles. And OlliW, sorry, seems to act mostly as a jerk. He is seemengly consumed with some other ideas he pursuits, what happens with software for current boards and current horrible tuning approach, he does not seem to care at all.
So I've tested and confirmed that the MAVLink communication still works fine with SToRM32 firmware v080. Sadly the serial interface does not seem to work. Seems like it's been broken somewhere between SToRM32 v070 and v080.
I know it is too many questions :) but what is your long term vision for 2 way communication between pixhawk and gimbal controller?
So far gimbal was only a consumer of data, what kind of data may be needed to be commnicated from gimbal controller into pixhawk?
Paul,
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.
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".
-
1
-
2
-
3
-
4
of 4 Next