Posts made by Ansel Misfeldt

@Zachary-Lowell-0 Got it working. It seems we encountered a documented bug where the defaults were somehow getting incorrectly set to the wrong parameter for RC input protocol when we reset the board to firmware defaults. We were checking the COM_RC_IN_MODE but had always had the RC_IN set to Auto previously. This made everything look fine until it glitched and changed the parameter without us knowing.

In case anyone else runs into it, here is the bug: https://github.com/PX4/PX4-Autopilot/issues/22986

Appreciate the assistance on figuring this out Zachary, we can switch over to Flight Cores and VOXL Flights for this client now which they'll be happy about.

@Alex-Kushleyev It was working on v1.11 for certain, and I recall it was working on v1.13 too, but seemed to stop working on v1.14+ from what I recall. We flashed them to different versions many times during troubleshooting and we weren't taking specific notes on which versions it was working on.

Let me know if you need us to test the specific version it breaks on.

I did more digging and it seems that the problem is related to the v1.14+ firmware I upgraded it to (from the Flight Core v2 downloads). For some reason in recent firmware updates it breaks the SBUS input.

I verified this by also upgrading a working VOXL Flight and was able to reproduce the same problem with the upgraded firmware in 1.14 and 1.15.

Any idea why this would break on the latest firmware releases?

Hello,

I'm trying to connect an SBUS receiver to a particular Flight Core v2 and it's not detecting it. The same cabling and receiver works just fine on a VOXL Flight, but this particular Flight Core v2 board won't detect it.

We haven't used SBUS with this particular board before (previously was using MAVLINK for control). We've tried the usual things like firmware updates, resetting all parameters, etc, but it won't seem to register the SBUS connection.

Is there something different with the v2 like requiring the signal to be inverted, or could there something wrong with this particular unit?

Appreciate any ideas anymore might have like a parameter that could be wrong!

Thanks!
Ansel

Anyone have any ideas here? We need to get Wifi working on this unit and are at a loss what to try when this is the only unit out of an identical batch of 7-8 that we set up with the same procedure and identical FW.

Hello,

One of our brand new VOXL Flights is having a wifi problem where it doesn't seem to be accessing the onboard wifi chip and is behaving differently than all the other identical units we've set up.

Steps
-Install system image
-Install voxl-suite
-Set up WiFi in access point mode
-Claims setup was successful, but no Wifi network is created

We then noticed there was no wifi network created so we checked and unlike every other system we've set up, this one doesn't have the second connection box for the Wifi network.


Any thoughts on how to fix this? From what we can tell VOXL doesn't seem to be communicating with the wifi chip to create the network. We've done this setup many, many times with the same procedure and firmware without issue, we're not sure what's going on.

Hey @modaltb,

Wanted to follow up again on this thread as we managed to make some progress.

We've continued troubleshooting and can conclusively say that the firmware linked to on the https://docs.modalai.com/flight-core-v2-firmware/#v1132-px4-support page does not work when flashed on our units. We finally tried downgrading to an older version of the firmware in desperation and it worked just fine. On the linked FW version the attitude estimator doesn't start up correctly which renders the controller unusable for flight. Not sure why it worked for you when you installed that version of the firmware but we were able to replicate the behavior on two separate units in our possession. Is it possible it went unnoticed that the attitude estimator was broken when you tested it on your end?

Wanted to share that insight with you and ask if there's any progress or an ETA on getting the QGC auto connection on windows fixed?

Thanks!

Will try the Pyserial on Windows on our end to see if that fixes our firmware issue, which I suspect it might given everything works fine on your end. It's a super busy week for us so will try to verify that by EOW if possible! Let me know what you figure out on the auto-connect issue!

@modaltb Awesome, glad you were able to replicate it! We'll keep working on the firmware on our end to see if something weird was happening with our firmware flashing.

Again, appreciate the help!

