Drone doesn't arm indoor

🧪 Flight Testing & Log Analysis
1

Hello everyone, my issue is that I can’t arm the drone indoor where GPS info is not available.
The drone FC is connected to my pc using a USB-UART cable and the Agent-Client connection is properly configured as stated in the px4 docs guides with a baudrate of 921600. I have two questions:

  • Since the drone is in a GPS denied environment does it need an external source of position estimate like a MoCap system in order to correctly arm? Or this applies only to takeoff?

  • Is a baudrate of 921600 enough for the drone to arm or It needs a much higher rate?

Also, since the FC I’m using has only 1 MB of flash memory when flashing the px4 firmware I couldn’t put all the modules contained so I selected only the ones that I though I needed. Do you think could also be that the arm issue is related to some modules not present in the drone firmware?

Thanks,
Ronald

2

It depends what you want to do. If you want to do a takeoff which is essentially an “autonomous” mode, then it does need some position estimate, e.g. from GPS, Mocap, flow, VIO. If you fly manually e.g. in altitude or position control, then you don’t need it.

That should be plenty of bandwidth, however, the question is what you want to be sent over that link. If it’s just manual control up and telemetry down, then a radio with 57600 is even enough. The other part is of course latency which is different from just the bandwidth and determines how dynamic/fast you can do controls.

That makes sense.

Yes, potentially. I suggest to connect with QGC to the MAVLink telemetry and it should usually tell you why it can’t arm. If you can’t do that, then you can try to set the param SDLOG_MODE to always log. Then you try to arm and afterwards check the messages stored in the log. They might hint at what is wrong.

3

@JulianOes I have to perform activities in “autonomous” mode, therefore now I understood that I need to link my drone to the VICON system that we have on lab.
The idea is that the drone should be controlled by a ros2 python script and reach multiple setpoints inside the indoor area. The thing is now I’m using a USB-UART connection from FC to my GCS in order to perform the first tests and here the baudrate is 921600 but the intention is that the ros2 script should start directly from the companion board, which has a max baudrate of 115200. Do you think that is enough? If not I have to select another companion board that reaches 921600.

Here is the log file https://review.px4.io/plot_app?log=14762313-2cf2-4250-82d1-ef46beb825f1 and as you can see in the Failsafe Flags graph, the local position/velocity invalid is set to 1 even if I’m in Offboard Mode.

4

I almost don’t believe that. Surely it can do more?

5

@JulianOes I’m using as a companion board the NanoPi Neo Air for which I couldn’t find online any reference on the baudrates for the UART connections. Instead, I’ve tried to run communication between the Agent on the companion board and the client on the FC and if I try baudrates higher than 115200,say 230400 bauds, the communication doesn’t even start, Agent and Client can’t see each other.

6

Have you tried 1500000 baudrate?

7

@JulianOes Hi, yes I tried today and It worked. So it was a matter of choosing the right baudrate. Moreover, I finally succeeded to arm the drone via ros2 script using Vehicle Attitude Setpoint.

The final issue that still remains is to arm it using the external position estimate. I’ve created a script in which fake mocap position coordinates are passed using the vehicle_visual_odometry to update the ekf2 estimate but the drone is not arming. We will open a new post about this.

So, thanks a lot for helping.

1 Like