Hi Andrew,

We have other folks using it for controlling ESCs, let me try to see what I can find as far as examples, we don't have one in our repos.

PX4 itself has a UAVCAN implementation they've been working on that might be of help: https://dev.px4.io/master/en/uavcan/index.html

Thanks!
Travis

Thanks @modaltb , that worked! I had to set it to run as a background function using the &. It's running perfectly now.

I probably want to rewrite it as a task, but that example code looked tough to follow. I wish the PX4 developer manual included more step by step tutorials, like the ROS tutorials.

Thank you @modaltb. I was able to control the LED with my code (yellow = waiting for serial, blue = data valid, red = data not valid).

Hi @Andrew-Keefe,

I'm not positive on this one. I have an example of using UART for an ESC here, and I remember having to be careful what task was opening the UART port:

https://github.com/modalai/px4-firmware/blob/modalai-1.11/src/drivers/uart_esc/modalai_esc/modalai_esc.cpp#L736

Here's opening of the port (note: this is beta level code)

https://github.com/modalai/px4-firmware/blob/modalai-1.11/src/drivers/uart_esc/modalai_esc/modalai_esc_serial.cpp#L48

Hey @Andrew-Keefe ,

This isn't something I've tried. Curious as to what the setup looks like if you're up to share more details.

Thanks,
Travis

Well, we aren't routing the 5V on that little M0022 board to prevent it being used to drive servos (for this concern). But 5V does come down to the connector, so it could be soldered to, and you could create solder bridges on the bottom of the board. Not ideal, but 5V is there, just not routed....

I know this is kinda an old post but I have created a driver for px4 that can use both flavors of the MS5837 the bar2 and bar30. I will create a pull request with px4 so it will be available.

Ah, when I run the PWM program there is no chatter on the PWM signals, so I'm going to review that code again and compare it to mine.

Indeed it was the diodes! I was able to fix one board by bridging the pads with some solder, the other one had the pads completely gone. Very strange, the flight cores are powered by the VOXL with the serial pins connected as well, but I don't see how that could cause hardware damage?

@Adarsh96 Hey there, reading your issue reminded me of something I once experienced.
EKF not initializing position is a separate issue but I can tell you if you're able to arm the quad amd have the motors spinning, it should be good.
What flightmode did you arm it in?
Because with some you need to raise throttle above 60% to takeoff.
Just a thought but you might have just been in the wrong mode bc quad arming means you're basically ready to fly. 😉

We test all of our PCBs thoroughly before they are shipped. We do ship the PCBs bare though, which means they are susceptible to ESD and other damage. We really can't warranty against how different people may handle the PCBs.

We publish handling instructions that are also shipped with the PCBs, found here

An issue many run into with Flight Core is that they plug USB into the Spektrum port and fry the board.

The RMA diagnostic process is for ModalAI technicians to spend time looking into the root cause of the failure, and then provide analysis on what to do next.

@modaltb Interesting, that's good to know they should be identical (what I assumed), that's why I was puzzled when it didn't seem to work.

On VOXL Flight we're using port J13 and it's always worked perfectly without issue the first time we're wired up a new unit.

I have not tried starting via the command line, but that's a good idea to try.

My best guess is a loose connection in the wiring somewhere or a pin not making good contact on the board. If it should be working the most obviously problem is user error on our part or something not making contact properly.

We ended up sending them one of our VOXL Flight units where we knew it worked perfectly each time instead of using the Flight Core because they were in a rush to get things working.

Thanks for the suggestions!

Outstanding! Thank you for following up

Hi Adam,
By default we have J5 TELEM as matching PX4 formats, with +3.3V signaling and the +5V power. We do not recommend operating J5 or any of the 3.3V based ports at 5V signaling.

There are a few things to note:

The default range of the pins in the MCU spec is a max of 3.6V If you want 5V signaling, consider using J1 which is 5V signaling, but note the pinout is a different format by design using a DF13 connector instead of the JST-GH

https://docs.modalai.com/flight-core-datasheets-connectors/#j1---voxl-communications-interface-connector

Although the MCU claims it is 5V tolerant, there are functional configuration limitations on that tolerance that the PX4 images may include, such as internal pullups. Refer to the STM32F7 series MCU spec for details on their 5V tolerance. It is limited. If you were to run "bare-die code" (not PX4) and meet the MCU limitations, and consequently drive inputs at 5V, keep in mind your outputs are still 3.3V based, so your 5V device you are trying to talk to (if it is a CMOS input) will not register the HIGH voltage and your interface will not work. Hence overall our recommendation is to keep 3.3V specified interfaces at 3.3V.

Let us know if you would like any further info.
Thanks!

@Jimk_Aero

Sorry so hear that you're still having problems. The built-in BEC shouldn't be required for basic use case. Unless you're trying to power some other on-board electronics/avionics with the BEC.

All you should need is the "power in" to all 4 esc's from a PDB and then signal and ground from esc's to flight core J7, via the breakout board.

Modalai's breakout board was designed for PWM signals only and works well in that regard. Also check to make sure that DSHOT_CONFIG
is set to "disable"

Here's some notes from our board designer to clarify.

The primary design intent was to be used with a distribution board for power

It is actually unsafe for these types of pin headers to have exposed voltages on them

We wanted to prevent some customers from accidentally installing two BEC generators on these blocks which occur all the time in other hobbyist forums/kits and customers end up damaging their BEC modules.

We apologize we did not make it clearer this is just a breakout board and not a BEC distribution block.

@modaltb Thank you for your answer, it is true that the problem is caused by the lack of magnetic compass.

Hi @Jimk_Aero ,

Sorry to hear about the problems. Not being able to power off USB does make this hard and is a carry over from the VOXL Flight....

Even without ESC calibration, you can manually attempt to spin a motor, if using PWM, via this: https://dev.px4.io/master/en/middleware/modules_command.html#pwm
Do you have an oscilliscope? You could probe the PWM channel output pretty easy (pins 2-5 for a quad) and see if you see any signal coming out of the board. If there's no signal, when you expect it, on a single channel, try to look at those ESD diodes right next to the connector and check for any fried parts.

PX4 FW version you are running? There are two programs to handle some edge cases, px4-esc-cal-tool-v1-11.py and px4-esc-cal-tool.py

Yes, this "can" work, but it is not ideal due to the many unknown variables on someone's host PC. Hence it is not a default option, and we would not recommend it. Issues can range from USB VBUS being out of spec (as it is, it is allowed +/- 10% which puts it in on the edge of our needs), and most "correctly designed" PCs will not provide more than 100mA unless a device is enumerated that asks for more. I'm not sure if all version of PX4 do that correctly. 100mA is insufficient for most use cases.
In a strictly "QGC config" mode, I can see this work, but it is not something we plan on supporting on this version board due to those risks above. This also opens the door for someone to leave that power feed in-place while then later connecting the power module which will create a serious power rail shorting problem between the module and the PC.
However, we do have a design already figured out that can take USB power for QGC/Config type of applications, and it validates the VBUS through a smart fuse/mux before using it. This will allows us to globally claim support, and if someone's system is not correct or out of range, we protect the HW.
Stay tuned!

@Zeev-Mindali Checkout your options here: https://www.modalai.com/pages/rma

Flight Core does not have an internal magnetometer (compass) so there's no need!