hello everyone, completely new to this area … please apologize.
I use a Rover with Le Cube Purple and Ardurover as well as Herelink for the ground station and the video. QGC seems to me more suitable to drive the Rover. I have installed a wheel encoder and I can visualize the ground speed and display it in the QGC screen. No GPS on my rover.
My question: is there a way to display the distance traveled in QGC or Solex without set ekf origin?
maybe this question has already been asked but I couldn’t find anything on it.
thanks for your answers and your help, kind regards.
It is possible to see the distances from individual wheels using the Mavlink Inspector (both MP and QGC have this feature) but it isn’t possible to see the overall distance that the vehicle has travelled without setting the EKF origin.
There’s actually a picture of the mavlink inspector from MP on the wheel encoder wiki page and the “distance” row shows two distances (in meters), one for the left wheel and the other for the right. So those readings show the left wheel has turned backwards 1032m and the right wheel has travelled forward 1053m. That’s a bit of an odd reading but who knows what this vehicle was doing when I took the screen shot.
If that helps, I adjust and check all wheel encoder parameters arming, driving forward a fixed distance as straight as possible at home (around 11m, wall to wall), disarming, and observing WENC distances on MP.
This is a real example of driving similarly one lap on a real circuit, for which I have its waypoints GPS coordinates for missions. Adding distances with the Haversine formula gives the same result (even the inner wheel (CCW, left wheel, red trace) shows smaller distance).
I haven’t used the OSD in a long time so I actually don’t know how much flexibility is has to display data from mavlink. I suspect it cannot display these fields.
However, I never could emulate that in a mission. Certainly it works in Copter changing the ROI and inserting a delay (for giving it time to rotate), but it is not clear on a balance bot, since it cannot move sideways, but MP admits DO_SET_ROI waypoints for a balance bot.
So the question is: can a balance bot pivot in a mission changing the ROI?
Re the DO_SET_ROI command, rovers will not turn the vehicle in response to this command being run, instead they will point the gimbal.
In general NAV_ commands change the attitude, speed or position of the vehicle. DO_ (including CONDITION_) commands do not affect the movement of the vehicle… they only affect secondary subsystems like gimbals, servos, etc.
So I found that balance bots can be rotated (CW and CCW):
easily with a MP script similar to:
while True:
Script.SendRC(1,1810,True)
Script.Sleep(2950)
Script.SendRC(1,1210,True)
Script.Sleep(2950)
but I don’t fully understand how this works:
Since at the time, I had both transmitters on sending RC neutral pulses (around 1500µs) on ch1, it seems that MP MAVLink messages have precedence. Is this documented or explained somewhere or on the source code?
The 2950ms sleep time comes from an observation that each Script.SendRC(...) seems to have a 3s “persistance”. Is this documented or explained somewhere or on the source code?
I’ve never actually written an MP script but I think this is using RC_OVERRIDES meaning that the script is overriding the pilot input. I think you’ll find that while this is happening you cannot control the vehicle using the transmitter.
The 3 second persistence is caused by the fall back from RC_OVERRIDES to regular RC input after the RC_OVERRIDES stop being sent.
When I download the log, I can see that the WENC Value is correct. But the telemetry value for Distance to Home, shows sometimes no value, or wrong value. I tried this with firmware 4.22, 4.23 and the latetest 4.30 RC12. Is maybe the script not correct here?
I’ve another problem with my Rover4x4.
There are 4 motors and 4A and 4B encoders, but I’ve connected forward wheels and when I drive offroad I’ve got an error if I want to return my rover.
In that figure with the WENC distances going opposite, if you have moved the vehicle fordwards, the software would think that one wheel goes forward and the other backwards (rotation implying your no value). Exchange right wheel WENC pins.
In fact, on a new vehicle I check WENC parameters moving the vehicle a fixed distance forward (around 10m). On the log I should see exactly the same positive distance (10m) for bothWENC.Distx’s.
Let me say that the routines for the wheel encoder signals interrupts (on WheelEncoder_Quadrature.cpp) can be further optimized in timing, simplicity and clarity (a floating point division in an interrupt should be avoided), but they work very well and with great precision.
