Ackermann attitude and position control #7139
Conversation
…er controls and firmware modifications
Conflicts: ROMFS/sitl/mixers/rover_sitl.main.mix posix-configs/SITL/init/ekf2/rover src/firmware/posix/sitl_target.cmake
Conflicts: src/firmware/posix/sitl_target.cmake
Conflicts: src/firmware/posix/sitl_target.cmake
… control (change this at some point) and started working on gnd_pos_control
|
Ah, that's the VTOL crap I tried to extract. Nice catch. |
|
I've been trying to fix it but I still have some bugs here and there. Open loop speed is almost working except for this weird behaviour that I don't know where it's coming from:
I'll sleep over it and see if tomorrow morning I can find a quick fix to go testing but if not I'll use the original code to get the data I need for the steering controller and estimators unless you can help me out while here it's night 😄 |
|
Can you expand on the problems? I don't want to distract you from real work, but I'd personally like to help get this stripped down and working well, then expand the manual assist modes. Stabilized, acro, and position control. |
more cleanup
|
This seems to work fine by just using normal waypoints, I'll try it on the real system and get back to you with logs in a few hours. Thanks a lot for the help! |
|
@marcozorzi please after you make sure it works on the real thing, squash the commits using |
|
So, tests today were good, but tuning the speed controller proved to be quite a challenge so it took me some time. Here's the log for the speed controller: log46 Here's a mission test with open loop throttle and mission through waypoints: log14 I realized the circling issue was due to the fact that while the setpoint wraps around PI, the controller does not and I fixed it brutally with the last 2 commits. I just did one test before my computer died but by the looks of it, it seems working: I am not sure why the attitude setpoint was not logged but it might be due to the replay parameter for the EKF2 that I activated or something else, as I was poking around with those parameters. Tomorrow I'll do the final test for these and then rebasing. |
|
Seems promising! Keep going mate ;) |
|
We have good news! Everything is working great! It required some tuning but overall it's looking great! Here's the log on mixed grass and tartan track with target speed at 5 m/s and some sharp turns: I believe this is now ok, a small addition that could be done in the future would be some sort of traction/pitch control to avoid wheelies and then we could start considering some smart strategy for turns as now it just accelerates to keep the target speed.
Anything else? |
|
Some basic traction control would certainly help my driving! After the basic version is merged let's create an issue with ideas for next steps. I'd personally like to expand the manual assist modes. Let's get this into a state for merging. Do you want to squash it down into a single commit rebased on master? If you want to split it slightly you could do the controllers and the cmake configs separately. You could start with a new branch (from master) and |
|
Sounds good. Let me talk to Kabir as he's around here. Tomorrow we should be able to get this done. |
|
@marcozorzi if you want to keep the commit history I advise you to first squash and then do the rebase |
|
Also please add some documentation about this on https://dev.px4.io/. Create a subsection in https://dev.px4.io/en/airframes_experimental/ with the name "UGV/ROVER" or something like that (you can rename this same section to "UGV/Rover" only instead of "Boats, Submarines, Blimps, Rovers" so to be more specific), add a part list to build a RC car like yours (Traxxas Stampede VXL), an assembly guide, a general schematic of the different parts and how they are connected, the servo connections schematic, a list of mixers values and the PID tunning you used, and finally add some photos. Add everything you think it can be useful and informative. |
|
I'm personally against incremental commit history in master unless each individual commit is some level of "working" and actually provides value 6 months from now. One option is to resolve the conflicts in this pr-rover branch and then "squash and merge" in github. PX4 master will have a single commit that references this PR, and the full development history is still captured. Best of both worlds. |
I buy it ;) |
|
So, I created a new branch from master and I did as @dagar suggested so https://github.com/marcozorzi/Firmware/tree/pr-rover-rebase Should we close this and open another PR? could you guys have a look to that and tell me if it's correct? thanks a lot |
|
You can either open a new PR, or hard reset the branch in this one. Let's try to get minimum viable ground vehicle support in master as a baseline, and then continue making incremental improvements. I've already come across a few different people interested. http://discuss.px4.io/t/where-is-the-code-for-controling-car-and-boat-in-px4/3171/2 |
|
Awesome, thanks! I decided to go for a new PR, hoping it goes fine. |
|
Continued here: #7175 |
This PR builds on top of #6615 , and implements 2 new modules
These two branched off from fixed wing apps and went through big refactoring and, to the best of my abilities, simplification and improvement.
Also, it allows to drive a Traxxas Stampede VXL manually and with mission mode and aims to provide a low level interface for similar vehicles.
I did a lot of tests on the system but, as a precaution, I'll do the final one this weekend and post here the logs for final validation.
This work was developed during my master thesis with @LorenzMeier and it's close to its end so I thought it would be cool to propose a merge with master so to allow others to develop on top of it but also to get feedback from this great community.
I used the new Pixhawk mini and built the system as shown in pictures below
This is definitely not at the level of other apps and I kept it as simple as possible but perhaps it's still useful or interesting.
Any suggestion/comment/feedback is welcome.
PS: please apologize me for the immense amount of commits, which probably do not follow any good practice, it was a learning curve and I was often using two computers in two different locations, so i moved code through github.