Just wanted to start a discussion on what hardware base will the be the best for uploading or software onto. The options seem to the Arduino’s (Uno, Mega, Nano, Leo) and a few others like the teensy. The Teensy 3.5 looks very interesting for the price, 5v digital in capable, loads of analogue in + PWM out etc, SD card built in for data logging and a 32bit processor. Seems like the most future proof piece of hardware unless I’m mistaken.
Interested to hear everyone else’s thoughts!
I’m liking the Teensy 3.5 as the best option at the moment. I also like the SD card for logging, and it should be able to handle all the I2C to the BMS, the PWM out to the ESC as well as the RPM inputs for monitoring prop speed. Definitely some good bang for the buck in terms of cost too.
Any ideas on monitoring prop rpm? Using a VESC or by using sensors hooked up to the arduino?
Yessir, we will be using the RPM output of the ESC. It pulses with each electrical commutation. So you’ll need to know the number of poles of your motor to convert, so that’s easy.
The Teensy definitely seems like a very capable board, perfect for this application! I need to get that board to play around with.
@davek79, right now do we have anything checking for a motor failure? As in if one fails do we have any circuitry to detect it and turn off the motor opposite to it?
That’s the plan. Don’t have that in this rev, however. I’m just getting started on the BMS side of things, FC will be after that. There’s some good conv on other threads about how we could balance in case of motor failures.
I’ve asked this in another thread, but seems more appropriate here.
I’d nominate the ESP series microcontrollers as they’re much more capable and less expensive than the teensy or other AT(x) based solutions.
Native WiFi and Bluetooth, more memory and more processing power, and so on. You shouldn’t even have to change much (if any) code while still using the arduino platform.
Typically they cost a couple dollar to under ten (model depending) if bought overseas and still relatively inexpensive if bought at sparkfun or adafruit.
Thanks for the suggestion. I’m definitely going to have to start experimenting with some ESP boards.
Worth still considering @davek79 excellent suggestion of keeping the comms as a slave device, and the ESP32 as a comms coprocessor? Sensible to keep safety critical on a device that isn’t busy talking to others.
Oddly, the community picture of an STM32Fxxx based flight controller is a brilliant starting point. ST micros are well used (and solid), Atollic give a free and brilliant IDE, and the debugger is cheap. Temperature is 105C maximum, but that is a trustable 105C… Also, you get a 6/9DOF plus a barometer interface on most similar boards (So you can crib code from existing - and well written - resources like Betaflight). The 6DOF is the killer feature for me over a standard paramotor, as it has the ability to thrust vector your motors in conditions like undetected motor failure twist, launch where the pilot face plants (a game changer to have a safety kill when the pilot falls face first on to his throttle) etc. You can quickly make gasoline machines look dated and dangerous.
For all of your failure cases, please be careful with all of the inter board interfaces. Some diagrams show i2c etc, which are great, but they MUST have protection for short circuits,ESD (aircraft props generate a LOT of static!) Etc. Please consider using isolated CAN or RS485. I’m not preaching, just do an analysis where you do a short circuit supply to ground on the hand throttle (damaged cable), and an open circuit ground to one of the ESCs. You may find that you end up with some voltages at IO pins that will cause considerable current flow and a loss of the whole paramotor on inputs from, for example, the tacho signal from the ESC, or outputs to the ESC. A normal controller would have a tracking regulator feeding the hand throttle to protect the FC from loss of power in the short circuit case, and the ability to check the hand throttle for failures (supply overcurrent/voltage out of range). Similarly, a digital input from another board may well have a low cost HC14 based inverting schottky buffer and anti-alias filter, plus sufficient series resistance and double diode protection such that a 48V short on an input would cause no stress or issues.
All the best with it, looking forward to seeing progress.
Hey @Codemonkey. Some great suggestions.
I’m not at all a fan of i2c and hope to eliminate it from the system. I’ve seen way too many glitches, so want to eliminate it from mission critical systems. It’s fine for displays and stuff.
If you’re up for it, would love some fresh eyes for design reviews and such. Starting to get docs into the github for architecture and such. And starting to get schematics/pcbs in for the battery monitor (not safety).
Esp32 is dual core and thus able to delegate coms or inessentials to the 2nd core, if programmed correctly.
Thanks for the video. To answer his question in the video, it is normal to double buffer the global variables, with each task taking a local copy in a task prologue. A task writing to the global is handled in a write back during a task epilogue. If tasks need to sequentially operate on a global, that is handled by semaphores, and strong allocation of write permissions at compile time.
Multiple core micros do not offer any protection for safety critical code in their own right. That is offered by resources only being allocated to one micro, or by memory ring fencing (hardware blocking in inter memory bus accesses).
As an example, imagine the two cores are kids at primary school, both facing a common white board. The left hand kid is the careful kid, and draws a neat picture. The right hand kid goes crazy, and scribbles all over the entire board, destroying the left hand kids picture. That is the problem with common resource micros (imagine the board is system RAM).
One useful feature of heavy comms applications is heap space (dynamically allocated memory). However, a safety critical task ‘running out’ of available RAM is ‘inconvenient’ to say the least, so dynamic allocation is prohibited for high ASIL code.
It’s entirely down to the majority, but micros cost $4, and a more comfortable harness might cost $100 more. I’d spend a little more to get a micro with decent safety qualification, and use the ESP32 as a coprocessor. The other advantage is that it is quite likely that more tweaks will be performed to comms code, and having the freedom/peace of mind that a reflash of the ESP32 will (at worst) only lose your mobile phone connection due to a code bug is a major benefit.
The ESP32 (and its older sibling the ESP8266) is an excellent reliable affordable micro.
I agree that safety critical stuff could live on its own micro with limited I/O to be extra cautious, but the ESP32 is fully capable of handling comms and control on separate cores with properly written software.
That being said it seems a smart use of time and money to go with a fully tested and mostly off-the-shelf part for the flight controller and then use the ESP32 as a coprocessor for comms which has the added benefit of making it dead-simple to flash updates onto the flight controller wirelessly.
Uhhh so in summary: listen to @Codemonkey. Everything he said is correct.
I’m new here and I find this project fascinating.
Did anyone else notice the Teensy has CAN bus built in?
Is this flight controller intended to be a single custom board derived from something open? Alternately, is the goal to make a motherboard type thing that other off-the-shelf board plug into?
For those that are interested we are already beginning to prototype a new controller based on the Cortex M0. It will give us plenty of room to grow as it is a huge step up from the atmega328p that is on the current controller in the Arduino Nano.
The goal of easy customization still stands so we will be working to ensure that anyone can tinker with their own controller using the simple Arduino IDE.
I look forward to sharing more details as we get them nailed down.
Hey all,
I’m hooking up voltage and current monitoring, as well as PWM and motor RPM monitoring. Based on the suggestions above, my current plan is to use an ESP32, and bluetooth it to a cell phone for logging/etc.
I’m thinking of this module. Anyone got a better suggestion?
Should work great! I only have experience with adafruit’s bluefruit feather M0 board. it uses a BLE module with a separate M0 processor to tell the BLE module how to run. It looks pretty much the same as what you’re looking at, except it cost $30.
I’m new to this forum and PPG in general, but I love the idea of the "E"PPG and may be getting into it. As a retired EE having spent some time in aerospace cockpit controller design my question is where is the redundancy? Or, do we really need to address it based on getting down fairly soft and easy (with no power)?
Since I’ve got a touchy back I will probably go the trike or quad route, carry a fair amount of battery for an hour flight. Given that a trike or quad can carry some significant cargo, why can’t a hand throttle just be a cable to 4 independent controllers, one for each motor? Similarly, batteries assigned in 4 groups, one for each motor.
For the group, how long is a good flight in a PPG? I’m thinking the goal of one hour would be plenty of flying. Most of my private pilot flying in small aircraft is around an hour per flight.