Navigation pyskin - Board Design RFC

[blmorris]

@Turbinenreiter and @pythoncoder - thanks for the advice and feedback. I've been mostly offline for the last few days; I saw your posts but didn't have a chance to reply until now.

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

Understood, but there are two problems:
First, the GPS unit I am planning to use (and most units that I have seen) require a UART interface. The X position has UARTs 1, 2, and 4, but 1 overlaps with I2C(1), and UARTs 2 and 4 overlap with the servo pins on X1-X4. For a system that requires a UART, an I2C bus, and the servo pins, the only options are to designate that the navigation board will be in the Y position or to remap the servo pins away from X1-X4.
Second, leaving the extra two rows for GND and VBUS next to X1-X4 (provided by J4 on the current v1 board) to accommodate the servo connectors would restrict the space available for the GPS 16mmx18mm footprint. My current solution to both problem is just to design the navigation board for position Y. If Damien wanted to remap the servo pins (I don't think that it is absolutely necessary to use X1-X4), then I could design the board to be compatible with either position and provide servo headers with the extra pins sitting outside the two main header rows.

As for the choice of IMU device - I have no strong opinions on which device to use as I have no direct experience with these devices. Creating a new symbol and footprint in Eagle for another device is no big deal.

My main considerations for choosing the IMU would be cost, availability, and actually being able to do the job at hand. The MPU-9150 appears to be back in stock, so I'm not too worried about long-term availability. All the devices mentioned here are within a few dollars, so no reason to rule out a slightly more expensive part if it is clearly superior.

That leaves the ability to do the job of motion sensing for autonomous navigation. As far as I can see, none of the vendors actually list 'autonomous navigation' as one of the recommended applications, but I assume that the current generation of low-cost remote-controlled helicopters and quad-copters must use something like this, as the 'tactical grade' iSensor IMU devices from Analog Devices are much larger and cost 100 times as much. When I get a chance I think it would be worthwhile to put together a direct specification comparison to see the difference between the low- and high-cost parts.

How much priority should we put on having the sensor provide built-in sensor fusion / quaternion computation? From what I have read, the MPU-9150 promises this but we don't actually have access to it. For what it's worth, the STM devices (LSM9DS0/S1) offer compatibly with ST's iNEMO Sensor Fusion software
As @pythoncoder pointed out, the Bosch BNO055 also promises sensor fusion by way of its integrated ARM chip. They don't appear to be widely available yet, though I did find them here: https://www.rutronik24.com/product/bosc ... 17672.html

-Bryan

[blmorris]

I did a little more searching on the tindie.com link provided by @pythoncoder; the description for this breakout board mentions 'open-source Madgwick and Mahony sensor fusion filtering.' A google search on Madgwick and Mahony turns up this demonstration of x-io's implementation of the algorithm with their x-IMU sensor board, which uses the Invensense IMU-3000 as the 3-axis gyro and the LSM303DLH from ST as the 3-axis accelerometer / magnetometer.

Given the performance shown in that video demonstration, and the fact that it uses sensing hardware that is probably pretty similar in performance to what we are considering, I would guess that our navigation system will have sufficient performance for our purposes. I'm also heartened by the fact that the Madgwick / Mahony algorithm is open source and seemingly well-documented.

-Bryan

[blmorris]

I am nearly finished with the full GPS-capable version my navigation board design, just a few things to check if nobody can suggest a compelling design change. I'm pretty happy with the size; at 1.6" x 1.3" it is 0.05" shorter than the pyboard. (I would attach images but the forum doesn't allow pdf's).
However, once again I am reminded to assume nothing and take extra care when venturing into unfamiliar territory.
I had assumed that the nav board would need its own switching regulator to deal with the 11V from the battery pack. I went back to Damien's initial post to make sure that my connections would be compatible with the electronic speed controllers when I looked at the picture and realized the pyboard was actually getting 5V power _from_ a regulator on the ESC. D'oh! Of course I shouldn't complain; less space, cost, and complexity on the nav board; but I was pretty pleased with the design I had come up with. I can always re-use it in a later project, I guess.
The nav board now has its own 3.3V LDO so that the sensors and GPS receiver have their own low-noise supply uncontaminated by high-speed digital noise from the processor - probably wouldn't be a problem, but it is easy enough to take the extra precaution.
I assume that the 5V regulators on the ESC's are designed so that there won't be any problems when they are connected in parallel on the pyboard? It seems that parallel operation is their intended application, so it seems reasonable to assume this will be safe, but it would be nice if anyone can confirm this.

Brief description of my current design:

• The 9DOF IMU and barometric altimeter remain unchanged. I am keeping the MPU9150; we have tested it, code is written for it, and it appears to be available with only occasional supply-chain hiccups. The BMP180 and MPU9150 will share the same I2C bus on Y9/Y10.
• GPS - using the FGPMMOPA6H module from GlobalTop, based on the MediaTek MT3339 GPS Chipset. This is the only compact SMT module that I have seen that is essentially plug-and-play; all supporting circuitry is provided on the module: power regulation, crystals, patch antenna and amplifier are all integrated, all you need to do is provide power and put it out in the open. It also has an option for a backup battery (to preserve satellite data for faster restarts) and an external powered antenna, so I am designing for a battery holder and an SMA connector on the board. The GPS will connect to the UART on Y1/Y2. There will be a point to connect a jumper to connect the backup battery to the pyboard as well.
• Battery current and voltage sensing (as requested by Damien) using the MAX4137 and an op-amp difference buffer, respectively, connected to the ADC's on pins Y11 and Y12. Since the pyboard / nav board will not be drawing power directly from the battery (drawing fromn the ESC's instead) we can't assume that board ground will be at the same potential as the battery's negative terminal, especially at high operating currents. The battery voltage monitor will therefore utilize an op-amp difference circuit, rather than a simple voltage divider referenced to ground.

