@rmackay9, you ment BRD_BOOT_DELAY parameter ?
Gal
1 Like
Thank you for your hard work randy and other developer who involved in this release.
By default this value is BRD_BOOT_DELAY is 0.
As you said randy dynamic Alt change and dynamic ground speed change in auto mode will work in AC 4.x release.
But I have tried many times it’s not working at all,When I go extended tuning parameter page and change wp_speed to what ever value then only it take effect.
In auto mode there is no stop and turn method even AZ degree goes above 90 degree from current heading but sometimes it does I don’t couldn’t find the reason. Whem does it will make stop and turn and bank turn (current method) it use roll as well about 13 to 15degree to achieve within this desired point. But it looks sometime very Stanger.
Please give me some feedback to over come this issue.
Good day, ive install today the version 4.0.1, ive a drotek r3100 wired on mro can bus on the i2c after the calibration the rm3100 its not recognize, setting the boot delay as you adviced but nothing happened.
I did not find the same issue on version 4.0.0.
i will attach the log25.01.2020.bin (283.5 KB)
Mav FTP, on pixhawk 2.4.8 is not working. In ‘dev’ firmware ftp is working(from https://firmware.ardupilot.org/Copter/latest/fmuv3/), but there are down some other fings, like radio control with telemetry, heh it can’t fly in one word.
Re dynamically changing the target ground speed, there appears to be an issue in the Mission Planner which I’ve raised an issue for here. I’ve tested the flight code with the MAVProxy GCS and it seems fine so pretty sure it’s a mission planner issue.
Copter doesn’t support dynamically changing the altitude during missions. There’s already a request on the issues list covering this but I can’t promise when we will get to it.
Re “stop and turn” in auto mode, I think you’re referring to this long standing issue re copter’s navigation algorithm. For now the best advice we can give is to add a delay to the waypoint (set the first parameter to 1). In a future version of Copter we will include Leonard’s S-curves navigation which will make things better.
1 Like
There was an issue with the build server which meant that Copter-4.0.1 didn’t go out at the expected time. It’s out now but from looking at the log you’ve provided the vehicle is still on 4.0.0. Perhaps something else has changed in the setup to cause the rm3100 to not be recognised?
I’ve just checked MAVFTP using MP with a CubeBlack running Copter-4.0.1 and it appears to work. I press Ctrl-X and then I can open the APM/TERRAIN folder and see some .dat files in there.
I wonder if perhaps MAVFTP is not available on the fmuv2 builds and that this is what is being loaded onto your board if MP’s firmware install screen is used. The firmware that is being used is shown in the messages sent to the GCS soon after a connection is made. For example below is a screen shot showing that I’ve got the CubeBlack on my board. Can you confirm you have the fmuv3 firmware on your board when MAVFTP is not working?
Another possibility is an issue with MP (or whatever GCS you’re using) although this seems unlikely because you’ve confirmed it does work with Copter-4.0.1-dev.
If you have a moment I was wondering if you could confirm that the rm3100 (present on a DroTek F9P Sirius GPS unit) is working for you with Copter-4.0.1? I think you’ve confirmed it was working in Copter-4.0.0-rc4 so it should still be working but if you could double check that would be a great help, txs!
1 Like
It was working in the latest 4.0.1 Dev build which was post rc3. I will be upgrading mine tonight to the stable 4.0.1 and I will confirm it works. The only difference and not sure it matters but my rm3100 is on the can bus
1 Like
Good day, the setup didn’t change… rm3100 is connected on i2c port of can nodri will flash again the firmware and i will check if the rm3100 will be recognized… i will let you know
1 Like
I just tested 4.0.1 on both a Holybro Pixhawk 4 mini and a CUAV V5 Nano and the rm3100 compass got picked right up no problem… This is in the CUAV NEOV2 Pro CAN GPS with RM3100 Compass. I am not sure if I2C is different
I will try to get this loaded on my CUAV V5+ Cube tomorrow to see if the results are the same
1 Like
I am sorry but i don’t have a machine with 4.0 with rm3100 installed 
1 Like
I have had some worrying problems with the AC 4.0.1 which could lead to crashes.
Please check the topic below:
I have seen parameter FRAME _TYPE to many configuration and also seen 13 DJIX.
This means motor order and connection also will differ?
Because DJIX configuration is start from right top motor 1 and counter clockwise its 2, 3 4 respectively.
But where as arducopter is different.
Looking at the AP_Motors library it seems like our “DJI X” frame is setup to order the number in counter-clockwise as shown here. In my (limited) experience with converting a DJI hexacopter to use AP, the motors were in clockwise order so I tend to agree with you. Do you have some reference that shows the DJI motor order is clockwise? This would help with the discussion to possibly have it changed.
Dji motors order are always start with front right motor and counting towards its counterclockwise direction. It’s not clockwise direction.
One thing I have noticed in AC hexacopter when do YAW command from RC remote some motors are almost it reach stop condition (very low rpm and we can see it in our eye’s also).
But in case of DJI motor order I didn’t see such different why?
There’s any special reason for putting motor order in different way in AC.
I have fmuv3
My board is pixhawk 2.4.8
I’ve tried fmuv2 firmware, and mavftp is working (but with mavproxy app, in mission planner 1.3.70 it’s not working too). Maybe i should use another firmware, but as i search, the fmuv3 is correct for my board. The Cubeblack firmware has no use - i tried, i have sensor missing masseges.
@rmackay9 Installed today 4.0.1 in order to test on a Y6F configuration(fresh build), but i was not able to find it in the setup, even though i am able to see the option on the wiki. https://ardupilot.org/copter/docs/connect-escs-and-motors.html Am i missing something?
i will also test the code tomorrow on my X6 test platform and give my update also.
Great, the DJIX frame should work then.
Re the motor order being different from DJI, it’s mostly historic. ArduPilot’s original Quad motor order came from Multiwii. It’s an odd order but MultiWii was a very popular system at the time (more popular than DJI) and I think the MultiWii developer’s thought there was some hardware performance improvement they could get from that ordering.