Navigation pyskin - Board Design RFC

[blmorris]

Taking inspiration from @dpgeorge's quadcopter project, I have offered to finish a navigation pyboard skin design begun by @turbinenreiter, incorporating the IMU, barometric altimeter, and hopefully GPS. He and and I are both hoping that this board could see wider use, so I would like to collect some opinions from other potential users before proceeding much further - unfortunately hardware design doesn't lend itself easily to the 'commit early, commit often' philosophy of open source software; mistakes and poor design decisions are substantially more expensive to fix after boards have been ordered.

I would like this skin to stay as close as possible to pyskin design guidelines, such as they exist, so I have done a brief survey of the current state of the art. The pyboard was designed to make it possible for a pyskin to be placed in either of two opposite, symmetric positions (designated X and Y), assuming that the components of the skin only require the use of GPIO pins X/Y 1 through 12. However, position X also provides access to several additional GPIO that are not available in position Y, and the audio and LCD/touch sensor skin available from the micropython store both make use of resources available only in position X.

There is also the issue of potential stackability - in theory it should be possible to design skins that can stack up in several levels of boards, if they are fitted with pins/headers that can pass the signals through. I haven't seen any designs that actually attempt this, and it appears that it would be impractical to do this with either the LCD or Audio skins.

A few design consideration that are specific to this navigation board:

• If a GPS module is included, it would also make sense to include a backup battery to retain satellite ephemeris data to enable fast acquisition and position fix after a power cycle. If a backup battery is included, it would make sense to share it with the pyboard, which would necessitate using position X.
• If the navigation pyskin is to be compatible with a quad-copter (which is of course the intention) then the servo-control pins X1-X4 need to be available to the motor controllers (This is what I gathered from watching Damien's video) so a navigation board in the X position would at least need to pass these through even if none of the other pins are passed through.
• In order to achieve the best possible fix, a GPS antenna should have unobstructed exposure to the open sky, so any stacking board design should ideally have the nagivation board at the top of the stack. (It is possible that I am overthinking the stacking problem here, and should just dictate that this board should be the only board occupying position X.)

So, to summarize my current thinking - navigation pyskin based on @turbinenreiter's initial plan, using MPU9150 accelerometer/magnetometer/gyro, BMP180 barometer/altimeter, and footprint for an optional GlobalTop MTK3339 GPS receiver and shared backup battery, and pass-through for at least the four sets of servo headers for motor control.

Any thoughts or suggestions?
-Bryan

[dhylands]

Does the GPS have an option for an external antenna?

For the quadcopter, it probably doesn't make sense, but for a ground based vehicle, it does.

If the VBAT line is the only special line, then you could still use it in the Y position by using a jumper wire.

[blmorris]

Does the GPS have an option for an external antenna?

It does, and I use an external antenna with the breakout board I have, mostly to get access to a window from my desk. Outside, it does fine without it. It also does fine drawing power from the pyboard 3.3V regulator.

If the VBAT line is the only special line, then you could still use it in the Y position by using a jumper wire.

True, but it's a bit ugly, and only makes sense if there is a skin in the other position that doesn't block access to VBAT. Still worth considering.

-> Edited to fix formatting - I shouldn't try to split up a quote while replying from an iPhone and walking in the rain at night.

[Damien]

Great idea to do this!

It would be nice to have a current sensing chip on the skin, since I want to know how much current is drawn from the battery. I will also want to measure the voltage of the battery, but that's easy to do using a voltage divider input into the ADC. Current sensing is harder (esp at large currents like 10A). Tom and I did some searching and found the MAX4173 which is a high-side current sense chip and seems pretty neat. What do you think? Would this fit on the skin (maybe underneath) and would it be useful for more than just a quadcopter? (I wouldn't put the current sense resistor itself on the skin, just have headers to connect to an external one.)

Regarding skin design. The LCD does not need to be in the X position; it works just fine in the Y position since it only uses the standard 16 pins on the outer edge. You could stack something on top of the LCD if you wanted to. You'd lose access to the 4 buttons, but you still have the headers in the middle row to connect to your own external sensor pads (these middle exposed pads are not X17-X24, but connect to the 13 electrode lines of the touch sensor chip). As for the AMP, yes it needs the X position for the shielded ADC input, and AGND/A3V3. But you can stack a skin on top: Arduino-style stacking headers are tall enough to clear the speaker. And the AMP skin uses only the I2C bus (for digital volume control) and 1 ADC input on the X22 pin, so you can pretty much use all the standard 16 pins for another skin on top (eg the LCD would work fine).

[blmorris]

Regarding skin design. The LCD does not need to be in the X position; it works just fine in the Y position since it only uses the standard 16 pins on the outer edge. You could stack something on top of the LCD if you wanted to. You'd lose access to the 4 buttons, but you still have the headers in the middle row to connect to your own external sensor pads (these middle exposed pads are not X17-X24, but connect to the 13 electrode lines of the touch sensor chip).

Thanks, I missed that detail - I thought that the middle row on the LCD skin was a pass-through for X17-X24. I assume that boards designed for stacking should only count on the standard 16 pins being passed through; anything requiring the additional pins in the X position should just assume that it is the bottom board in an X stack.

