Sure, I’m happy to test a fix for this. I’m not able to consistently reproduce this. So I wont be able to say super affirmatively if its fixed but only that I wont have issues for a long time. I will probably detect the issue pretty fast though if its not fixed. I have not figured out why some times they or some go full throw and some times they don’t on boot.
What do you mean GPIO settings dont take effect in the place most people put it? As in the servo limits are not implemented until farther along in the boot process or something? Im pretty new to ardupilot but id love to know how to investigate this in logs or where ever I should be looking to figure this out.
Alright, finally got parts and put repaired the heli. I have the new firmware you uploaded on it now and will report back if I have a servo freak out.
I have a question though, When I load the new firmware it was 4.3.7 not 4.3.6, I just want to confirm that is expected and am not saying it is a problem. Also is there any way to identify or confirm I have loaded your custom firmware? It look in mission planner as far as I know how to look like I just loaded the next stable version. I did the custom firmware and selected the AJP, watched it erase and write and all that. I just like to be able to verify that I loaded the custom file and not the next stable version if possible, mostly because I just like to verify things as much as I can.
I am getting a error “PreArm: Motors: Check frame class and type” and “Frame: UNSUPPORTED” though.
I have tried a bootloader flash as well.
My params are set as:
FRAME_CLASS 6
FRAME_TYPE 0
If you show/tell me what code you changed I’m happy to go learn how to compile custom firmware with it my self. Ill need to do that eventually for other things anyway.
I found a couple of resources talking about it Here and Here but I have a suspicion you are already familiar with this. If there is another param that these are set in I have not found it yet.
Are your code changes in github someplace? Is this already a bug fix waiting to merge possibly? Just looking for where I can view the code and try to compile my self.
I have loaded the latest official release of 4.3.7 back on this flight controller but have not done the boot loader flash again. It occurs to me the fix might still be there than but I’m not sure at all if the boot loaded is part of a whole firmware flash or not. @andyp1per do you know if the boot loader will stay as long as I don’t specifically use the bootloader flasher in mission planner if I load other firmware?
Iv booted up the heli many times in the last few days on the battery so applying power to the servos and FC at the same time for boot up. I have not had the servos go to extremes yet on any sort of boot where power was disconnected. Seems like that problem is probably resolved or im just getting really lucky.
However, I just tried a soft reboot using control+f then selecting reboot the pixhawk in mission planner and it sent the servos to their extremes. This is a much more livewithable issue as its just means you can’t soft restart. IDK but I would think its related. Just reporting what I’m finding.
As far as your latest fix above, it seems to solve the big problem for me and I am sure others. What are the next steps for how we get this merged in to the an eventual stable release of ardupilot?