ESC Issue On SDK 1.0.0
-
@John-Nomikos-0 Okay, I don't see anything obviously wrong with those. Can you arm the drone and collect a log?
-
@John-Nomikos-0 When you arm you are using the
-fflag to force it. What happens if you don't use the force flag? Does it give you some errors? -
@Eric-Katzfey John left to go home, but popped into the other room to run this
I keep on getting a failsafe activated the MOMENT we try and arm.
I can not seem to get more than this message. I am going to manually run voxl-px4 to see if I can get better output
-
Here is the output from voxl-px4 once we requested to arm
INFO [px4] Startup script returned successfully INFO [muorb] SLPI: Advertising remote topic ping WARN [uORB] orb_advertise_multi: failed to set queue size INFO [uORB] Marking DeviceNode(mavlink_log) as advertised in process_remote_topic INFO [muorb] SLPI: Armed by external command INFO [logger] Start file log (type: full) WARN [uORB] orb_advertise_multi: failed to set queue size INFO [logger] [logger] /data/px4/log/2023-03-02/12_59_17.ulg INFO [logger] Opened full log file: /data/px4/log/2023-03-02/12_59_17.ulg WARN [mavlink] Event dropped (37, 65526) WARN [mavlink] Event dropped (37, 65526) INFO [muorb] SLPI: Advertising remote topic logger_status WARN [mavlink] Dropped 65489 events (seq=65526) WARN [mavlink] Dropped 65489 events (seq=65526) INFO [uORB] Marking DeviceNode(mavlink_log) as advertised in process_remote_topic INFO [muorb] SLPI: Failsafe activated INFO [muorb] SLPI: Disarmed by failsafe INFO [uORB] Marking DeviceNode(parameter_server_set_value_request) as advertised in process_remote_topic WARN [mavlink] Event dropped (65527, 37) WARN [mavlink] Event dropped (65527, 37) WARN [mavlink] Dropped 28 events (seq=37) WARN [mavlink] Dropped 28 events (seq=37) INFO [muorb] SLPI: Marking DeviceNode(parameter_server_set_value_response) as advertised in process_remote_t INFO [logger] closed logfile, bytes written: 221550 -
@wilkinsaf Okay, that's not very useful. Definitely going to have to figure out a way to make PX4 provide an actual reason. Our ESC guru Alex thinks that the older ESC firmware you have defaults to a different baudrate than we are expecting in SDK 1.0.0 PX4. So he will respond later with the ESC parameter change that will allow them to have the same baudrate.
-
@Eric-Katzfey Thanks Eric.
I imagine we are going to have to connect the ESC to FTDI to laptop. Or is it possible to change this on VOXL2 terminal.
-
I guess Alex will know that. Thanks!
-
@wilkinsaf You should be able to do it directly on VOXL2 with voxl-esc.
-
Based on your description of the problem (when you switch from SDK 0.9 to 1.0.0, the ESCs start responding), it sounds like a mismatch in the UART baud rate in ESC and PX4 params. When going from 0.9 to 1.0.0 we have changed the baud rate for ESCs in PX4 params from 250K to 2M. Accordingly, we have updated the ESC params to 2M as well (ESC firmware and params are part of
voxl-escpackage). However, since you did not perform an ESC firmware / param update, your ESC is still running at 250K baud rate, but the latest PX4 is expecting 2Mbit.From your output of esc scan, this is confirmed:
INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 250000You have several options:
- Change your PX4 param MODAL_IO_BAUD from 2000000 to 250000 in order to match what your ESC is currently using
- Update the ESC firmware and params while the ESC is connected to VOXL2 (with SDK 1.0.0 installed, which will have the latest
voxl-escpackage with latest firmware and params). Please see this post about updating firmware and params: https://forum.modalai.com/topic/2509/voxl-2-mini-with-mini-4-in-1-esc-no-battery-information/5 . Please note that if you are currently using non-standard ESC params, you will need to make a few updates to them in order to make them compatible with the latest parameter files. If that is the case, let me know, i can help.
Alex
-
Confirmed, changing the MODAL_IO_BAUD to 250000 fixed the problem for me. Thank you so much for the help!
