Hi
I am using a Sabertooth 2 by 12 RC motor controller with a Pixhawk 2 loaded with firmware 3.2.1. The chassis is actobotics and weighs about 10 pounds. I am using 303 rpm motors and the bot is set up for differential steering. I have just bought 2 118 rpm motors that will be better. Ie slower with more torque.
In manual mode all is as it should be and the bot responds well. However in steering and auto I am getting violent swings from side to side whilst traveling to a waypoint. This being said forward back velocities are well constrained and not a problem. Also the bot is generally trying to go in the direction of the WP so I think all the connections and reversals are bacially correct.
I have been through the new wiki material on speed, steering and navigation tuning many times and I have still not found the solution
If some can tell me the main parameters that control steering in these modes I would be grateful.
Also the parameter to turn pivot steering off and back on
I can include a log file in the next post If thought useful
Sorry, I’ve been away at the un-conference for a while. I’ve posted some advice on the other thread. If you have a dataflash log I can have a peek.
Hi Randy
Thanks for your various responses
I will send a data flash in an hour or two. At the moment the Rover is performing so poorly it will be embarrasing.
First let me explain my main issues.
I am using a pair of Ublox C94-M8P rtk evaluation boards. It gets a rtk fix and sometimes (when I set the correct parameters) the rover works as expected. However sometimes Mission Planner gives me a “Bad GPS Health” message. I have to use the NMEA output from the C94 to get MP to see the GPS. If I use UBX output from the C94 and set MP gpstype = 2 then I do not see the gps at all.
I am working with another forum member to resolve this. He say I must get the output to be UBX. Although i get the message I am not sure this is a major problem as the rover does work quit well.
I am as you can imagine I am altering quite a few parameters to tune the rover at the moment. I try to do this in an organized manor however sometime it can be a little intimidating.
More of a problem is when I start in working on the Rover on some mornings it seems like the Rover is a completely different Rover from the night before.
Question. Do some parameters only kick in after a hard reboot or a software MP reconnect? if all parameters are accepted when they are written then I am unsure why the behavior is so different on a morning restart.
At the moment the Rover is dancing about all over the place. I do not know if it is a GPS or other parameter issue.I am trying to get the Rover to return to its performance of a few night ago from which I sent the screen shot. Where ever I get to tonight I will send a data flash log so you can take a look
I did enclose one from a post I started a few days ago. Maybe you can take a look at that in the meantime.
regards and thanks for your help
Max
I think we need to separate out the various issues and tackle them one at a time. Michael DuBreuil is our GPS maintainer so his advice will be the best we have regarding the GPS.
To get the tuning right (which I can help with), I think it would be best to switch to a regular GPS and set the GPS_TYPE to “2” then let’s set the ATC_STR_RAT parameters to all zero except the ATC_STR_RAT_FF - we should increase that until the STER.DesTurnRate is close to STER.TurnRate.
I looked at the 2 STER functions and my actual turn is greater than the Desired.I will reduce ATC_STR_RAT_FF in the morning and re run the tests. This is possibly the reason for the over steer at the way points.
How do I contact Michael DuBreuil as I do have a GPS issue. I can not get an UBX output from the C94 and then use option 2 for the gps as everyone suggests.
Tonight I did make a lot of progress with U-Center and removed from the data stream everything accept what seems to me to be the most essential sentence. See Below
I need to know how else to configure the GPS data so that it is acceptable to the Pixhawk and Mission Planner. I am pretty sure that all the crazy behavior with the rover was GPS related. I think it was being provided with too much information and not enough useful data. I can switch to a normal gps for testing/ tuning however as I am trying to get very accurate lanes using a normal gps will never be accurate enough.
Yes, reducing the ATC_STR_RAT_FF should help. Maybe try 0.33. I think ATC_STR_RAT_P could be lower as well. It’s already quite low (0.1) and getting the FF right will reduce the error in any case but maybe make it 0.05.
It looks like the top speed of the vehicle is a leisurely 1m/s. maybe reduce the CRUISE_SPEED to 0.8 and CRUISE_THROTTLE to 80. This doesn’t matter too much though.
I reduced FF and P as suggested. I also reduced Speed and Throttle however that just stopped the Rover so returned them to 1.25 ms and 100% throttle.
Here is the problem in 3 pictures. With the params as above when I do a mission with 180 degree turns and no pivot turns the path travelled is off the track as follows
when I add in 90 degree pivot turn angle the rover does tight turns but then turns again about 45 degrees off track and then drives off and then corrects itself
The data flash of these mission somehow got corrupted so I will run the missions again and send the log in the next post
I will also check the STER graphs
regards
The pivot turn overshoot is a “known issue” and it’s on the to-do list to fix for Rover-3.3 (here and here). The only thing that may help is adjusting the TURN_MAX_G parameter but no promises really.
the vehicle is not getting back on the track fast enough. This is just navigation tuning and reducing NAVL1_PERIOD from “10” to perhaps 8 or even 6 should help.
The ATC_STR_RAT_FF still appears a bit high. Maybe try reducing it from “0.33” to “0.2”.
As a side note, if you have time, could do a test with WP_SPEED set to 0.8 or even 0.5 so that it runs the course more slowly? Both motors are saturating constantly meaning there is a very strong link between speed and turn rate and I suspect this may be why the turn rate response is so noisy. The moment it wants to turn, it must also slow down. Another solution would be to replace the motors with a lower gear ratio so it travels faster.
Dear Randy
I will make the changes and will get back to you tomorrow
Regarding the Max_Turn_G parameter which way should I go up or down
For the motors I am currently using 118 rpm motors. I also have 313 rpm and have just bought some 60rpm motors. Which do you suggest trying next. I can also buy other’s if you think it will help. I was a little unclear in your post are you suggesting using lower rpm motors
I am using an overkill 2 by 32 amp sabertooth motor driver. It can also be programmed. So can you tell me a little more regarding the motor problem so I can investigate this further, Altarnatively I can use a 2 by 12 sabertooth motor driver if you think the other one is causing a problem.
I think motors with a higher RPM would be better. I think it will perform better if the missions are run with the motors running at no more than 70% most of the time. That will give it some room to turn a bit without slowing down.
I think reducing the MAX_TURN_G may help but I’m not sure. The underlying problem is the slightly ham fisted way we do pivot turns. So it’s this software issue that we really need to fix… modifying MAX_TURN_G is just a temporary work around that may or may not work.
I changed the motors to 303 rpm and now, that the Rover is sort of behaving better, they worked very well. The only thing is that they do not have a lot of torque so not so good on grass.
I was already at the lowest Max_Turn_G so can not reduce that. I input all your other suggestions and ran two missions. The usual one East West and a new one running North South. By the way the east west mission, the turn points are 31 feet apart, so it is a short course.
As expected the NS mission is better than the WE mission. Although I have not measured it exactly the northern part of the W-E mission seems to be about 4 to 6 ft off track even though I have a RTK fix
I have tried the missions with and without Pivot turning
There is no doubt that I have a GPS issue as I get the GPS error (Bad GPS Health) and MP is also telling me we have 12 sats when U Center shows 16 and an RTK fix. You mentioned before the name of the resident GPS guru.However no way to contact him. Can you please let me have his contact details so I can resolve the GPS issue.
Randy
Looking at the Dataflash STER.DesTurnRate Vs TurnRate the 2 curves now match quite well.
I think the “hunting” between the turns is due to the extreme NavL1 Period value. I will back this off and this should reduce the hunting.
I also plotted THR- DesSpeed and Speed. Generally they are in conformance
I plotted ATT yaw vs DesYaw and the DesYaw is not shown
then ATT DesYaw vs AHR2.Yaw and again ATT.Des yaw is not shown.
So how to I graph the Desired track vs the actual track?
Are there other useful graph combinations
Yes, the steering looks better. The throttle/speed control is still a bit messy. To try and reduce environmental effects it might be good to test the rover on pavement instead of grass. Even if the final application will be on grass, tuning it in a less noisy environment will work out better I think.
The NTUN message has some data in it related to the heading but I don’t personally look at it much so I haven’t yet verified that what it produces is sensible.
By the way, this morning I created a developer wiki guide for the Rover’s navigation code. I don’t think you’re looking to dive into how Rover’s navigation works but perhaps it will be useful as a reference for some.
If you are still having troubles with M8P, you might be interested in testing again with u-blox F9P, which solves most of the limitations of M8P. There’s an evaluation board with Pixhawk connector available “simpleRTK2B”.
