Closed korken89 closed 6 years ago
I've seen this bug before, and I thought that it had been fixed a while back. (I'm pretty sure that it's actually a problem with the breezystm32 drive layer) I'll probably have time to look at this this afternoon or tomorrow. Thanks for letting me know!
Thanks for having a look!
Which branch of the code are you running?
I just tried the current release v1.1.0
, and I saw the behavior you're describing, however it seems to be fixed in master
.
Hi, I was using the latest release (which at the current time seems to be v1.1.0
as you say.
Is is safe to use the master
branch? I am generally a bit careful when not running stable releases. :)
What are you using it for?
I'm flying master
for my own Ph.D. research efforts, and consider that use case very stable. I've also got a pull request open to release current master
(#294)- The differences are pretty small, but the one that you want is the BMP280 support. However, I pretty much only fly multirotors.
FYI, we just released master
, so you should be able to use the new .hex
file. v1.2.0
Hi, thanks for the release and prompt reply!
I have my own FCU I have been supporting for about 5 years now, which was first my hobby and then it became the FCU I,and my group, used during my PhD. While this was fine, now when I'm finishing I want to leave the group with an FCU that I don't need to support. :)
So I have been testing Pixhawk, but was not very impressed. Too bloated, non deterministic communication, and the documentation was meh. Now I'm testing rosflight, and so far it seems quite straight forward - which I like in its simplicity. A bit lacking support for new motor protocols, ESC telemetry and serial receivers, but these are not "must have" features. However, from a research perspective, ESC telemetry and synchronous motor protocols are something I would recommend, together with tracking notch filters for the gyros to not be as sensitive to vibrations (and to practically remove low pass filters). :) But if you are interested in something like that we can discuss it somewhere else, I have reference implementations for it all that I could port the day you use an F4 or better MCU.
Thanks again, and keep up the good work!
No problem!
Our F4 port is basically done (I'm running it right now on a final overnight test before merging into master) I've been flying the F4 for a couple of weeks.
I think we would be super interested in those additions. It makes a lot of sense to do notch filtering, and ESC telemetry would be really awesome. Our loop time on the F4 is on average about 40 us, so there is actually a ton of processor overhead. I'll start some issues for those topics and we can chat about them some more. Thanks also for the feedback about motor mixing!
That's really good news! I saw a bit about F4 here and there, but I did not have time to dig into it yet. Let's continue where it fits, I also saw you had a discussion forum. I have a small writeup on recommended design practices for these type of systems which I can paste in, just for reference and discussion.
And no problem on motor mixing, you are having the same problem I had some time ago. Just that I chose to solve it with a larger hammer and tested implementing an MPC, which an F7 can do, but I would not recommend. The simplicity of the cascaded PID loop and some smart saturation really gets you close to all the way! :)
Hi again, I should probably report that in v1.2 the barometer is working again! Thanks!
Awesome
Hi, the reading of the barometer gives nothing, but it is coming at what seems to be a normal rate. The message in ROS looks like this, but is stuck on the same value always:
Tell me if there is something I can do to help debug this issue!
rosservice call /param_save_to_file
)Parameter file: