search

iNavFlight / inav

INAV: Navigation-enabled flight control software
https://inavflight.github.io
GNU General Public License v3.0
3.08k stars 1.46k forks source link

Design a FC for INAV #287

Closed digitalentity closed 7 years ago

digitalentity commented 8 years ago

I think it's time to think about designing a FC specifically for INAV.

Features I want to have on this FC:

  1. Future-proof design with an F4 (or even F7) CPU
  2. 8 outputs supporting 8/0, 6/2, 2/6 motor/servo configurations
  3. Onboard baro (MS5607 or BMP280)
  4. Optional onboard NRF24 receiver (placeholder for a tiny daughter PCB)
  5. External I2C connector (compass)
  6. External SPI connector (opflow)
  7. SD-card logging
  8. Hybrid 4-pin connector to PWM/SBUS receiver (3.3V + 5V both available), same pin used for PPM/SerialRX
  9. USB VCP
  10. At least 3 extra UARTs for GPS, MSP, Telemetry
  11. 5V-level LEDSTRIP connector
  12. Analog inputs for RSSI, VBAT, CURR and an extra for optical rangefinder
  13. Sonar connector

What do you think?

skaman82 commented 8 years ago

13 Sonar Pads

Linjieqiang commented 8 years ago

Wonderful!I have always been concerned about this project.I am designing a FC board now and ready to flash inav F4 firmware,use STM32F4RGT6.I suggest why not use Can Bus Hub like Dji to connect sonar,opflow,gps,osd or even more sensors and devices?It will save hardware resources.

DzikuVx commented 8 years ago

What about factor? Probably keeping 30-something (30.5mm hole spacing) would be impossible. I'm fine about that, Pixhawk size would be totally fine in my case. I would even prefer that.

It would be also very nice to have SoftSerial not conflicting with RSSI and ADC

digitalentity commented 8 years ago

@skaman82 Done!

@Linjieqiang I'm thinking about being able to connect a sensor hub via serial port - this way sensor hub will be usable even with older FCs without CAN. I don't want this design to be bound to one hardware only.

@DzikuVx I'm going to keep 30.5mm hole spacing but the overall form factor is going to be larger (longer board). USB on the side, connectors on front and rear edges. I'm not going to make SoftSerial available on this board - F4 CPUs have enough hardware UARTs.

I'll design the board in such a way that it would be possible to use all (or almost all) features at once without conflict.

skaman82 commented 8 years ago

1+ for 30.5mm hole spacing

DzikuVx commented 8 years ago

I would be very happy with 5 Hardware Uarts

digitalentity commented 8 years ago

@DzikuVx this might be impossible. I'm going to use UART2 RX for PPM/SERIALRX input so it's going to be UARTS 1,3,4,5

DzikuVx commented 8 years ago

I know I am an special case here. I have OSD via MSP, another msp for telemetry, GPS, FrSky S.Port and Blackbox. All 5 possible Uarts taken on my Sprf3. Probably will switch osd to ltm and share it with telemetry via some Small arduino to free one uart

oleost commented 8 years ago

Just a question.

Hardware UARTS are fine, yes. But Softserial has proved very usefull in many cases.

With an F4 cpu compared to an F3 CPU could we overcome some of the limitations? Or with the F7 cpu?

Not a hardware developer, nor a software. Just thinking with a more powerfull CPU maybe softserial could run at 100k baudrates?

bk79 commented 8 years ago

I would use mpu9250 to have compass with no extra wire and an integrated bec so to avoid having a different board and all the io pin out avaiable Il 15/giu/2016 11:52, "Konstantin Sharlaimov" notifications@github.com ha scritto:

I think it's time to think about designing a FC specifically for INAV.

Features I want to have on this FC:

  1. Future-proof design with an F4 (or even F7) CPU
  2. 8 outputs supporting 8/0, 6/2, 2/6 motor/servo configurations
  3. Onboard baro (MS5607 or BMP280)
  4. Optional onboard NRF24 receiver (placeholder for a tiny daughter PCB)
  5. External I2C connector (compass)
  6. External SPI connector (opflow)
  7. SD-card logging
  8. Hybrid 4-pin connector to PWM/SBUS receiver (3.3V + 5V both available), same pin used for PPM/SerialRX
  9. USB VCP
  10. At least 3 extra UARTs for GPS, MSP, Telemetry
  11. 5V-level LEDSTRIP connector
  12. Analog inputs for RSSI, VBAT, CURR and an extra for optical rangefinder

