Hi @timtuxworth,
To debug this it might be good to stick messages in these functions:
I think we probably need to add an last_rc_input.initialised boolean to the class and then use it to set the last_rc_input.roll_in, etc the first time we get rc input.
I’m about 90% sure that you’ve found a bug. thanks for that!
EDIT: do you want me to raise a PR to add this boolean and init? I suspect you could do it yourself but no pressure either way.
Hi Randy - you were onto something. RC was basically overriding the default as soon as it came up. So it was a bit random depending on whether the RC came up first or the camera came up first. Here’s my PR that fixes it. I didn’t think of a boolean, so did this before I saw your comment. I could change it if you prefer.
Re the Hereflow startup issue and the need for the BRD_BOOT_DELAY=3000, we’ve reproduced the problem and we’ve got a fix here.
This needs to be peer reviewed but hopefully it will be included in the next beta (4.5.2-beta1). Thanks again for the report and special thanks to @xfacta for finding the work around which led to the fix.
Dear @rmackay9
With 4.5.1 loaded and with a SIYI A8 Tested, all controlls seam to work with all the aux functions tested. But i cant find any messages in telemetry even with Mavlink inspector for CAMERA_FOV_STATUS
Only gimball information with angular velocities.
In previews itterations, we used your Script mount-poi.lua to extract the crossing coordinates that camera looks. But given that now is included in the mavlink stream, we can easily forward these messages.
Is the above statement true? Do we still need to upload the applet Lua?? Do we need to wait for GCS’s to be updated to consume these messages?
Thanks,
Dimitris
Hello @rmackay9 i wanted to reach out to see if you had a chance to test the S1 rplidar sensor ? Support is appreciated with this ! Thank you
Hi @Aki_Kalantri,
I have not tested the S1 but hopefully within a week or so after my main sponsor sends me their S1 testing unit. By the way, this Rover user has been using it successfully.
We found a slight issue in the RC_TARGETING change which is fixed by this PR that will be included in 4.5.2-beta1 in about a week. It’s not completely clear to me how it could be related but maybe.
Hi, thanks for this update. I have a strange behavior with it : As soon as I bank it for more than 90 degrees I have an internal error 0x100000 followed by this message : Internal errors 0x100000 l:57 flow_of_ctrl. Can reproduce it every time. AHRS orientation is Pitch90 and accels have been calibrated after AHRS orientation parameter set.
Video : https://youtu.be/xF8-1ZPsL3A
Hi @alex78,
Thanks for the report. I’ve added this to our 4.5.x issues list so it won’t be forgotten.
This is the line in our landing detector code that is causing the internal error. At the risk of appearing to minimise the problem, I don’t think that it is actually that dangerous. This is not an error in AP’s attitude estimator or control libraries. This is a case that we think should not happen (but clearly it does) when the vehicle is trying to determine if it is flying or not.
It is a bug though and appears scary so we will fix it of course.
Thanks for your reply. Maybe it is not a bug because in this particular case I do not use Arducopter under “normal” conditions… Here my FC is mounted in a Rocket nose and do not have any ESC nor motors attached. I just want it to record logs and stabilize the rocket with controlled fins. As there is no Vectored Rocket Ardupilot Branch for the moment (why not in the futur 
) I used Copter and it should explain why this particular situation (model tilted more than 90 degrees with no lift) may never happens in real life with “true” copters.
Thanks for the feedback. It’s definitely a bug so we will fix it and it’s good to have a way to reproduce it.
Re supporting rockets, we’ve talked about it in the past but the “dual use” nature of rockets means it is not area that many devs are comfortable getting involved in.
Hello, do you have some solution?
Maybe I could help you with tests?
I have speedybee f405 v4 and vtx rush tank solo 2.5.
I have the VTX now, just need time to test …
Hi @Prof_Leandro,
Thanks for the report about SBUS output not working correctly. I’ve reproduced an SBus issue with 4.5.0 (and higher) so I hope it won’t be long before we find the cause and fix it.
FYI @andyp1per ('cuz you were also investigating)
ardurovers1.param (15.2 KB)
Hello @rmackay9 , I just tried with ardurover too, and I had the same issues, I attached my parameter file for your review, My TX of the sensor is connected to the RX of the pixhawk cube orange, and RX of the sensor is connected to the TX of the pixhawk cube orange.
Do you see any issues with the files or the connection?
Hi all, 4.5 and 4.5.1 new build is acting odd but really could be something i’m doing wrong. 1. A lot of twitching of the frame. 2 Loitor has an altitude climb like a flyaway switching to stabilize recovers… 3. EKF errors show movement in MP even when grounded. Last flight copter drifted and had an impact. I decided that i won’t do more work on this and rebuild from new.
Thinking it could be a Radio issue. The climb was repeatable.x4
Hi @Quadzilla,
Thanks for the report. I suspect it is environmental or frame related. We really haven’t made that many changes to the EKF or controllers in 4.5.x vs 4.4. Maybe try back-to-back tests with 4.4.4 and 4.5.1?
Re the SBUS out fix has gone into master and should be included in the next release which will be 4.5.2-beta1.
If you’d like to test the fix immediately (which would be very much appreciated) then you could load “master” (aka “latest”) onto the board using Mission Planner’s Firmware Install screen, just press Ctrl-Q and you should see the version under each icon change to 4.6.0-dev. Please note that this is a development version that hasn’t gone through beta testing so while it is probably safe, all we really need to know is that it’s resolved the Tarot gimbal control issues you were seeing.
