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
Fixes to be made:
- Fix 4-pin GH Connector Pinout
...
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 what’s found in COTS products or what intuitively feels convenient.
...
I2C conn (J7, J12, J16). Replace with BM04B-GHS-TBT 4-pin connector.
...
On the Pixhawk, there are BM08BGPIO conn (J31, J32). Replace with BM06B-GHS-TBT 8 6-pin connectors which share GPIOs and ADC inputs
The following is their pinout (pin 1 VCC, pin 8 GND, pins 2-5 GPIOs, pin 6-7 ADC inputs)
There are 10 GPIOs + 3 ADC inputs on our flight board, we can use 2 8-pin connectors containing all GPIOs and 1 8-pin connector containing all ADC inputs. Another option would be to:
GPIO conn (J31, 32). Replace with 2 8-pin (or either 0.1” pitch through hole solder pads for option of using pin headers or direct soldering).
ADC conn (J28). 0.1” Pin sockets/headersADC 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.
(Pins 1-5 are IOs, pin 6 is GND).
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.
...
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 , I3C, 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.
Other Additions
Now there seems to be considerations for a barometer and compass/magnetometer on board. EFS has been asked what they would like to have on it.
. 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.