Enhancements
a) Guided mode supports using SCurves and OA for position control (set GUID_OPTIONS = 64)
Bug Fixes
a) Serial port auto detection of flow control fix
So just two fixes but the 2nd bug fix was serious enough that we though we should release the fix quickly.
Thanks again for your help with beta testing. Things are looking pretty good so we may be able to release 4.1.0 as the stable version within 2 weeks if all goes well.
Hi,
In order to setup bdshhot configuration, do we need to flash the custom selector ending in bdshot(ie mission planner) or directly with the beta firmware from any GCS
Because bdshot requires exclusive access to DMA channels and that removes them from things that were using them in the original configuration. Where there is no original configuration I have attempted to include bdshot in a single config.
I been using the wrong Firmware version as i use Dshot. I was not sure it was for a special case only… thanks for the explanation. To be clear if you run Dshot only use the bdshot compile in said directory.
I wonder when we get new builds if Randy can place a note in the Update. Like "also included the Dshot build for the testers with Dshot configs. "
Regular firmware will work with dshot - it’s just bi-directional dshot that requires the bdshot firmware, but conversely the -bdshot firmware will work fine even if you are not using bi-directional dshot
Actually to use SCurves for Guided mode’s position control you’ll need to set GUID_OPTIONS = 64 (Waypoint navigation used for position targets). Sorry for not making this more clear.
The reason that we need to have two options for position control is that for companion computer users, they want to send in targets at very high speed and this is incompatible with SCurves. For regular users who just want to click on the map once and have it also do object avoidance on it’s way there, SCurves will work better.
Users who aren’t intending to use object avoidance (including Dijkstra’s to get around fences) will probably not notice a difference between the pure position-control and SCurve methods. Both are jerk limited, both can do terrain following. The only difference I’ve noticed is that the SCurve method makes the initial turn to the target point a little more quickly.
SCurves are never used when the companion computer is providing velocity or acceleration commands.
Thanks again for testing and sorry for not making this setting more clear in the release notes.
After I updated from 4.0.7 on a CubeBlack, the EK3_IMU_MASK is set to 3 by default (I had EK2_IMU_MASK set to 7 before). Is this intended behaviour? Shouldn´t all the IMUs be enabled by default, like described in SB_0000002 from Cubepilot?
Also what about EK3_GSF_RUN_MASK and EK3_GSF_USE_MASK? Should these not be the same as EK3_IMU_MASK?
Great stuff - I’ve noticed recently that I can no longer connect to APMPlanner with newer builds of Ardu. Was there a Mavlink update that would prevent it from connecting? Linux user so not sure if I need to change to qGroundControl…
AP_Motors: always use PWM min and max, don’t take from throttle. #18576
I had some major issues using the old esc calibrate a few days ago does this mean that i can’t auto calibrate endpoints anymore? Normally i calibrate the radio then calibrate the esc and it always does the job for non Dshot old esc’s. The issue i had was going from dshot to normal and using esc calibrate then the endpoint where off and burt a motor that was a mess. Honestly i never seen anything like it.
