Better documentation on Pixhawk controllers RPI integration

[dimon777]

Hello,

Current documentation is not adequate/suitable to connect Pixhawk broads to RPI companion computers, esp. to people without strong engineering/electronics skills. There is absolutely no clarity on what pins on TELEM2 port should go to what pins on rpi GPIO. Instead documentation deals with wiring TELEM2 and FTDI and other well known topics of SSH and WIFI setups. There is ardupilot docs over there with much better explanation and pictures but we are PX4 here. Can we take on this? We should have at minimum:

• Schematics to connect v2/3/4/5 connector designs to RPI GPIO
• Options for powering FC and RPI
• Tools to test connectivity between board and PRI and vice versa
• QGroundcontrol reference how to configure board to talk to RPI
• Reference how to configure RPI to talk to board via mavlink
• Simple testing for the setup (ex: od -x < /dev/serial0 and observe raw mavlink output)
• Simple python snippet showing how to connect to Pixhawk from RPI
• Links to other topics like RPI peripheral equipment use

Thanks,
Dimon.

[hamishwillee]

IMO it would certainly help if the docs could be more "end to end", in particular to wiring and power. Note though we're a bunch of volunteers - this was what someone learned, you can add to it if you discover more. I will help you.

@bkueng Can you please review my comments and the stated problem AND/OR suggest someone else who might advise? I've not done this, so it is hard for me to comment on the sufficiency or otherwise of this doc.

Schematics to connect v2/3/4/5 connector designs to RPI GPIO

My understanding was that the FC connected to the RaPi via an FTDI cable. That's a serial to USB-serial converter - which would plug into the RaPi USB port.

Options for powering FC and RPI