What do you think?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/287, or mute the thread https://github.com/notifications/unsubscribe/ALSWiiyIOmZnHBD6KjQAyiFv4M03egHBks5qL8tHgaJpZM4I2LxB .

skaman82 commented 8 years ago

@bk79 External compass mounted far away from the wiring is always better then a internal one.

DzikuVx commented 8 years ago

And this is why I like the idea of no magnetometer on this board

bk79 commented 8 years ago

As long as it is far from ac power source (escs) it's ok and unless you have a 250 size which is intended normally for racing i can assure it makes really little difference to have it inside or outside the fc shell if you like i can attach the reading coming from a sparky connected to an hexa 320 and the reading coming from a cc3d connected to an 400size with ext compass of course in hoovering conditon for both that means low currents radiating Il 15/giu/2016 13:07, "Paweł Spychalski" notifications@github.com ha scritto:

And this is why I like the idea of no magnetometer on this board

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/287#issuecomment-226156631, or mute the thread https://github.com/notifications/unsubscribe/ALSWiu7Jy-WNCoqjsS2oreNx3zYu8pZ-ks5qL9zngaJpZM4I2LxB .

bk79 commented 8 years ago

Just as addition the bigger is the angle between escs wire and compass the higher will be the induction current from the esc wires since their radiation field is radial to the wire and normally the wire are on the same plane of the fc which means low mutual induction Il 15/giu/2016 13:27, "luciano palermo" luciano.luca.palermo@gmail.com ha scritto:

As long as it is far from ac power source (escs) it's ok and unless you have a 250 size which is intended normally for racing i can assure it makes really little difference to have it inside or outside the fc shell if you like i can attach the reading coming from a sparky connected to an hexa 320 and the reading coming from a cc3d connected to an 400size with ext compass of course in hoovering conditon for both that means low currents radiating Il 15/giu/2016 13:07, "Paweł Spychalski" notifications@github.com ha scritto:

And this is why I like the idea of no magnetometer on this board

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/287#issuecomment-226156631, or mute the thread https://github.com/notifications/unsubscribe/ALSWiu7Jy-WNCoqjsS2oreNx3zYu8pZ-ks5qL9zngaJpZM4I2LxB .

Linjieqiang commented 8 years ago

@digitalentity oh,I see.Your idea is great.What processor chip do you want ?I just think F7 is too expensive now.What about STM32F4RGT6?I think it's ok.Anyway,look forward to your work.Oh,I have another question.Are you going to design a FC box to damp the IMU, just like place it on sponge?The photo is that I hack ZYX-M FC.For reference only.Forgive me for my bad English.Haha…… img20160613121502 1

Also,if Revo Openlrs can be supported,that's more better~!But I think it lack powerful mobile GCS for IOS or Android Phone.

digitalentity commented 8 years ago

Vibration damping of the sensor board is a good idea but it will make the FC harder to manufacture. You can easily soft-mount the FC itself.

bk79 commented 8 years ago

I think thata mix spracingf3 deluxe and evo with sdcard reader is a good starting point but with f4 processor Il 15/giu/2016 17:18, "Konstantin Sharlaimov" notifications@github.com ha scritto:

Vibration damping of the sensor board is a good idea but it will make the FC harder to manufacture. You can easily soft-mount the FC itself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/287#issuecomment-226220413, or mute the thread https://github.com/notifications/unsubscribe/ALSWiqdryq2DdLxUgpwUqR5cfoU0f_Ozks5qMBe0gaJpZM4I2LxB .

dan557 commented 8 years ago

If most people are going to use a osd on one of the uarts why not build a max chip into the FC and with a f4 or f7 processor there will be plenty of resources to support it . osd support is currently being added to cleanflight On 15 Jun 2016 4:18 p.m., "Konstantin Sharlaimov" notifications@github.com wrote:

Vibration damping of the sensor board is a good idea but it will make the FC harder to manufacture. You can easily soft-mount the FC itself.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/287#issuecomment-226220413, or mute the thread https://github.com/notifications/unsubscribe/AD8DEZ56dN177lVJ376pk9fq_1-kMEbeks5qMBe0gaJpZM4I2LxB .

digitalentity commented 8 years ago

With HD systems emerging having an analog OSD is not the best idea. Also what if one will want different OSD? If possible I'd like to avoid mixing flight control and vision.

