thats my flock of 12 swans, run on Pixhawk and Ardurover. They are doing shows on light festivals: https://vimeo.com/387663421
Right now I have a strange problem. Some of the swans suddenly abort their missions. Some just stop and do nothing, some trigger a RTL. But when I look into the logs I don´t see a failsafe.
The location right now is an urban area / quays with a challenging magnetic situation. So I suspect this as a possible reason.
But I wonder why there is no EKF failsafe shown in the log file. Normaly, when I face too long GPS glitches I get the EKF FS displayed in the value graph window.
Is there any other place to look for failsafe events? Or any other ideas what causes this issue?
Here are two logs:
abort with RTL: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
abort without RTL: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
how are you controlling all these? do you have a radio for each one? the second one looks like it was caused by the radio switching modes but to RTL instead of manual.
Thanks!
Each swan has its own RC radio. To arm them and in case they try to escape. Normaly I deactivate the radios when running a mission. (I disabled the radio failsafe when in mission).
Yesterday when it happend, the radios were on, but not touched. The manual mode switching in the log that was me, after I recognised that they were out of the choreography.
The bad thing is, when a swan leaves the mission, I cannot bring it back in again. Thats because the whole flock is syncronized by UTC triggered delays every few minutes. UTC is the only possibility to sync them. So if a swan makes trouble and therefore cannot reach the next delay waypoint right in time, it waits for the set UTC next day.
The radios are Radiolink T8FB, cheap stuff. But I can´t imagine that a 3way switch can drift that much, or? The switch is set up as auto / manual / RTL.
FS_ACTION is set to 1 (RTL)
FS_THR_ENABLE is set to 2 (enabled, continue with mission in auto)
Radiolink are decent, but I was meaning how did you set up the failsafe on the radio, are you setting the throttle position below failsafe value?
As far as I can tell, they were moving when they were switched, did you say they stopped or what specifically were they doing that caused you to switch to manual.
Actually I didnt care about the FS on the radio yet. And with FS_THR_ENABLE 2 Ardurover ignores a signalloss anyway when on mission. Maybe next step could be to switch the radios off right after switching to auto, just to see if that problem happens without the radios.
What they were doing when they stopped I can´t tell exactly. I recognized it not at that point but some time after, when they obviously didn´t join the choreography anymore. Which is kind of challenging with that sack full of fleas.
Ardupilot only knows its a failsafe if:
Sbus or ppm signal is cut off
throttle channel goes below failsafe value.
If your radio is not doing either of those things, then the radio failsafe is not setup correctly.
Your radio might be trying to set all channels to different failsafe values rather than setting the throttle below failsafe value or cutting it off when signal is lost. Ardupilot can’t tell the difference between the receiver setting modes and pilot controlling the modes.
have you tested them to see if they say throttle failsafe when the radio is switched off? im sure it should still say it even when set to ignore in auto.
Seems like I got it.
The show today had two swans leaving the mission. One just waiting, the other one was on its way to Africa, which I last time misinterpreted as RTL.
From both swans I downloaded the missions back to my laptop and figured out that the downloaded missions differed from the original ones that I uploaded to pixhawk.
The swan that was on its way to Africa had a corrupted waypoint with the coordinates of 0,0. The other swan had a corrupted delay command.
Seems like it happend due to the upload. Normally I upload the missions with baud rate 115200, which may be to fast. But I never faced that issue before. Tomorrow I will try with 57600 and re-check beforehand, which is kind of challenging. 12 swans with 650 commands each.
The missions itselfs are script-generated.
Its uploaded via USB.
For example that is one of the corrupted delay command:
original:
559 0 3 93 -1 21 9 50 0 0 0 0
back from pixhawk:
559 0 0 93 0.00000000 1.00000000 49.00000000 -33.00000000 0.00000000 0.00000000 0.000000 1
Also I think you should just do away with the RC stuff, just use a mavlink connection to do manual controls, This is also a perfect application for using a mesh network, maybe something like LoRa. Very cool project.
USB should be more reliable than almost any other method. I routinely upload 200-300 waypoints via USB and MAVFTP. For 650 waypoints, I’d almost certainly use USB if possible.
Have a look at your file formats. Take a good look at the white space and number formatting. While I’m sure it’s consistent, it may not be consistently meeting the autopilot’s expectation.
Completely agree that ditching all RC control is a good idea. That’s a lot of RC hardware to manage, maintain, and keep interference free.
Rather than using USB for them, I would just get some cheap pixhawk wifi adapters and set them all to connect to a hotspot, either your phone, a standalone access point or hotspot. that way you can power them all up and its much faster than any uhf or lora system, its secure, you dont need to upload waypoints at long range so it should be ideal for your use.
The show last night went very well without any issues, after uploading the missions at 57600.
I guess it may have been the SD card in combination with high baud rate uploading.
Thanks for all the hints and links!!
I just switched to 57600. The swans will run a few more times every night. After that I will have a close look at the cards. Maybe I should disable the logging. The duration of the choreography is five hours each day. A lot of writing going on on the cards.
