ardupilot
ardupilot copied to clipboard
ArduPilot
HWDEF: update MicoAir405v2 and MicoAir405Mini default parameters
A minor change for MicoAir405v2 and MicoAir405Mini:
1, add LOG_FILE_BUFSIZE 8 to MicoAir405Mini and MicoAir405v2 default.parm, the default value of LOG_FILE_BUFSIZE is 16. Setting it 8 to spare RAM for compass calibration thread.
2, add OSD_TYPE2 = 5 to MicoAir405v2 default.parm. There is a connector for OSD2 and setting the parameter for it.
3, enable opticalflow for MicoAir405v2 by adding undef AP_OPTICALFLOW_ENABLED. In the last commit, include ../include/minimize_fpv_osd.inc is added, which disable opticalflow and opticalflow is important to us, so I update the hwdef.dat of MicoAir405v2 to enable it.
Please add a description to your PR. This really helps the devs doing the releases to understand what you are doing and why you are doing it.
From you comments on discord, I can see that you have tested this. It would be really useful if you could post some of the results of your testing. If you upload your logs to the hardware report tool.
Here: https://firmware.ardupilot.org/Tools/WebTools/HardwareReport/
And screen grab the plots that I have given an example for below:
That will help us to a) see buffer space, and b) see what log messages you are using during your testing. We can offer advice based of what features you should consider trying during logging.
As a minimum I would suggest you try "Fast Attitude" logging in Copter. "Full Rate" Logging in Plane and batch imu logging. These are common log features that users will want/need during setup so it is worth testing that these don't overflow the buffer.
Please add a description to your PR. This really helps the devs doing the releases to understand what you are doing and why you are doing it.
Thank you for your input and I have added the description.
From you comments on discord, I can see that you have tested this. It would be really useful if you could post some of the results of your testing. If you upload your logs to the hardware report tool. Here: https://firmware.ardupilot.org/Tools/WebTools/HardwareReport/
And screen grab the plots that I have given an example for below:
That will help us to a) see buffer space, and b) see what log messages you are using during your testing. We can offer advice based of what features you should consider trying during logging.
As a minimum I would suggest you try "Fast Attitude" logging in Copter. "Full Rate" Logging in Plane and batch imu logging. These are common log features that users will want/need during setup so it is worth testing that these don't overflow the buffer.
I haven't uploaded the logs to the hardware report tool but checked the freemem and messages in MP. And ticked all the items including "Fast Attitude", took off and checked the logs after all the flight.
From you comments on discord, I can see that you have tested this. It would be really useful if you could post some of the results of your testing. If you upload your logs to the hardware report tool. Here: https://firmware.ardupilot.org/Tools/WebTools/HardwareReport/
And screen grab the plots that I have given an example for below:
That will help us to a) see buffer space, and b) see what log messages you are using during your testing. We can offer advice based of what features you should consider trying during logging.
As a minimum I would suggest you try "Fast Attitude" logging in Copter. "Full Rate" Logging in Plane and batch imu logging. These are common log features that users will want/need during setup so it is worth testing that these don't overflow the buffer.
Hardware report tool results:
MemInfoV1
START=0x20000000 LEN=128k FREE= 72 LRG= 24 TYPE=1
START=0x10000000 LEN= 64k FREE= 13720 LRG= 13720 TYPE=2
ThreadsV2
ISR PRI=255 sp=0x20000000 STACK=1280/1536
ArduCopter PRI=182 sp=0x20000600 STACK=5312/7168
idle PRI= 1 sp=0x20014CD0 STACK=288/496
UART_RX PRI= 60 sp=0x2001DC20 STACK=864/1200
OTG1 PRI= 60 sp=0x2001D2D8 STACK=496/752
monitor PRI=183 sp=0x20011980 STACK=1112/1456
timer PRI=181 sp=0x20012F40 STACK=1576/1968
rcout PRI=181 sp=0x20012560 STACK=552/944
rcin PRI=177 sp=0x20011F70 STACK=768/1456
io PRI= 58 sp=0x20010F90 STACK=1544/2480
storage PRI= 59 sp=0x20012950 STACK=920/1456
UART1 PRI= 60 sp=0x2001CA10 STACK=344/752
UART2 PRI= 60 sp=0x2001BEA0 STACK=464/752
UART3 PRI= 60 sp=0x2001B718 STACK=376/752
UART4 PRI= 60 sp=0x2001AFD0 STACK=360/752
UART5 PRI= 60 sp=0x2001A888 STACK=464/752
UART6 PRI= 60 sp=0x20019020 STACK=464/752
SPI2 PRI=181 sp=0x200184B8 STACK=808/1456
OSD PRI= 59 sp=0x200170A0 STACK=976/1712
log_io PRI= 59 sp=0x20016518 STACK=480/2016
I2C0 PRI=176 sp=0x10002C10 STACK=968/1456
@Minderring those dropped messages are deadly. You should be aiming for 0 lost packets.
Can you push the buffer back up to 16kB and re-run the test to see if it really is buffer size making the difference there, please?
@peterbarker re-run the test with the LOG params as follow:
compare the parameter
LOG_FILE_SIZE from 8, 16 to 20, the graph of dropped message did not improve.
LOG_FILE_SIZE = 8 :
LOG_FILE_SIZE = 16 (default value) :
And LOG_FILE_SIZE = 20 :
@peterbarker In MicoAir743, which LOG_FILE_SIZE = 200, the graph of dropped messages looks good. Although the LOG_BITMASK = 176126 (default) and in the MicoAir405V2 test (last comment), the LOG_BITMASK = 4108287 (ticked all the items of BITMASK)
The graphs of Free Buffer Space are similar even using different parameters.
@Minderring OK, so looks like you've got logging under control. Did you want this merged now?
@Minderring OK, so looks like you've got logging under control. Did you want this merged now?
@peterbarker needs a rebase?
@Minderring OK, so looks like you've got logging under control. Did you want this merged now?
@peterbarker needs a rebase?
Not really, but I did so anyway.
Adding in OpticalFlow is obviously use-case specific and important for you - just bear in mind these boards do only have a limited amount of flash space :-)
If you are using a specific sensor on these boards and it will always be present, I suggest that you set AP_OPTICALFLOW_BACKEND_DEFAULT_ENABLED to zero and then set AP_OPTICALFLOW_sensorname_ENABLED to 1 - this will have your board work as desired while minimising the flash cost, meaning it's more likely to continue building. "Not building" isn't an imminent problem, but....
Did you want this merged?
@Minderring OK, so looks like you've got logging under control. Did you want this merged now?
@peterbarker needs a rebase?
Not really, but I did so anyway.
Adding in OpticalFlow is obviously use-case specific and important for you - just bear in mind these boards do only have a limited amount of flash space :-)
If you are using a specific sensor on these boards and it will always be present, I suggest that you set
AP_OPTICALFLOW_BACKEND_DEFAULT_ENABLEDto zero and then setAP_OPTICALFLOW_sensorname_ENABLEDto 1 - this will have your board work as desired while minimising the flash cost, meaning it's more likely to continue building. "Not building" isn't an imminent problem, but....Did you want this merged?
Thank you! Our OpticalFlow sensor using MAVLink protocol and I'll try and test the suggestion you mentioned later. It's better to merge this firstly and I'll try to solve it before the "Not building" problem.