Working on tuning, and following the steps to set the ‘initial’ throttle to achieve the target cruise speed.
When watching the HUD, however, even with the target cruise speed set to 10 m/s, the bot regularly gets up to 30+ m/s.
We have braking configured, but it never seems to brake until it slams on the brakes right at the waypoint. We’ve tried turning the various speed and braking parameters, but nothing really seems to be affecting things significantly.
When we increase the initial throttle, it starts at that throttle, and then keeps accelerating until it gets to the waypoint, whereupon it slams on the brakes. So, the higher the initial throttle, the higher the top speed right now.
Any thoughts on what we might be missing in terms of having it back off the throttle once the target cruise speed is reached?
@timlwhite,
I assume that you have calibrated your transmitter’s throttle in the Radio Calibration screen and then calibrated the rover’s ESC to the transmitter’s throttle in the Manual Mode?
Since the navigation controller uses the GPS to determine its target speed, how many sats and what is your HDOP when entering the Auto Mode?
Also, what is your waypoint_radius parameter set to?
What are your BRAKING_PERCENT, BRAKING_SPEEDERR, and SPEED_TURN_DIST parameters set to?
Please provide a tlog and a data flash log of your rover when it exhibits this problem.
TCIII AVD,
Jim here (Tim is my teammate). I attempted to upload the logs but they are too large. Perhaps you can see what we are doing wrong from the data below.
In our initial setup we did the RC calibration. We also used the Castlelink program directly connected to the ESC to set the ESC to the following parms:
Reverse type: With Reverse
Motor direction: normal
Brake Amount 100%
Drag Brake: 100% The thought here was that the APM would probably not envoke reverse to slow down, but would reduce forward throttle and perhaps go to idle throttle. I’m wondering now if this is the ESC parm that causes the skid stop at times when approaching a waypoint.
Full Reverse Power: 100%
Max Reverse Power: 100%
Punch Control 0% We noted with a previous setup the car was jumping forward on pretty much all starts so we set this to zero
The rest of the parms are default.
CAR parms you asked for:
We manually calibrated the 2MPS throttle percent to 12% by running the car across a measured 2 meters, adding throttle percent to the HUD, and noting that setting when we got across the 2 meters in 1 second. That caused the car to go pretty slow, in fact not making 10MPS even though that was the cruse_speed setting. We then raised cruse-speed and it didn’t go any faster. So we increased the cruse-throttle. Then we noted it wasn’t slowing down when it went over 10MPS, just kept accelerating till it got near the next wp.
Waypoint radius is .6096M
Braking percent = 00
Braking speed err = 1 m/s
Speed turn dist = 7. We started out at 1 as I recall and made this larger trying to get the car to slow down as it reached a WP rather than getting right up to it and skidding to a near stop. The objective was to make wider faster turns around the wps.
Base throttle % in auto = 5
Curse speed = 10
One additional data point. During this day of testing the HUD always showed 3D fix and the car appeared to be hitting the wps within a few inches, including when we had them just a couple of feet apart (pretty amazing). But when I replay the log the detail parm status shows 0 for the number of sats and gps status. Not sure why that would be.
Jim
@jjwhite,
What do you have your LOG_BITMASK parameter set to?
If you are using a Pixhawk it should be set to 65535.
I never use a BRAKING_PERCENT parameter value of more than 75%.
The higher the BRAKING_PERCENT parameter value the more the reverse throttle that is applied.
I have my CRUISE_THROTTLE parameter set to 35% on my Traxxas Slash 4WD rover.
I have worked with some other members’ ESCs that had such large dead bands that there was no way that they could reliably start out with a CRUISE_SPEED of 2m/sec. They all accelerated well beyond 6m/s at the start. A CRUISE_SPEED of 2m/sec is barely enough forward velocity to get a reliable GPS velocity input.
What is the model of your ESC?
The SPEED_TURN_DIST is in meters so you are starting your braking at ~22 feet from the waypoint.
How closely spaced are your waypoints?
I have had good success using a waypoint radius of 2 meters.
Are you using a Pixhawk or an APM? The Pixhawk is far superior to the APM as you can enable the EKF for considerably better navigation between waypoints.
What GPS are you using? Have you installed a second GPS?
Is your navigation controller and GPS/Compass a 3DR product or a clone?
Log bitmask = 16254
APM 2.5
We started out with a speed turn dist of 3 meters but the car was not slowing down before it braked hard at the wp. We made it larger to try to get it to slow down further from the wp, but it’s not slowing till it breaks hard at the wp. We were able to see no slowing by graphing the log.
We put a wp before the one where it needs to turn, in line with the start point, to try to get it to slow down at that first one, then do the turn slower. The result was it exceeded 10mps to the fist point, skidded to a slow speed, then went slowly to the 2nd wp, turned, etc. I think this is all a result it exceeding the curse-speed.
For these tests we had wps at various places. For example at the end of the loop, after the car returned to start we had three only about a meter apart and it did a nice job of crawling around them.
The problem is when running a few 10s of meters distance to a wp it goes faster and faster then skids to a stop a meter or so from the wp. It then makes a turn and slowly goes to the next a few meters away, then the next another few yards, then accelerates again for the 10s of meters back toward the start, where it again exceeds the 10 m/s cruse speed till it skids to a stop at the next wp.
3DR integrated GPS and compass on a stalk above the roll cage of the car.
ESC is a Castle for the brushless motor in the car.
The question remains, why doesn’t the code limit the speed to the cruse-speed setting of 10mps?
@jjwhite,
Set your LOG_BITMASK to 32767.
Then run your rover over your course again a few times and post the tlogs and data flash (.bin) logs in either Google Drive or here as a zip file for analysis.
Regards,
TCIII AVD