So as mentioned by @Matt_C, in Rover-4.0 we are no longer reporting the wheel encoder data using the mavlink RPM message, instead we use the WHEEL_DISTANCE message.
We could add the rpm calculations back but that would only be for the convenience of the users. The RPM is not needed for anything internally.
By the way, we should not mixup the setup for wheel encoders (which is on the wiki here) with the setup method for the RPM sensor because they are separate features. It’s a bit odd that we even have the RPM sensor feature in Rover because we don’t use the output of these sensors at all at the moment. I probably won’t remove the RPM feature because it’s in all vehicle (including submarines even!) but it’s not actually useful at the moment.
For other reading this, the wheel encoders are good for two things in Rover:
Non-GPS navigation (wheel encoder data is integrated by EKF3 to calculate position and velocity)
Improving balance on a balance bot but only if the wheel rate controllers are enabled (see WRC_ parameters). I don’t think we have anything on the wiki explaining this part of the setup sadly.
I think it’s this last point that we are focusing on to improve @Webillo’s balance bot performance.
What happened historically is that I was assembling the vehicle, and not seeing rpm values (and no smoke) I thought I had something wrong, till trying v3.5.2 on a spare pixhawk: rpm’s appeared. A lot of wasted time.
Later, with motor data, I could not find logic values for motors CPR, measuring rpm with tachometer. I adjusted CPR empirically (v3.5.2 rpm’s displayed = tachometer rpm’s). From what is said here, I doubt if this is correct, so I’ll check with real distance later in the track. Anyhow, for different motor setups adjustments (such as using gimbal brushless motors) there is this spare pixhawk and servo Y’s method.
So now, if rpm’s calculation were internal, I have the doubt if having real rpm’s displayed is not correct (the CPR’s I use are not logical).
I suppose that there is used a servo for steering. I could not find documentation about motor controller DIR1/2, although being there two pixhawk free outputs these should be used (needing RELAY_PIN=50 RELAY2_PIN=51).
There appears: Another way to check operation on Rover 4.0 and later versions is to monitor the Wheel_Distance MAVLink messages as shown below.
My natural language is not english, and this seems to imply that for v4.0 on the old method is still valid (Another…).
Other observation is disregard the limits for PID parameters and MP warnings.
@Matt_C, @Webillo, yes indeed, the wording was unclear so I’ve clarified it a bit more to make it clear that rpm1/rpm2 is visible with 3.5 (or earlier) and WHEEL_DISTANCE should be used for 4.0 (and higher).
One slightly difficulty is that because an individual message is sent for each wheel the user can’t easily see both wheel’s distances at the same time…
From this and this (600 rpm at tachometer) it seems that the CPR’s should be around 100. So I left them at 105.6, as calculated from motor data. But then rpm’s with v5.2 appear four times greater (415->105.6).
In regards to the motor support for the Sailboat improvements, is there a way to control stepper motors using the Pixhawk?
My senior design project is to make an autonomous large scale sailboat (14 feet long). I have succeeded with making a small scale sailboat using a pixhawk and servo motors, though for the large scale design I would have to scale up to stepper motors.
Could this update enable a motor driver to be connected with the pixhawk to control stepper motors, or would I have to interface the pixhawk with an arduino in order to use a motor driver and stepper motor? If the latter is the case, how would I go about doing this?
I am currently using Rover 3.5 firmware and everything is running perfectly… Once I upgrade to Rover 4.0 when switched into Auto Mode the rover does not follow mission waypoints and instead just turns on the spot acting confused with which direction it should turn.
Is there something that needs to be changed in parameters in rover 4.0 to fix this?
Got the same issue. In the past this had been a rangefinder issue so I tried to disable it. All RNGFNDx_TYPE is set to 0 but still showing Bad Lidar Health and doing cycles.
The only possible thing I can think of is the change to how CRUISE_SPEED and WP_SPEED are handled. In 3.5 CRUISE_SPEED was used as the default speed for missions if WP_SPEED was left at zero. In Rover-4.0 WP_SPEED is the main parameter to set to control the speed during missions. If this isn’t it then probably best to provide a log file (ideally a .bin file).
This may be the issue. I have reverted back to rover 3.5.2 as it works. Will updating the firmware bring me much improvement in regards to the way the rover is? I mean as the saying goes if it’s not broke don’t fix it. What would I be missing out on without rover 4.0?
The release notes are here so it should be possible to have a look at the list (about the first 67 lines) to see if any enhancements or fixes are important for you.
It’s probably best to provide an onboard log file. As we often say, it’s all guesswork without a log.
Hey!
can you re-enable mis_done_behave in rover 4.0? I miss it because there is no feedback at 200m apart from a melody! Auto to hold and RTL to hold was ideal!