ZP3 Flight Interface Board

Changes to be made to ZP3 Interface Dev Board:

• Change 2.54mm pin socket connectors to match Pixhawk Connector Standard (Pixhawk-Standards/DS-009 Pixhawk Connector Standard.pdf at v6xupdate · pixhawk/Pixhawk-Standards · GitHub)
• Remove ST-Link connector
• Decide on which sensors to add (if any) with EFS
• Remove LEDs?
• Add IMU

CONNECTORS

All interfaces which have a pixhawk standard connector (UART, I2C, SPI, ST-Link) except for debug (ST-Link) will be replaced with GH series JST connectors. Debug will use SH series. The rest (GPIO, ADC input, TIM) don’t have a standard, and thus will use found in COTS products or what intuitively feels convenient.

As is the case with the Pixhawk FC, only upwards-facing JST connectors will be used.

• Replace ST-Link socket (J30) with BM10B-SRSS-TB connector. This is a 10-pin upwards-facing SMT connector. It is the standard “Pixhawk Debug Full” connector. There is a “mini” version with only 6 pins, but it does not seem to have an nRST pin, which is needed for ST-Link.
  From the PX4 user guide, the following pin connections will be made:

Note: the connector-standard pdf document does not identify the location of the nRST pin, but the user guide specifies it as being on pin 9.

• UART conn (4-pin: J6, 11, 34; 6-pin: 18, 23). Using 6-pin standard telemetry connector (BM06B-GHS-TBT). On 4-pin UART, CTS and RTS are left floating.

• SPI conn (J26, 27). Replace with BM07B-GHS-TBT 7-pin connector. NSS will be connected to the SS1 pin and the SS2 pin will be left floating.

• I2C conn (J7, J12, J16). Replace with BM04B-GHS-TBT 4-pin connector.

• GPIO conn (J31, J32). Replace with BM06B-GHS-TBT 6-pin connectors (Pins 1-5 are IOs, pin 6 is GND).

• ADC conn (J28). Replace with BM04B-GHS-TBT 4-pin connectors (Pins 1-3 are IOs, pin 4 is GND).
  Jerry Tian suggested these GPIO and ADC connector replacements.

• TIM conn (J3, 4, 9, 10, 14, 15, 19, 20, 21, 22, 8, 13, 17, 24, 25, 29). Going to use a 3-row 16-pin per row 0.1” right-angle pin header. This is shown to be done by Pixhawk here.

IMU

ICM-42670-P seems like a widely available low-power option (and apparently low noise) . Need to find out the desired orientation and placement of the IMU on the board (Since it’s recommended for it to be in the center of the drone and to align expectedly with the yaw/pitch/roll axis)

EFS seems to planning to implement a standard IMU that they use for all projects so they don’t have to remake drivers as often. They have not committed to but the ICM-42688 sounds like it is likely to be the one. It is slightly more expensive than the one above but still super cheap and seems to me much more common, meaning more community support. The features are very similar between both.

During this weekly EE meeting, it was mentioned that EFS would be interested in having a magnetometer/compass as well. They also do not care as much about keeping the IMU in this project the same as the ones they are looking at. The ICM-20948 seems to be the most affordable readily available IMU that contains a magnetometer and it seems to be popular. Also, EFS may be working with the ICM-20948 instead of the ICM-42688 for their standard IMU so this should be a good choice.

Looks like we are changing the IMU again 😭😭😭. Now multiple devices is not necessarily a concern since we have discovered we can put them all on the same bus. We will use the ICM-42688-P since EFS is already using this IMU and it is commonly used for modern drones. It does not have a magnetometer but this will be added separately.

While the placement of the IMU is not critical, it should be placed as close to the center as is convenient. This way rotation will have less of an impact on output acceleration and EFS would have to worry less about factoring the offset into calculations.

The IMU should be placed according to the following image to align the axes of the IMU with the axes of the board. It should be discussed which axis is defined as forward and which side of the board is considered forward.

Having the IMU in the board is not a priority since the hardware has not been confirmed and no one in EFS has relevant experience yet to write the firmware.

EFS has changed their mind and this would be useful for future development.

The IMU can communicate with I2C and SPI. I2C and SPI already have ports on the interface board so we could potentially route these to the IMU and use jumper pins so the IMU can be disconnected when this port needs to be used. Unused pins on the STM32 are not connected to the connectors in the ZP3 schematic so these can not be used to to connect to the IMU on the interface board. Using the 61300211121 header pins since we already have the component on Altium.

Edit to the paragraph above. Daniel brought up the fact that I2C and SPI are bussed protocols. Therefore they do not have to be disconnected from the connector and both can be used at the same time. This works fine for I2C but Anthony mentioned that for SPI, we would still need additional chip select lines. We could use the GPIO pins for this. I will still include jumper header pins 0 ohm resistors here so the GPIO pins can be used if desired. The 0 ohm was chosen over the headers because they are more reliable and cheaper.

Barometer

We decided since we can have multiple devices on the SPI bus, we will include a barometer as well. We will be including the MS561101BA03-50 as per Derek's recommendation.

LDO

The VDDIO pin on the IMU has a max voltage rating of 1.95V so a voltage regulator will be needed. I have chosen the AP2112K-1.8TRG1 since it is relatively cheap and highly in stock.

This is no longer needed since we are now using a different IMU. It is fairly expensive but is a common choice for our type of application.

Magnetometer

Since the IMU does not have a magnetometer, we will need to include one. I have chosen the BMM150 since it seems to be well stocked, relatively cheap, and good for this application. I have chosen the MLX90393 since the BMM150 is too small.

It should be aligned to the following axes:

Other Additions

This document from September outlines some potential improvements for the ZP3 board. It has not been touched since. EFS has been asked if this is still relevant and if they want these suggestions to be added.

This seems beyond the scope of the project but I will remind EFS again just in case.