Rover-4.0.0 released!

Thanks for your attention to this problem.

Recall that I maintain two pixhawks on the Barbie, one with v4.0.0 moving the motors, and the other with v3.5.2 (just logging), with the encoder outputs connected to both with servo Y’s. There are two telemetries and I run two MP instances, or one instance with a connection list.

v3.5.2 configuration has no RPM_xx parameters, and RPM0/1 works. For clarity here are last versions:
Barbie352.param (13.2 KB)
Barbie400.param (16.3 KB)

Trying to configure v4.0.0, I found confusing give values to RPM_xx parameters; after all AUX3 to 6 (encoder inputs) are defined with BRD_PWM_COUNT, RELAYxx (3 to 6) and WENCxx on both versions, which are the same on files above.

So v3.5.2 gets data for RPM0/1 from WENCxx parameters, and it works.

@Webillo, @Matt_C, @ChrisOlson,

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.

Ah, I see. It’s (was) an internal calculation, not an actual external sensor input like heli. That explains my confusion.

1 Like

Hi.

Everything is clear now.

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.

Your work is extraordinary; thanks a lot.

1 Like

@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…

2 Likes

EKF3 Compass problems. See this.

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).

It works, including a first auto mode test with RTK GPS.

1 Like

Two more 4K videos with Barbie GPS RTK missions:



image
Satellites positioning was bad; that prevented completing a lap on the small circuit (second video).
2 Likes

Hello,

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?

Any information is much appreciated!

@D-RO,

We have an item on the to-do list to add support for stepper motors but I’m afraid it hasn’t been completed yet.

My only suggestion is perhaps there are motor controllers out there that can drive stepper motors but can also accept a PWM input.

Dear Randy,

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?

Thank you

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.

1 Like

@ArduNoob,

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).

1 Like

@rmackay9 I don’t seem to be able to disable Rangefinders anymore. Any ideas?

@Trent_dutton,

We’ve removed the older “dodge” style of object avoidance and replaced it with BendyRuler which is still not perfect but is much better at least.

Individual rangefinders can be disabled by setting the RNGFNDx_TYPE param to zero.

Randy. Tried that buddy and also physically disconnected. Still showing bad lidar on HUD and doing circles.

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?

Four Balance Bot 4K videos with working RTK, with the open sky HDOP’s (since the circuit is surrounded by trees there is a lot of GPS shadowing)

20200131 19:20

20200204 17:30

20200204 17:40

20200204 18:00

1 Like

@ArduNoob,

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.

@Trent_dutton,

I suspect that the lidar is actually not related to whatever is going on but I think I’ll need to see a log file…