Another thing to note: the current-sense resistor will require a bit of careful consideration; even a 1-milliohm (0.001 Ohm) resistor with 50 Amps running through it will dissipate 2.5 Watts of power.

The 4 ESC's will connect directly to the servo headers located on the pyboard on positions X1-X4. These pins coincide with 2 of the 3 available UARTs in position X, and the 3'rd UART coincides with I2C(1). Since the nav board requires both a UART and an I2C bus, it needs to use postion Y to avoid conflict with the servo headers. This is fine, as the NRF24L01 serial link can still use the UART on pins X9/X10.

-Bryan

[pythoncoder]

Just a random thought but is it worth considering a Hall Effect device for current measurement? It would bypass the need for a 1mOhm resistor and would ensure the measurement circuit is isolated from the power wiring, an advantage when you're measuring at the millivolt level.

[Turbinenreiter]

Yay, sounds good to me.

[blmorris]

Just a random thought but is it worth considering a Hall Effect device for current measurement? It would bypass the need for a 1mOhm resistor and would ensure the measurement circuit is isolated from the power wiring, an advantage when you're measuring at the millivolt level.

To be honest I hadn't considered using a Hall Effect sensor for current measurement; I had pretty much just decided to use the method Damien and Tom had suggested.
At your suggestion I did a little research - the integrated devices that I found in my quick search would actually have been well suited for my original strategy of running a switching regulator directly from the battery. However, in order to use them I would need to run the full battery current through a connection on my board, requiring additional bulky, high current connectors. Now that I know that the system can run on the 5V output from the ESC's, I don't need to draw power directly from the battery to run the pyboard and navigation board, so the sensing connections to the battery and sense resistor can be low current and high-impedance.
I found this 1-milliohm resistor along with a few others; cost is US$5.69. Pricey for what it is, it's tempting to just measure the voltage drop along a 3cm length of solid-core 20AWG wire instead. Not as precise, maybe, but it would have the extra safety benefit of serving as a fusible link. (Note: I'll probably just spring for the expensive sense resistor )

Since I can't figure out how to post a simple PDF image on the forum here , I pushed the images of the current board and schematic to github:
Board
Schematic
Still subject to change, few things to clean up maybe, but I think that the design in it's current state could be built without any problems. (Disclaimer - when building a new board design, there is always at least one problem…)

In my last post, I wrote that the NRF24L01+ RF serial link could use the UART on pins X9/X10. I just checked (reminded by this note from Damien) and the NRF24L01+ is in fact an SPI device. No worries; SPI1 (pins X5-X8) is still free in this scheme.