So we can confirm that the Windows USB driver is the main issue with the connection, it connected right away on QGC Mac. Looks like something's being buggy there.

We had a friend try installing the firmware via Mac instead of Linux just to test if something in our setup could be messing with the firmware, but couldn't get the bootloader to actually write the firmware and gave up after an hour of troubleshooting (that's the third engineer who's tried working on the problem from our end). We'll keep working at it on our side but we're running out of new computers to test things on.

Any thoughts on why our firmware seems to not be working correctly (e.g. attitude estimator not running on bootup)? Could there be a glitch we're running into on our machine during the firmware installation that would mess with that?

Will be good to see if you run into the same connection problem on Windows too.

Great, thanks!

We'll also try repeating everything on Mac instead of Linux to see if we can further troubleshoot on our end in case something weird is happening with our Linux build.

Hi @modaltb ,

Really appreciate your help on this! I figured the connectors were a red herring. And understand about the MAG, I get that not everyone wants to use it as they can be prone to interference when not separated. Thanks for the re-enabling script instructions!

It looks like the connection is a Windows issue as that's how we do out setup (because that's how most of our clients access the drone in the field). It shows up normally as a COM port but for some reason QGC doesn't seem to be recognizing the FCv2 where it doesn't have issues with FCv1, VOXL Flight, or VOXL 2.

The status looks identical once the manual connection is established:

Airframe is also looking the same but without the dev of course:

I also took a screenshot of the console in case that helps. This is where a link has NOT been established, so QGC clearly sees the device on the COM port but doesn't connect to it. The streamer error is because it's looking for streaming video (eg. a VOXL Flight setup) and none exists:

Could you try a Windows connection on your end and see if you get similar results with v1.13.2? We're getting the same thing on two different Windows computers we've tried on our end.

Still not sure why our firmware flashing seems to produce some buggy startup issues on the unit, we'll keep testing the firmware side tomorrow to make sure we didn't miss anything.

Hi @modaltb,

Making some progress here, that explains the MAG question, thanks for the clarification on that!

I've been doing some troubleshooting with the various v2 boards we have and this is what I've found:
-We're definitely using the J3 port for USB
-We bought three new v2 boards, none of them connect natively to QGC (v4.2.4, tested on multiple computers)
-In order to connect it needs a manual COMM link for any of these three boards to be recognized, and must be set to a BAUD rate of 115200
-We upgraded FW on two of the boards and have one left in its default shipped state

The board in the default state is mostly working aside from the QGC connection issue.

• The one board we have not updated the FW still has the Attitude Estimator working when it connects via the manual COMM link in QGC. This might be an earlier FW version because the compass is working without an external MAG plugged in so it seems the onboard MAG is enabled on this particular board (FW v1.13.1dev, custom FW v0.0.9). The J12 port is a beige instead of yellow on the other two boards, I don't think that would make a difference but wanted to mention it in case.

• The two boards we updated the FW as per px_loader.py seem to have issues around the attitude estimator no longer booting up once the new FW is installed (v1.13.2 custom FW ver 0.1.1)

Any thoughts on what could be causing this? Could there be an issue with the more recent FW file? The difference in FW versions seems to be the only difference we can see, aside from the fact that QGC still won't recognize any of the boards without a manual COMM link that you don't seem to be having the same problem with.

As always, any thoughts or troubleshooting help is greatly appreciated!

Hi @Chad-Sweet,

We followed all instructions on the 'general user guide' as listed to install v1.13.2-0.1.1 and that's where we're running into issues.

Are there further steps we have to take to get it working right (e.g. using an STLink)? Our reading of that page was that we didn't need to go through the steps in the developer guide below as we're not doing anything custom with these.

Any further guidance would be appreciated, we did this on two separate boards with the same result.

Hi, we got our first shipment of v2 and started installing them in drones only to discover several problems that render them unusable in their current state.