FC should be powered as usual (ie as if companion wasn't there). I would imagine RaPi would be powered off a separate BEC. I would not power the RaPi off the FC unless you want it to die.

Tools to test connectivity between board and PRI and vice versa

Yes, something for this definitely good. Obviously you might use MAVSDK to connect, but would be good to have something low-level.

QGroundcontrol reference how to configure board to talk to RPI

This one is complicated, because there are so many ways of doing it. The implied setup from docs is to use mavlink router https://dev.px4.io/v1.9.0/en/companion_computer/pixhawk_companion.html#companion-computer-setup to forward to QGC.

Reference how to configure RPI to talk to board via mavlink

The easiest way would be MAVSDK. But we should indeed say that.

Simple testing for the setup (ex: od -x < /dev/serial0 and observe raw mavlink output)
Simple python snippet showing how to connect to Pixhawk from RPI

I think this is MAVSDK. You might be able to use PyMAVLink or something more lightweight, but you'll end up with ROS or MAVSDK anyway to do real work.

Links to other topics like RPI peripheral equipment use

Sure.

[bkueng]

@Jaeyoung-Lim can help here.

[RicardoM17]

I second this. We had some issues with the documentation to setup our RPis here too. In fact I still maybe am to open an issue on the FTDI not working but I have one last test to do to confirm it and no time yet. (Right now we have a direct serial connection between Pixhawk and the GPIO of the RPi).

The good news is that I can also help by contributing on this.

@hamishwillee your comments seem good to me. That's roughly what we did.

[hamishwillee]

@RicardoM17 If you can help with this, that would be awesome - not much point me trying to add docs without having real setup or practical experience.

I think @dimon777 points on the main issues are well taken. What can I do to help you progress this? I'd recommend doing it in bits Ie start with powering sections, then the serial link etc.

[RicardoM17]

@hamishwillee I guess first we should start by defining the location of such documentation.

Perhaps a complete tutorial like I helped in https://dev.px4.io/master/en/ros/mavros_custom_messages.html ?

However stuff like the wiring can be on a subsection of https://dev.px4.io/v1.9.0/en/companion_computer/pixhawk_companion.html just for Raspberry Pi?

Lastly on my end I am running Mavros on the Pi which culminated in flight testing of a slightly modified version of https://dev.px4.io/v1.9.0/en/ros/mavros_offboard.html which I also wanted to push somewhere. Imo there should be a working model somewhere for people to build and run. That example is no longer incomplete as it doesn't have the entire package, it is very dangerous! Namely the fact that it's very hard to regain control of the drone from Offboard. But I digress. I can also create a separate issue/PR for this.

[hamishwillee]

@RicardoM17 I'd rather avoid a tutorial. Generally a tutorial is great if you have one path you always want people to take. But IMO RaPi is just one option, and there is no need to push people down that path.

So I see an update to https://dev.px4.io/master/en/companion_computer/pixhawk_companion.html , primarily for wiring.

My assumption is that Pixhawk side is always very similar. You set up power, you wire a serial port using an FTDI cable, and you config the UART you used (in this case TELEM2) for MAVLink. So with respect to what is already there, we'd pull the pixhawk bits together under a Pixhawk section, and add a section on powering.

For the companion, my assumption is that the things that need to be covered are powering, connecting the serial port, basic testing of the connection, then installing the main software stuff - mavros/mavsdk/mavlink router.

It isn't clear to me how "common" this is for different systems. What we want to do though is pull as much of the common stuff as possible into a common section, then underneath have specific sections for different companions - e.g. RaPi. I *hope" that the general stuff can be offloaded to other docs - e.g. setting up MAVROS.

Anyway, we'd start with power and wiring. For powering that might be as simple as saying that you have to separately power the companion, that typically this would be done off a separate BEC (?). We might provide more direction in each companion-specific section.

For the serial connection I assume you just wire the other end of the FTDI cable to something (?) ... or do you just plugin to a USB port? In any case, this can probably be covered generically.

re-reading, the above, I think that makes sense. Is it enough to get started? Firstly by clarifing the powering and wiring story?

[physicsman]

I can help out a bit on the trial/error side and some writing.

[Jaeyoung-Lim]

@hamishwillee With the RPi or other comapnion computers that have a native UART available, you can hook the TELEM port directly to the UART pins. If this is worth documenting, I can write something up specific for the rpi series

[RicardoM17]

@hamishwillee Sounds good yea. I will start a WIP PR soon and ping you all there.

The fairly simple stuff like the RPi powering should be in there fairly quickly.

[hamishwillee]

@Jaeyoung-Lim

With the RPi or other comapnion computers that have a native UART available, you can hook the TELEM port directly to the UART pins. If this is worth documenting, I can write something up specific for the rpi series

Yes it is please. We need to try cover:

1. which instances of the series support this.
2. How you'd do the connections
3. How you connect/reference the RPi side port.

I'd be happy for that to be a separate PR if it is hard for you guys to collaborate. I can pull the bits together.

[hamishwillee]

@RicardoM17

Sounds good yea. I will start a WIP PR soon and ping you all there. The fairly simple stuff like the RPi powering should be in there fairly quickly.

Thank you very much. I've very happy with quick gains!

[Jaeyoung-Lim]

@hamishwillee Thanks, I will try to get this done this week.

@dimon777 In the meantime you can look at this article I wrote a while ago.

[physicsman]

I think the current draw limits for the FMU and RPi should be addresses. I know for my NXP FMUK66 there are limits and the RPi exceeds them.

[hamishwillee]

You shouldn't be drawing any power out of the FMU, ever.

[physicsman]

You shouldn't be drawing any power out of the FMU, ever.

For the Lidar Lite I was following the manufacture recommendation of powering the sensor separately which means two signal wires and common ground go to the FMU and the +5v from the BEC is only connected to the sensor. I’m not sure why since peak power is listed as 130mW, but, they also recommend a 680uF in parallel to handle spikes which I had installed. I’m wondering though, when the device is first powered on that 680uF acts as a direct short to ground, would that hurt the FMU or possibly devices connected to it since it shares a ground with the FMU through the I2C connector?