-Bryan

[blmorris]

GPS / IMU navigation board design files are posted on Github: https://github.com/blmorris/pyIMU_v1/tr ... /pyIMU-GPS
I provided PDF's of the board and schematic for those who can't view Eagle files.
The board is printed at a 4x scale, overall size is still 1.3" by 1.6" (33.02 x 40.64 mm)

I could tweak this endlessly, but ultimately the only way to really test a design is just to build a few. I don't plan to change the design any further unless someone spots a real design or usability flaw. I'm planning to order boards in a day or two, but feedback is welcome any time, of course

-Bryan

[Damien]

I assume that the 5V regulators on the ESC's are designed so that there won't be any problems when they are connected in parallel on the pyboard?

No, they are not designed for parallel connection. You must remove the "red pin" from 3 out of the 4 ESCs so only 1 provides power.

[Damien]

Thanks blmorris, looks good! Here are some points regarding your design:

• We don't need to use X1-X4 for the servo control. Any IO with PWM capability will work just fine. But X1-X4 are the best to use because they connect to 1 timer with its 4 channels.
• Can you put a mounting hole in the bottom right corner of the PCB, to line up with the mounting hole on the pyboard (next to pin X2/Y2)?
• Note that there are 4k7 pull-ups for the I2C bus on the pyboard, so R1 and R2 are not needed.
• Can you swap MPU_INT to pin XY-5, so that XY-6,7,8, being the SPI bus, are free? Or is there a reason to have it on XY-5?
• Does the 3V3 regulator provide enough current for the GPS module?

Also, it might be a good idea if we amortize the cost of parts: we can do a bulk order of the main ICs, the GPS module and the PCB, and then divide it amongst those who want to build one.

[blmorris]

We don't need to use X1-X4 for the servo control. Any IO with PWM capability will work just fine. But X1-X4 are the best to use because they connect to 1 timer with its 4 channels.

Given that you already have the set of four 3-pin servo headers on X1-X4, and everything we need for the navigation board is available in the Y position, I'm happy to keep things as they are.

Can you put a mounting hole in the bottom right corner of the PCB, to line up with the mounting hole on the pyboard (next to pin X2/Y2)?

No problem, just need to move the names into the space below the SMA connector (J4)

[*] Note that there are 4k7 pull-ups for the I2C bus on the pyboard, so R1 and R2 are not needed.

I'm inclined to leave them there; they cost basically nothing, I2C works perfectly well with 2k2 pull-ups (still less than having two 4k7's in parallel) and it could be handy if anyone tries to use this board with another system besides the pyboard (not that anyone would ever want to do that ). Basically there is no harm in leaving them there, and the space is already reserved.

Can you swap MPU_INT to pin XY-5, so that XY-6,7,8, being the SPI bus, are free? Or is there a reason to have it on XY-5?

That works for me. The only reason that I had it on XY-8 is because that is where it was in @turbinenreiter's design that I used as my starting point. I assumed it was what he had tested with his code and just decided to leave well enough alone. You do offer a good reason to switch it, so I will.

Does the 3V3 regulator provide enough current for the GPS module?

Plenty - the GPS module is actually remarkably stingy; the data sheet claims 25mA for acquisition and 20mA for tracking at 3.3V. I have tested and confirmed that this module can work perfectly well drawing power from the pyboard regulator connected to a USB port. My reason for including an additional LDO was that there are going to be several devices claiming power - I imagine that the NRF24L01+ may be pretty hungry, but I haven't actually checked. Seemed safest just to split things up.

Also, it might be a good idea if we amortize the cost of parts: we can do a bulk order of the main ICs, the GPS module and the PCB, and then divide it amongst those who want to build one.

Could be nice if it comes to that - I was just hoping to justify getting to the first price break of 10 units. The GPS modules are ~$30 in single unit qty, accounting for over half the cost of a completed board. I'll try to put together a more detailed breakdown, and maybe see if we can ask Lady Ada very nicely if we might negotiate a small break.

No, they are not designed for parallel connection. You must remove the "red pin" from 3 out of the 4 ESCs so only 1 provides power.

Thanks, that is good to know. Still, the ESC's claim 5V/2A, which should be plenty.

-Bryan