I’ve been working on this rover for a few weeks, it seems as though it can’t figure out what direction to go. My original issue was that it would drive the opposite direction from what I wanted and now it seems to be having a bit of a hard time as it tries desperately to hit the waypoints. It’s possible I’ve fixed the opposite direction problem and now just need to adjust the way point / turning / PID tuning behavior? I set the WP_RADIUS fairly small because I wanted it to fully come to the center of the waypoint before turning. TURN_RADIUS set to zero. It never turns like it should with each motor running opposite one another and instead tries to do more of a sweeping turn. Is this a GPS / center of rotation problem?
Should I just let this thing loose into an open field and start tuning and just assume it will work itself out? Is the GPS accuracy just that bad that it can’t actually hit the waypoint? (I’m working on getting RTK to work.)
Setup:
Pixhawk 6X
Holybro H-RTK Unicore UM982
SIYI MK32 Running QGroundControl
(I also have a telemetry link to computer running Mission Planner)
Cytron SmartDriveDuo-30 MDDS30
If not, you will waste countless hours trying to make it work. Take your time, don’t skip steps and you’ll get there. Remember, If it doesn’t drive properly in ACRO mode, you are wasting your time playing with AUTO. Good luck!
I have now, especially the first run and tune section. I had an absolute failure trying to do the tuning. I am reading that perhaps ACRO mode isn’t the best and instead I should be using STEERING mode for my skidsteer rover?
I believe I need to redo my accelerometer calibration.
One other thing for the PID setup. I could not get any values out of PID expected / actual unless I was turning. While the GCS data was set to throttle, PID actual only reported anything if it was turning.
I set the turn rate and cruise speed based on what I could measure, the built in cruise speed function did not work.
Autotune failed.
Already there!
I think I got RTK working for the first time today. I used RTK2GO and Mission Planner fed the corrections. It said RTK Float on the device, but the horizontal error was still 0.6 meters. The ground station I was connected to was too far away to provide any useable correction data.
sounds like progress to me.
We have 2x F9P ardusimple boards on the mower and 1 more as the ground station - using Rtk2go as the ground station is 2km away. For me RTK_FIXED is usual and very accurate/repeatable. RTK_FLOAT is hugely not so. I havent looked into it too far but base station beyond 20kms becomes unreliable.
If your GPS’s are calculating YAW from knowing their exact location, then gps inaccuracy will be delivering poor yaw estimations. Get the GPS’s status to 6 - RTKFixed to give your poor computer a chance to deliver.
The PID_Desired vs PID_achieved is exactly what tuning is. Both lines doing the same thing.
I’ve managed to get the quick_tune script working on both our mowers. It worked well once, then not so much. Crawler mowers speeds are too slow for the script. I did the first mower with the script, then the second by hand with the pids. Both work.
ACRO is the way. If ACRO doesnt work - keep tuning until it does. Accurate GPS for yaw im thinking. You are close to automatic mowing - just a couple more steps !!
I never considered the yaw was bad, because it always displays the correct heading and doesn’t seem to jump. I would think the moving baseline 2x GPS would provide a good solid reading even without RTK?
Unfortunately the nearest NTRIP RTK2GO station is ~60KM away. I guess I’ll be building my own base station!
Ran through some more testing and tuning (or at least tried to!).
I had arming_checks disabled because of when I was bench testing, it was giving me all kinds of EKF errors for the GPS. I realized last night that OH, these checks might be important to keep. I started having erratic motor behavior however and need help understanding the settings.
With the Cytron MDDS30 motor driver, once it receives the PWM trim signal, it knows that is middle (off) state. However something is happening with ARMing that is causing a 0 PWM or minimum throttle to be sent. This causes the Rover to have 100% reverse throttle, which luckily just causes the rover to spin.
MOT_SAFE_DISARM = 0 (trim PWM is sent).
ARMING_REQUIRE = 1 (min throttle)
With the arming require, none of these settings make sense. If I set arming_require to 0, it never lets me disarm. It skips all checks and just immediately arms. As of right now this is the only way I can arm if I have arming checks turned on.
1 = THR_MIN PWM when disarmed (this will cause my rover to spin won’t it)
2 = 0 PWM when disarmed (definitely will spin).
Where is the setting that forces the PWM to be the TRIM value?
I’m not sure if I changed a setting which is causing this or if I damaged something in the driver. As of right now my process goes like this:
-Turn rover on.
-PWM = 1500, we’re good.
-Arm rover.
-Rover immediately starts spinning due to either 0 PWM or PWM throttle minimum.
-Arming fails due to abnormal mag reading (probably from the motors running?)
-Rover stops, probably because my 1500 PWM signal returns.
I took out the autopilot and did a bench calibration of the accelerometers. I’m assuming the MAG is the compass? Should I even bother with the compass since I know I have large magnetic fields and have the moving baseline GPS to provide my YAW?
I use the same Cytron driver in one of mine. Never had a problem. You have a config issue - check the RC throttle and steering channel’s min, max, and trim values.
Yuri, I think I know what the problem is. This probably started after I adjusted the MOT_THR_MIN setting from 0 to 5% after reading a comment in another thread. I’m guessing that 0 = disabled and 5% forces the PWM to be 5% of the range, or ~1100 PWM, which causes it to spin. Maybe a bug? Shouldn’t it be 5% +/- from the trim position?
Have you had any thoughts about creating a script that drives the MDDS30 over serial or UART? Are you using PWM mode or RC mode?
I built an RTK Base. It was surprisingly easier than I thought it would be. I will mount the antenna on the roof of my building and then it will automatically survey in for about ~24 hours or until a 0.1m fix is achieved… then it will transmit the RTK data over the radio. Just needs USB power, which I have from a solar panel and battery.
Downside is that the radio is what I was using as a connection to Mission Control. I’m not ready to go strictly QGroundcontrol on my radio transmitter yet.
That seems like common sense. Not intended as an insult, but if you intend to send RC pulsewidth, anything other than default output will likely be the wrong path.
“Normal” is the most common and involves sending PWM values normally between 1000 and 2000 (1ms ~ 2ms)
“Brushed BiPolar” is for brushed motor drivers that, a bit like “Normal” PWM. These devices interpret a low PWM value for reverse, a high PWM value for forward.
My hope / expectation is that Ardupilot knows 1000 is reverse, 2000 is forward and 1500 is neutral even without selecting Brused BiPolar. I’ll have to look at the code to understand the expectation of what Brushed BiPolar actually is.
Now that MOT_PWM_TYPE is set correctly, everything else is starting to work. It now drives toward the waypoints and I can finally tune as PID numbers actually show up on the graphs. I’m having a wobbling problem as is recently discussed here: Rover - acro mode shaking