DzikuVx commented 8 years ago

I also do not like the idea of mixing FC with OSD.

digitalentity commented 8 years ago

What do you think, maybe make first version F3 based?

skaman82 commented 8 years ago

@digitalentity what would be the advantage, compared with a SPracing F3 (my board of choice at the moment) - except SD Card support?

digitalentity commented 8 years ago

A very brief connector layout image

This may even fit into square board with 30.5 mounting holes. But more likely it will be a rectangular board with regular thru-hole connectors on both sides (motors on one, RX/extras on the other)

digitalentity commented 8 years ago

@skaman82 for example gyro on SPI bus, direct support for SPI external hardware (optical flow), more hardware UARTs + USB for Configurator. EDIT: And none of those crappy JST connectors

digitalentity commented 8 years ago

Also, what about exposing USB as through-hole connector to be able to easily move it to the outside of the aircraft?

digitalentity commented 8 years ago

Laying out the board is going to be one hell of a task :smiley:

bk79 commented 8 years ago

Spi needs a dedicated pin for each device exposing one pin only means having a dedicate connection only for the optical flow and using f3 would loose any benefit compared to f4 since spracing pro deluxe has everything with less than 40$ Il 15/giu/2016 20:36, "Konstantin Sharlaimov" notifications@github.com ha scritto:

Laying out the board is going to be one hell of a task 😃

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/287#issuecomment-226279522, or mute the thread https://github.com/notifications/unsubscribe/ALSWii-MJ1mlvCrDuCfZZ7RSyzm4wY6bks5qMEYSgaJpZM4I2LxB .

digitalentity commented 8 years ago

We can move CAN to the side (or lose it at all) and have 3 \CS pins for SPI meaning 3 possible external devices to connect (SPI RX + OpFlow + ...)

digitalentity commented 8 years ago

And I agree - using an F3 chip is not a very good idea

bk79 commented 8 years ago

F4..ok f3...still not much gain compared to other boards Il 15/giu/2016 20:52, "Konstantin Sharlaimov" notifications@github.com ha scritto:

We can move CAN to the side (or lose it at all) and have 3 \CS pins for SPI meaning 3 possible external devices to connect (SPI RX + OpFlow + ...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/287#issuecomment-226284267, or mute the thread https://github.com/notifications/unsubscribe/ALSWisMTeXkkBw_pJSaUnyF07RvNR7OMks5qMEnegaJpZM4I2LxB .

digitalentity commented 8 years ago

@bk79 what would you consider "much gain"?

skaman82 commented 8 years ago

• More hardware UARTs are always nice! • I have nothing against a F3 version if it makes the CF cheaper. I personally don't like spending more than 30$ on a FC. • About the usb: I have to solve that problem constantly (because SPracing boards have the USB on the rear side. I just take a micro usb connector and connect it to a cheap USB breakout board. This way I can place the USB everywhere I like. It is pretty easy. If you placing the USB on the side, there is no need to have extra pins for that - they would take away some space to.

digitalentity commented 8 years ago

Actually STM32F303RC costs roughly the same as STM32F405RG, so it's going to be an F4 CPU after all. The problem is UART hardware inversion which F4 chips don't have.

digitalentity commented 8 years ago

Actually $30 price for this FC is marginal, BOM+PCB+assembly will cost ~20-30$ if produced in low quantities. What price do you think would be reasonable for this FC?

skaman82 commented 8 years ago

I just talked about me (personally). I see people spending 40-50$ for this easily. More likely 50$

digitalentity commented 8 years ago

Personally I don't like spending more than $30 on an FC as well, but I don't mind prices up to $50-60 for a decent product :smile:

Actually, a dead simple board w/o baro, w/o CAN and w/o SD-card might cost even under $20. I need to do a proper design to be able to estimate BOM and assembly prices.

skaman82 commented 8 years ago

The original SPracing F3 was to pricey as it came out (it was about 65 or 70€). That was a deal-breaker for most and that is mainly the reason why spracing boards are not so popular. It became more popular since china started to clone this FC and sell it for about 20-25 €.

DzikuVx commented 8 years ago

Suggestion that came to me after todays helping fellow... If 3.3v is supposed to be available on a connector, use 2 ldos. One for cpu, one for external pin. And maybe polymer fuse as well

bk79 commented 8 years ago

@digitalentity benefit from a faster cpu are huge quaternion can be used sdio for sdcard is there 4 usart various i2c and three spi...

Suggestion that came to me after todays helping fellow... If 3.3v is supposed to be available on a connector, use 2 ldos. One for cpu, one for external pin. And maybe polymer fuse as well

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/287#issuecomment-226314901, or mute the thread https://github.com/notifications/unsubscribe/ALSWioPa6HyHBeV9qkjVPR8BB-SUcTOWks5qMGS9gaJpZM4I2LxB .

rustyoz commented 8 years ago

I would love a board with a separate 5v rail on the motor/servo outputs with pins for an external input. I have a tilt quad and using a seperate 5v bec for servos or even high voltage servos would be a plus.

martinbudden commented 8 years ago

My thoughts on the iNav FC.

I'm not a hardware guy, so my thoughts should be taken with that in mind.

Thoughts on the spec

1) Future-proof design with an F4 (or even F7) CPU Leading edge, not bleeding edge, so F4 not F7. With F4 iNav can share code with Cleanflight and betaflight. With F7 it's on it's own. And F4 rather than F3 since the FC is for iNav and iNav will add more navigation calculations in future.

