I2C problem on STM32F303 processor, what is happening with SDA?
split 50/50 between high and low on what looks like the acknowledgement bit
  [...]
  It looks like a tug of war between high and low on the ack


Correct, and that means that the I2C Master didn't actually release the SDA line, for the I2C Slave to perform the Ack.

In turn, that means that the GPIO pins used for the I2C bus on the I2C Master (likely both pins, but certainly SDA) were incorrectly configured and left at their default of "push-pull", and not switched to "open-drain", as required for I2C operation.

That's what causes the "tug of war" as you described it, or as glen_geek said: "why does SDA line not pull all the way down to ground?" The answer is that SDA (and probably SCL too, but most slaves don't try to drive it) is still being driven (by a GPIO pin still configured as "push-pull") and not released (with passive pull-up only) as an "open-drain" pin would be.

If you are relying on STM32CubeMX to write the initialisation code, then you've either just discovered a bug in the version you are using (look for updates &amp; errata) or else configuring it incorrectly (I don't use it, so can't tell you which setting may be wrong).


  On the Nucleo, the I2C is on I2C1. On the drone, it is on I2C2. 


So the I2C ports are different between the working and non-working configurations. That could easily explain why your problem shows up only on one configuration, if the STM32CubeMX framework isn't correctly initialising I2C2 (and there have been port initialisation bugs which affect only some ports).