Issue #1 - connection problems to QGC
They won't natively connect to QGC so we flashed the firmware as per the instructions and they would still not connect.

After much trial and error we were able to connect with this process:

• We were finally able to manually set up a COMM link in QGC by setting the BAUD rate to 115200 and were finally able to connect to QGC.
• If we reboot PX4 via the software it will not reconnect again until we quit QGC and reopen it

Issue #2 - Setup issues discovered with default firmware
The main issue we're having is that the sensors don't seem to be working correctly, as we can't successfully go through sensor setup.

• On sensor calibration I get an error message saying the 'attitude estimator is not running - check system boot...'
• We were told v2 included a mag sensor but none is being recognized. Not sure if we were told incorrectly or it's not being recognized in the system.

Given the vehicle won't arm without an attitude estimator and customers can't access settings normally this is a major problem for us. Unfortunately, we don't have any more Flight Core v1's in our inventory so we can't deliver drones to customers until these issues are fixed.

Is this a firmware issue because this is a new release? Is it possible the wrong firmware was linked on the main page?

Any help would be appreciated!

Is VOXL 2 eventually going to support CAN connections in the future (e.g. with a breakout board), or is that simply not a connection type that's going to be supported?

We use a number of CAN devices with VOXL Flight / Core and it's been holding us back from adopting VOXL 2. Figured it was worth asking!

@Chad-Sweet Yes, it usually is a good starting point. I do want to mention it took us 3 or 4 separate resets of all related radio settings before this particular glitch went away.

@tom Thanks for your thoughts Tom, it was new to us as well! We seem to have managed to fix the problem but we're not entirely sure how / why. Our best guess is that was a software glitch with the Microhard radios themselves.

I'm documenting what we found here in case anyone else runs into a similar issue in the future.

We were able to eventually duplicate the same problem on another UAV that had previously been perfectly stable, thus eliminating the VOXL as a potential cause with two separate units showing the issue.

We were testing a variety of settings today (e.g. channel, bandwidth, power of transmitter, which module is master vs slave) just to try and identify if anything made a difference. Eventually after re-setting the settings back to the microhard defaults (which we had done several times already), the problem mysteriously stopped. We've since kept a stable link open on two UAVs for the last ~6 hours without issue, so we suspect that there was some software issue that eventually cleared when we modified the settings. The last change we made was testing which module was master/slave, and after swapping them and then swapping them back the issue went away.

Really puzzling issue, we're just glad it seems to be fixed. As I said, we suspect it was an issue with the radio and not with VOXL. Why it would be perfectly stable with one drone for hours and then have an issue with a different identical drone is beyond me.

You guys do great work, keep it up!

@tom Yup, you're fully understanding the situation. Just the one drone is having this problem (with microhard modem+carrier board), all others seem perfectly normal.

Tried replacing the modem + carrier board on the affected drone with a spare and it has the same behavior.

Would the next step be to try re-installing VOXL Suite and redoing the microhard setup?

We have several UAVs all operating with 1.8GHz Microhard modems and VOXL Flight for communication with the GCS (SkyNav or laptop).

We've found the connection will drop for ~0.5-1 second every 30 seconds like clockwork when the problem begins, but when it starts and stops appears to be random (e.g. sometimes it happens immediately and other times can have a stable connection for >1hr without issue).

Without touching the hardware (and testing in multiple locations to rule out an environmental problem), we've observed it starting on startup, after 6 minutes, 16 minutes, and 31 minutes of connection (to provide some examples). Then, every 30 seconds the connection will momentarily drop before fixing itself, with a visible interruption in UAV telemetry. Typically a reboot will not fix the issue.

It only happens on a single UAV that we believe to be configured identically to others. We've also ruled out a temperature problem with the radio and every hardware factor we can think of.

Our best idea is to re-flash the firmware as it appears to be a software bug, but wanted to check on the forums here in case anyone has run into a similar problem or has an idea for what it could be.

Thanks!