2) 8 outputs supporting 8/0, 6/2, 2/6 motor/servo configurations Yes, definitely 8 outputs. 6 is not enough for many iNav uses.

3) Onboard baro (MS5607 or BMP280) Yes.

4) Optional onboard NRF24 receiver (placeholder for a tiny daughter PCB) Most definitely. Note that the NRF24 requires a stabilised 3.3V power supply, and behaves erroneously if the voltage drops too low, so ensure your onboard 3.3V regulator is sufficiently powered.

5) External I2C connector (compass) Yes. And external I2C connector can be used for other devices as well. Eg sonar, optical rangefinder etc (see further comments later).

6) External SPI connector (opflow) Yes. And external SPI connector can be used for other devices as well. Consider having more than one NSS connector available. Other SPI signals can be shared.

7) SD-card logging Yes.

8) Hybrid 4-pin connector to PWM/SBUS receiver Yes.

9) USB VCP Yes.

10) At least 3 extra UARTs for GPS, MSP, Telemetry Yes, but see later comments on UARTs.

11) 5V-level LEDSTRIP connector Yes.

12) Analog inputs for RSSI, VBAT, CURR and an extra for optical rangefinder Not entirely. See later comments . In brief VBAT not required if there is an onboard BEC, and optical rangefinders seem to use I2C.

13) Sonar connector Yes.

It seems optical rangefinders use I2C. Both the teraranger and the lidar-lite can connect via I2C. (Now that Garmin has bought PulsedLight, it's unclear whether the Lidar-Lite will continue to be available though)

OSD has been mentioned in the thread. My view is that the "natural" place to integrate the OSD is in the VTX, not on the flight controller.

Sensors

Gyro should connect over SPI, not I2C

Consider using Invensense's temperature stabilised gyro the mod-1600

I believe this is used on the pixracer.

If you don't use the mod-1600 my preference is to use the MPU-9250 with built-in compass but have the option to add an expernal compass.

Thoughts on serial ports

While I think currently you need to maximise the number of serial ports, I think in future this will be less important.

We are already seeing devices that used to be connected via serial ports using different options:

Team Black Sheep's BST(Black Sheep Telemetry) uses I2C rather than serial. I think we will increasingly see I2C used for telemetry.

We are seeing begining to see OSDs connected via SPI, and VTXs with integrated OSD.

Once the ESP32 becomes widely available I think we will see Bluetooth devices connected over I2C.

Unfortunately most GPS devices seem to connect over serial, but hopefully we will start to see GPS devices connect using I2C.

So serial ports will become less and less important. Unfortunately we still need them now. (My personal opinion is that they are a 1980s technology and I will be glad to see them go.)

Hardware and connectors

Definitely use the standard 30.5mm hole spacing. And I think you should try as hard as possible to keep the 36x36mm square form factor.

I'm not sure how many layers you are planning on using. 2-layer boards are cheaper. As I said, I'm not a hardware guy, but I do know that having a ground plane on the board "is a good thing". This would seem to preclude the use of a 2-layer board.

As far as possible use through-board connectors, not plated on connectors (like those on the NAZE rev5 and previous).

I think the micro-JST connectors as used on (eg) the CC3D are too small, so consider using the JST GH connectors which are part of the dronecode connectors standard and are used on the pixracer.

The exception being the Serial RX connector, which seems to have standardised on micro-JST.

PWM connector

Traditionally flight controllers used 3-pin connectors for PWM, eg:

12345678
VVVVVVVV
GGGGGGGG

I think this is unnecessary and wastes board space. I prefer just one connector for each PWM output, eg:

GV12345678

Admittedly this makes the connection of servos slightly more difficult - they cannot just be plugged directly in, but I think the tradeoff is worth it.

My further suggestions

Some of these may be slightly controversial.

One of my motivations for developing Cleanflight/iNav/betaflight software is to make the hobby more widely available. Partly by (hopefully) making the software better and easier to use, but also by making the software support cheaper and more widely avaiable hardware (that was a prime motivation for doing the NRF24 work).

One way of reducing cost is the by the use of brushed motors. Brushed motors are cheaper and don't need ESCs and so can result in considerable cost savings.

For people on a budget (and I'm especially thinking about teenagers) we should support the use of brushed motors directly. And even for people not on a budget, having a spare cheap quadcopter for practice or to take on holiday is useful.

This means having at least 4 FET-buffered PWM outputs on the board.

This is not unprecedented. The SPARKY 2 flight controller has 4 buffered PWM outputs that can be used to directly drive brushed motors.

The KISS flight controller has buffered PWM outputs, although in this case I think they are for performance reasons (and KISS know a little bit about performace).

The AlienFlight F3 brushed-octo FC uses 4 dual-channel MOSFETs for its PWM outputs (it uses Dual N-Channel Fairchild FDMB3900AN MOSFET) so 4 PWM outputs could be buffered on the iNav FC using just two of these dual-channel FETs - that should not take up much board space.

Personally I'd be in favour of buffering all eight PWM outputs. I think buffering the PWM outputs may bring other advantages - performance and the ability to drive high power servos.

Here's what I'm thinking: someone could buy a cheap brushed-motor quadcopter, say a Syma X5 or X8, or a Kai Deng K70. They could then replace the original flight controller with an iNav FC, add an NRF24 daughterboard and a GPS unit and they have a very cheap quadcopter that supports navigation. They could probably even use the transmitter that came with the quadcopter presuming it's protocol was supported, so they wouldn't even need to buy a transmitter.

Brushed motors are pretty well universal on sub-120mm copters, and I quite like the idea of a navigable small copter like that as well. [And for those of you who haven't build a brushed quad - their perfomance can be surprisingly good and the flight fast and agile.]

Onboard BEC

I'd like to have an onboard BEC. This is just so much more convenient. BEC only needs to support 2S-4S. For a 5S or 6S aircraft the FC can be powered from the balance lead.

[As an aside, I generally wire my quads that way - power the FC from the balance lead, power the ESCs from the XT60 connector. That way you can power up the FC without powering up the ESCs. That means you can do some setup operations safely without removing the props. It also reduces (slightly) the electrical noise from the ESCs to the FC. Not my idea - I first saw it on the setup pages for the Brain FC.]

The onboard BEC also makes it easier to support brushed quads. (Note, no 3.7V to 5V boost is required. The way to support 3.7V brushed motors is to use a 2S battery (or two 1S batteries), and power the FC from both cells, and then use the one cell to power (say) the front two motors and the other cell to power the back two motors.)

Digital outputs

I'd also like to see a couple of digital output pins (ie ON/OFF, not PWM). These could be used, for example, switch on LEDs if an LEDstrip was not being used, or to control a camera. These are on my "nice to have" rather than "essential" list.

DzikuVx commented 8 years ago

My note on Martin's suggestions:

  1. Build in BEC: those things when with proper max. load tends to be big and heavy. And costly. And if it burns, one would have to usually throw whole board away. Instead I like the idea of separate power line with a jumper that might allow to use high voltage servos
  2. PWM outputs with MOSFETs to brushless motors: hmm... again, not a biggest fan in this case. While I'm totally fine with another FC with brushed support and without fancy stuff like SPI,CAN or even most of UARTs, putting all possible features on one board will make this big and costly. The biggest advantage of INAV is GPS. And somehow it's hard to imagine brushed motors carrying those
  3. Digital outputs: nice, too bad software is not ready for them yet. And to be useful, they would require MOSFETs
  4. PWM Connectors: I would stick with traditional ones because of servos
martinbudden commented 8 years ago

@DzikuVx

  1. I've seen from @digitalentity 's comments elsewhere that he is not in favour of a built-in BEC, so I'm probably onto a loser there :-) However, for the record, I don't agree with your big and heavy comment - this may have been true in the past, but there have been developments in BECs. A number of "small" FCs include BECs - these include the KISSFC and the LUX (which are both sub-36mm size - in that they are 36mm boards with the sides cut out). And the tiny FPV-PIKOBLX (which has 20mm mounting hole spacing) has a built-in 2A 5V BEC.
  2. I find it very easy to imagine brushed-motor quads carrying GPS. The Syma X8 is a very popular 330mm brushed motor quadcopter and I bet loads of owners would love to upgrade to GPS. The iNav FC could allow them to do so, and with the NRF24 daughterboard they would not even need to buy a new transmitter. Depending on the iNav FC cost they could have a GPS enabled quadcopter with transmitter and camera for about £100. (Admittedly the transmitter and camera are both a bit rubbish, but those could be upgraded if required.) Rather than a priori dismiss the addition of FETs, I think we should let @digitalentity do a BOM and rough board layout - if they are too costly or there is not room, then fair enough - but let's not pre-judge the result.
  3. Digital outputs "too bad software is not ready for them yet" - well that is something I can change :-)
  4. PWM connectors. I think I have a solution that works for both of us, see below.

Possible option for PWM connectors

One of the interesting aspects of the SPRacing Mini flight controller is the addition of "fault lines" on the PCB, so that parts of the PCB that are not required can be snapped off. This could be used on the iNav FC for the PWM connectors, e.g.:

fault line ____GV12345678___ fault line
                 VVVVVVVV
                 GGGGGGGG

That way users who did not require the extra two rows could just snap them off.

The extra two rows could be outside the 36mm square size, so that snapping them off produced a 36mm square board.

sppnk commented 8 years ago

And..what about an on-board OSD chip? The OSD tasks probably could be done by the main processor and the design still would be compact.

Then we would need also the conectors for camera and vtx (3.wire servo conectors, or may be 4-wire connectors, including audio).

DzikuVx commented 8 years ago

@martinbudden

digitalentity commented 8 years ago

FET-buffered PWM outputs: If I have space on the board I might add FETs to buffer PWM outputs to allow brushless motors. If it will be possible I'll buffer all 8 of them. The problem here is BLHeli passthrough - buffering is going to kill it.

Sensors: No I2C. Gyros will be SPI-bus. MOD-1600 looks promising. I'll try to get a sample and design a board to use it.

PWM connectors: There are lots of tiny FCs and this is not going to be one of them. As we target also airplane flyers there will be no compromises - each servo/motor is going to be a 3-pin header connector. I might try a "fault line" solution though.

OSD: I don't like all-in-one solutions. THe most logical place for OSD is VTX (or camera).

Onboard BEC: As a replacable daughterboard - it's possible, but not as a built-in option. BECs burn out and I'll hate to replace the whole FC. Also, I like specialised solutions - dedicated BEC will handle higher loads, will be easier to replace and will reduce cost for those who don't need it. I might add a 2-4S BEC to power FC from VBAT directly but this will be an option to power FC only, no servos, no external devices.

Digital outputs: And your whish shall be granted :smile:

martinbudden commented 8 years ago

I'm OK with the decision not to have a BEC. I'd certainly rather the board space was devoted to FETs. I don't think it's really worth it to have a small BEC just to power the FC.

I'm not familiar with the BLHeli passthrough code - why does buffering cause a problem?

digitalentity commented 8 years ago

It's not the code, it's the hardware. BLHeli requires a bidirectional link between FC and ESC. Mosfet buffer is uni-directional in nature. If I won't be able to make a hardware solution it's going to be either passthrough or buffers.

martinbudden commented 8 years ago

I see. If you can't make a hardware solution for BLHeli, then I suggest the best option is to buffer 4 of the 8 outputs. That way brushless quads can use BLHeli passthrough, and brushed quads are also supported. The downside is no BLHeli passthrough for hexacopters or octocopters, and brushed hexacopters and octocopters need to add additional FETs. But I think that is a reasonable compromise.

iforce2d commented 8 years ago

Absolute must:

Really would like

Don't care

Prefer not to have

Really don't want

The main thing is to have lots of connection options, that way other parts can be added as needed and the cost can be kept reasonable. Most people will not be using iNav on a little mini-quad, so I would think the wriring space needed to add, for example, a separate OSD or whatever will usually not be an issue.