I’ve been working on a rover project, and have been struggling. I have managed to get my RPI 4b connected and running drone engage, and accessible with the web client. I can view video, etc.
I am trying to mate a Mateksys F405 V2 wing FC to it.
I have installed the Ardupilot firmware on the FC, and can connect to the FC via USB on mission planner.
My FC is connected TX/RX and GND to the RPI, (TX to RX, RX to TX), and I have tried quite a few settings in the drone engage software, but I have not yet been able to connect to the FC with the RPI.
Any ideas or help on how to troubleshoot this? Ive had a hard time finding useful info on the Mateksys setup.
What settings/parameters do I NEED to change on the flight controller, using mission planner software, in order for it to communicate over serial with my Raspberry pi?
And those are the only parameters needed for comms to work?
I’ve tried that, and revisited numerous times, on all of the available serial ports.
I’m really at a loss as to what it could be, but, I don’t know the tools to be able to troubleshoot it. Seems like it should be something simple, but I can not find anything incorrect.
No idea. I don’t use that software. But I’m reasonably confident that it communicates via MAVLink to the companion computer, which makes those parameters the only relevant ones.
I’ve set Serial 7 in the FC parameters up as the Mateksys info states- BRD_ALT 1 (Also tried 0), Protocol 23 (Which is RCIN) ,( Also tried 2 for Mavlink)
Serial7 should be TX2/RX2 pins on the FC.
I’ve set the port to use in the Drone engage software to ttyUSB2.
(Noting that I cannot see ttyUSB2 when I use ls - /dev/tty*. I think not seeing it listed when that command is run means its not communicating, but I don’t know how to dig into that further. It was suggested I try “cu” commands, but they seem not supported.)
23 is wrong for sure. SERIAL7 may be a bad choice because it’s intended for RC protocols that are sometimes inverted logic. BRD_ALT_CONFIG,1 is correct if you wish to continue attempting to use SERIAL7.
And the Pi’s hardware serial port is usually /dev/ttyAMA0 or /dev/ttyS0. Sometimes it’s even sym linked as /dev/serial0 (I think…going from memory on that one).
No. The Pi has one serial port, and it is /dev/ttyAMA0. I would bet a fair amount that the /dev/ttyS0 that you’re seeing is actually sym linked to AMA0.
The Pi has no way of knowing that you chose SERIAL7 and will not re-index the tty structure.
Interesting. I wonder why there are configurable options then. That will be a good question to ask the creator.
Are you familiar with the Mateksys fc? I should confirm the USB connection I have tried isnt incorrect. I’ve tried USB C from pi4 “power” to USB C on the FC.
I’m familiar with autopilots like that one but have not used it. The options exist to cover all possibilities - yours is not the only use case. You can try connecting via USB, but it’s typically ill advised to use that method in flight (I forget exactly why, but I think it’s to do with the power pathway).
You can try using screen, minicom, or picocom to view the serial traffic on a given port. It will be largely non human readable, but a few clues should breeze by in the stream. A command line tutorial to audit serial traffic is beyond the scope of this topic, but there’s enough info here to get you started on a web search of the subject.
I would also suspect excessive wear on the USB port. I remember hearing about the software doing some things related to safety a bit differently when connected through the USB. Logging can be configured to be disabled when powered through USB.
I did manage to find a log section that gives a bit more insight to whats going on-
While trying to edit the Mavlink.config file, I had a syntax error that I couldn’t tell. The logs showed it was failing to run and called out the line in code, so I was able to fix. I’ve tried alot of options, AMA0, S0, USB everything, but all say fail to open port.
I’ll keep plugging away I suppose, atleast I found more info!
I went back to giving S0 a try with the newfound ability to see realtime in the logs what was occuring, and it works!!
I now have RPY displayed on the web client. Now I can move on to trying to figure out how to get my motors/servo functioning from the FC, hopefully that part is pretty easy.
