Hello I looking for information on SmartRTL can’t seem to find anything except the video. Can someone link me the information to read up on this flight mode?
Randy,
Great job on 3.6… I see DShot (no ESC calibration!) and ESC telemetry as great features to help understanding how ESCs are performing under load.
I would like to test them, but you’ve mentioned they are only available in ChibiOS. Are the links you’ve provided, such as http://firmware.ardupilot.org/Copter/beta/fmuv2/, pointing to the ChibiOS firmware to PixHawk 1?
One more question: what is the envisioned approach for DShot for octo drones? I understand on PixHawk 1 and Cube 3.6 firmware is relying on aux channels, which are limited to 6.
Thank you… Luis
@Fnoop,
The ChibiOS ports haven’t been flight tested much. I’ve actually only flown it once :-). My feeling is that it’s quite solid but it’s probably not a good idea to put it on a vehicle that you would be horribly upset to have crash.
P.S. sorry for the delay in replying.
Thanks for the detailed feedback on SmartRTL. It is “expected behaviour” that the pilot gets no control of roll, pitch or yaw until the last few meters. “Expected” but perhaps not great behaviour so I’ve added an issue to always give the pilot yaw control and another to allow the control to return earlier. The yaw one at least should be easy to do before Copter-3.6 goes out. I’ll update the wiki as well.
Re the failsafe behaviour, you’ve already figured it out but in any case, the battery failsafe actions include both SmartRTL and regular RTL. So it really depends upon how that parameter is set. BTW, I need to update the docs for the parameter changes for the battery failsafes as well because they can now apply to multiple batteries but sadly the param names had to change…
Brandon,
Here’s the wiki page on SmartRTL. From a user point of view, there’s not a heck of a lot of parameters to play around with. Just the accuracy and number of points. The number of points can be increased up to 500. It’s set conservatively to 150 points because more points takes more memory and we need to do some more testing to see what is a comfortable number. Of course, it shouldn’t be dangerous to set the number too high. It’s just unlikely to work.
What we also need to add to the wiki is info on what happens when you run out of points. The short answer is that a message will be displayed on the ground stations’s HUD and you won’t be able to switch into SmartRTL.
Hi Luis,
I’ve created the wiki describing how to upload the ChibiOS firmware now. The fmuv3 firmware is the one to use for the Pixhawk1 and Pixhawk2/Cube boards. The only real difference between the “fmuv2” and “fmuv3” is that “fmuv2” has a few less features so that it can fit onto the older Pixhawks with the 1MB limit. The ChibiOS builds are all below 1MB so even the fully features firmware fits on the older Pixhawks now.
Re OctaCopters on DShot, my understanding is that we want to enable DShot for the main outputs (which actually are run from the Pixhawk’s I/O chip) but it hasn’t been done yet. I’ve added an issue here.
P.S. when was the last time we heard of a piece of software getting smaller?!
2 Likes
Alan, Roman,
Thanks for the report, we will look into it and fix it!
Winston,
I’m not sure if Pixhawk mini is supported in Copter-3.6 or not. I know work has been done to add support but I think it’s not included yet. I’ll double check with @tridge.
Edit: I’ve checked with @tridge and the Pixhawk-mini is supported.
So, if you fly “too long” you’ll eventually not be able to Smart_RTL anymore? Why wouldn’t it just kick out the “oldest” point, thus when yo Smart_RTL it’ll backtrack all the points it has and then switch to regular RTL at that point? Also, what is “too long” does it plot a point every X seconds or something? It would be useful to be able to guage what a user would need to set in SRTL_POINTS based on the amount of time their system can stay in the air. Also, so they can gauge how much memory they need.
oh, feeling like the invisible man…
Hi where do we make testing notes for ChibiOS?
having issues connecting with the sik radio using CHi after reverting back to 3.6 Nut the Radio connected.
G’day Brandon,
I’d suggest opening an issue in GitHub and then drop a link into the ArduPilot/ChibiOS gitter channel. Thanks for testing!
1 Like
Brandon,
… re ChibiOS issues, it’s probably best to create new threads in this Copter-3.6 forum so we can discuss and investigate before creating an issue. Jumping straight to creating an issue is probably OK but normaly we like to verify the reports before creating issues.
Chris,
Re the analog sonar “flyaway” issue (only possible if sonar has been misconfigured), it’s not resolved in Copter-3.6 I’m afraid.
Sounds good… The new 3.61 flew nice today thank for all your hard work guys!
1 Like
LordNeeko,
Re SmartRTL’s behaviour when it runs out of points, yes, it could certainly be improved. Another idea is to automatically increase the “SRTL_ACCURACY” parameter from it’s default of 2m to something larger (like 3m). This would also likely make it suddenly free up a lot of points.
Yet another idea is to improve reporting of the number of unused points to the user and/or allow a failsafe to be triggered as SmartRTL become unusable (i.e. triggers SmartRTL when it runs out of points).
In the end it just comes down to developer effort on the feature to make it better.
In any case, I hope is that with a bit more testing we can increase the default number of points a lot so most people won’t bump into the problem.
1 Like
Roland,
Re Pixhawk-mini and D-shot, we will need to complete the port to ChibiOS for this board I think. I’ll check with @tridge on that because he and @bugobliterator are the ones who have the best idea of how the ChibiOS work is coming along.
I’ve just tested landing gear on a Pixhawk1 and it appears to work but of course that doesn’t mean that there’s no problem. let’s take this discussion over to this new thread.
http://www.sendbox.fr/e6d7163948afa863/8_23-04-2018_10-29-48.bin
I went back to 3.5.5 to test the platform works, so maybe a problem in 3.6 rc1?
thank you for your excellent work
Totally understand it’s a first iteration.
So instead of a X per second it’s after you’ve moved a distance of SRTL_ACCURACY? That makes more sense for sure.
If someone has battery or THR or whatever failsafe set to SMART_RTL, and the mode isn’t available, does it automatically transition to RTL already?