Naze32 Rev6

[aokholm]

I think ROSFlight sounds like a terrific solution to an easy to get into flight control system! I have gotten hold of a Naze32 Rev 6. One of the changes is that Rev 6. has a upgraded MPU 6500 vs 6050 in Rev 5.

It seems that BreezySTM32 does not contain the drivers of the upgraded MPU. Further the ROSFlight sensors.c specifically calls the 6050 functions.

I guess part of the appeal of the current setup is the simplicity, but being able to use the newest hardware revisions also have some appeal.

To get my own setup working I could fork both projects and do make the required changes. I don't think I'm skilled enough to make a system that could handle both hardware revisions. I have taken a look at how clean and base-flight, handles this, but their solutions are not especially easy to follow.

What's your thought on the issue?

[superjax]

I completely agree. Being able to use the newest hardware is definitely something I would like to get to, and you're right the baseflight/cleanflight hardware drivers are pretty tangled.

I'm actually currently working on rebuilding the entire hardware library in hopes of replacing Breezy. So far, it's a lot cleaner than cleanflight (lol), and I have been able to at least get printf support on F1, F3, and F4 boards. This weekend, I'll finish I2C, and over the holidays I expect to finish the drivers for all three boards. This would include the SPI driver for the MPU 6500.

The primary motivation for the move is to eliminate the crazy baseflight drivers with something less confusing/more extensible with a noticable reduction of #defines. I would also especially like to move to an MIT/BSD3 license, so I can use it at work and in proprietary projects without any possible legal ramifications.

Unfortunately, I don't see myself working on modifying Breezy to support the rev6. I can, however, make sure we support rev6 on the newest driver implementation.

Where did you get your rev6 board? I don't actually have one, but I should probably buy one because you're not the first who has requested support.

[aokholm]

I will experiment a bit to see how difficult it is to get working, I'm still learning about the STM32 family. If I get anywhere with the Rev6 I will share what I learned! I also just ordered a Rev. 5 to makes things easier in the meantime :)

I'm currently in Shenzhen, China to work on this project (for one week more). So the best option here is to pickup the boards from Taobao - the local eBay.

Thanks!

[superjax]

I just did some reading, and it looks like the MPU6500 is on the I2C lines, not SPI like I suspected. In that case, then there is almost no difference. In fact, I've used the 6500 in another project over I2C and I am pretty sure that I used exactly the same code as the 6050. Pretty sure that the rev6 has a different EXTI pin though. You'll notice in the code, I specify a board rev to the configuration, this is because that external interrupt pin from the MPU moves around from revision to revision.

I'd be happy to help out if you get stuck, but based on that, it shouldn't be super hard.

[pryre]

Hi all, I've been looking into a solution for a university project later on in 2017, definitely leaning towards getting a heap of Naze32r6 boards an working with them. Hopefully I can get my hands on a few in the new year to help out with debugging and any other business that comes up.

[aokholm]

The interface of the 6500 is indeed very similar to the 6050. Even the interrupt pin has stayed the same between V5 and V6. So I did get it to run with interrupt functionality on with a simple modified Breezy example. I'm not sure what has actually changed in terms of the interface. Haven't tested with ROSflight yet, since I ran into a bit of trouble with ROS as well. I will probably continue working with the rev5 I acquired until the whole setup is working :)

[superjax]

I just read this and thought it was pertinent to this discussion: I hadn't realized that the MPU6050 was actually a better sensor than the 6500 for most UAV purposes.

original link

The MPU-6050 is higher power, lower noise, and larger package versus the MPU-6500. Most of your code should port over, but some low power features are different and will need to be recoded in. Basic data acquisitions shouldn’t have changed.

[superjax]

Has this been resolved?

[aokholm]

Haven't made any progress since my last message. Did get the 6500 to work (at least some simple test scripts), but then got stuck getting ROS running on our OrangePi's.

Here is my commit that adds support for the 6500 MPU (to Breezy). It's a fork on BreezySTM32 repository. https://github.com/kitextech/BreezySTM32/commit/61430152c05d3dab216d0a6429bbbd64bd720dce

We ultimately decided to try our luck with the PX4 system, since it could be more compact and it did have some useful features :). Still hope this project takes off!