That said, it looks like my design goals may require the navigation board to sit in the Y position, at least in the quadcopter application. This is because the IMU and barometer require the I2C bus, and the GPS requires a UART. Position X has 3 UART's available; however one is unavailable because it overlaps the I2C (the same is true in position Y) and the other two overlap the servo outputs (X1-X4) which are used to control the motors. If position Y is used then the I2C and UART can both be used and the servo outputs remain open.
The only disadvantage to using position Y is that there is no direct connection to VBAT, but this can be addressed with a jumper as suggested by @dhylands.
Also, since I don't need to worry about including positions for all of the extra X position signals, there is a lot more room to work with (the GPS will require a 16x18mm footprint, which gets pretty tight on a pyskin board.)

It would be nice to have a current sensing chip on the skin, since I want to know how much current is drawn from the battery. I will also want to measure the voltage of the battery, but that's easy to do using a voltage divider input into the ADC. Current sensing is harder (esp at large currents like 10A). Tom and I did some searching and found the MAX4173 which is a high-side current sense chip and seems pretty neat. What do you think? Would this fit on the skin (maybe underneath) and would it be useful for more than just a quadcopter? (I wouldn't put the current sense resistor itself on the skin, just have headers to connect to an external one.)

This is a good idea, though I wouldn't have considered it as part of a 'navigation board' if you hadn't suggested it. The MAX4173 is available as a 6-pin SOT-23, which is pretty easy to fit in a tight space. Also, if the primary battery is to be connected directly to the navigation board for current measurement, would it also make sense to put the power regulator on the daughterboard as well? I have designed several board with switching regulators (even audio boards where noise is a concern), which is a good way to get a bit more power efficiency.

And then, of course, there is the eternal concern with feature-creep I think it is all reasonable, though.

[blmorris]

I've been sitting on this too long, so I figured it was best to publish what I have at the moment-
https://github.com/blmorris/pyIMU_v1

This board is just my attempt to clean up the design initially offered by @Turbinenreiter; it is a minimal size pyskin with just the MPU9150 and BMP180 and the option to pass through all of the pins in the X position; this way it can be used in either the X or Y positions without blocking any signals and won't preclude stacking with other boards.

I still plan to do a more complete design for v2, with a larger board and only the two standard 8-pin headers on each edge. This will allow enough room to include a GPS receiver module (requiring >16mmx18mm footprint) along with some other goodies like a backup battery, a switching 3.3V regulator (which could also supply the pyboard, and provide a good boost in battery efficiency compared to the pyboard's LDO regulator) and the current sensing MAX4173. My plan is that this board could connect directly to a battery pack and supply regulated 3.3V power to the pyboard and any other peripherals. The downside is that it will not allow the bottom row or servo signals in the X position to pass through; if the servo headers on X1-X4 are to be used, then the larger navigation board will need to sit in the Y position.

I'll provide gerber files to manufacture the pyIMU_v1 board if anyone asks.

-Bryan

[Turbinenreiter]

I'm trying to find the necessary parts right now, and the MPU9150 is kinda hard to find. DigiKey are the only ones who have it. They are also the only ones who don't have the BMP180 in stock ... . While I was looking around, I found the BOSCH BMX055 -> a 9-axis-sensor without any of the MPUs special tricks (that we can't use anyway as they aren't documented) that only costs half and seems to be easier to get. LSM9DS0 also is a bit cheaper and easier to get than the MPU.
Do you think it's worth reconsidering? The only reason I went with the MPU was that it was used on the Sparkfun board I already had. I'd have to write a new driver, but that really wouldn't be a big deal.

Anyway, I ordered 10 pcs from dirtyPCB (let's see how that turns out). I wont need all of them, so ... holler.

As for v2 - main use for this would be the quadcopter - servo headers should absolutely be there.

[pythoncoder]

I've found that magnetometers can vary considerably in quality: the one on the MPU9150 is the first I've come across which seems to give accurate results without needing to be recalibrated. This involves performing a full rotation around each orthogonal axis (not always easy or even possible). Another potential issue is gyro drift. At least we've tested the MPU9150: is there any way to test the Bosch device?

[Turbinenreiter]

is there any way to test the Bosch device?

kinda:
https://www.tindie.com/products/onehors ... teensy-31/
https://github.com/xioTechnologies/BMX055-Breakout

Sparkfun has a board with the LSM9DS0.

I found some MPU9150s on ebay, coming directly from China. ebay+china is always a little risk, but hey, no risk, no fun.

[pythoncoder]

There is also the Bosch BNO-055 with integrated ARM chip and sensor fusion code. This could take processing load off Micropython in aircraft applications.
https://www.tindie.com/products/onehors ... or-fusion/
http://www.bosch-sensortec.com/en_GB/ho ... 3/bno055_4

I should mention that the sample code at
https://github.com/kriswiner/BNO-055/bl ... HRS_t3.ino
seems to require you to calibrate the magnetometer on initialisation by "moving the device in a figure of eight pattern". Magnetometers requiring this procedure are a nuisance in my view, but perhaps the hassle is worth it for the usable sensor fusion.