ArduRover on real competition R/C 1/10 car on real circuit: missions. FAR FROM WORKING

[Webillo]

Magnetic Interference: probably this is why car orientation fails (and has a remedy).

This is how a traditional compass is distorted when it is near brushless drone and car motors (stopped):

Note that car motor has stronger magnets.

This is how a traditional compass is distorted when it is near a brushless car motor:

When the motor moves, the distortion is reduced on the average.

So the solution is clear: on the car don’t use the internal Pixhawk compass, and place the external compass (in the GPS or as an I2C small module (GY-271)) at the front bumper:

The distortion is hard to appreciate.

Also:
Magnetic Interference
CompassMot — compensation for interference from the power wires, ESCs and motors

[rmackay9]

Ok, thanks for the info. I think for now we don’t support the compass-mot on Rovers. It’s possible to add but not there at the moment.

Re the results in steering mode, definitely that log will help diagnose this. The first step is to determine if it’s a control problem or a heading estimation problem. It could be either …

[Webillo]

Hi.

Although placing the compass GY-271 I2C module on the front bumper, being it the unique compass which calibrated easily, and giving correct orientations, in Guided and Auto mode the result was the same, so a big error is still present.

In Guided mode, even having the car oriented to the destination point, the car turned and went opposite.

In Steering mode the car was handled better than before.

I got two .bin logs. Since they are too big (13MB and 38MB), better than uploading, here are links to download them:
Rover_201805200925_00000176.BIN
Rover_201805201032_00000177.BIN

Thanks for your review.

Here is another test of a motor near a traditional compass:

Wouldn’t it be better to calibrate the compass with the motor out of the car?

[rmackay9]

I don’t think the compass is the issue probably.

The SERVO2_TRIM value of 1517 looks very suspicious because SERVO2_MIN = 1000 and SERVO2_MAX = 1580. Do you know what the full range of the main motor’s ESC is?

The important questions to answer are:

1. what PWM causes the motor to spin full speed backwards? <-- put in SERVO2_MIN
2. what PWM causes the motor to spin full speed forward? <-- put in SERVO2_MAX
3. what PWM causes the motor to stop? <-- put in SERVO2_TRIM

Maybe try using the mission planner’s Motor Test page to check that the throttle and steering are working?

[Webillo]

Recall that the car is a real 1/10 competition one. At the beginning I used the transmitter full throttle range (Futaba nominal), but since Guided and Auto modes didn’t work I had several small accidents (the car was uncontrollable), so I limited manually the maximum speed (SERVO2MAX=1580) at the controller (could be also limited at the transmitter or ESC). The ESC is calibrated to the full transmitter throttle range 1000-2000 (if I take the Pixhawk controller out (receiver to servo and ESC) I can race with the car).

1517µs (SERVO2_TRIM) is Futaba nominal neutral pulse width at the transmitter (moreless). It is the pulse width with which a traditional analog Futaba servo would be mechanically centered exactly.

The transmitter throttle stick has a 7:3 range (set mechanically), although the neutral mechanical point gives mid pulse width (1517µs). There is no backwards speed (no reverse speed admitted on these competition cars), so the whole lower range (first 3/10 of the total range) is used for braking.

So the transmitter is calibrated to give:
-1000 to 1517: the car brakes (possibly ESC shorts two phases). SERVO2_MIN to SERVO2_TRIM.
-1517: car stopped (SERVO2_TRIM=1517).
-1517 to 2000: car accelerates. While in this tests, the Pixhawk controller output is limited to 1580 (SERVO2MAX=1580).

In the Motor Test page, Test motor A button tests car motor, whose speed depends on Throttle %. Test motor B button tests steering servo:
-Throttle % 0: steering servo centered, wheels centered.
-Throttle % 50; steering servo moves wheels half way to left (as if steering stick to left, pulse longer than neutral).
-Throttle % 100: steering servo moves wheels full way to left (as if steering stick full to left, pulse at max length).
Unless I miss something, right steering is not tested.

If observing chin’s and chout’s indications:

Here steering stick is centered (ch1in=1571, ch1out=1517) and throttle stick is at maximum speed (ch2in=1904, ch2out=1579 (speed limited at the Pixhawk controller with SERVO2MAX=1580)). Mode is selected with the transmitter knob, being receiver ch3 connected to ch5 on the PPM encoder, giving ch5in=1070 (Manual mode, being MODE_CH=5).

On the PPM encoder, channels 3, 4, 6, 7 and 8 are open, so they are open inputs. Strangely, ch4in=ch6in=ch7in=ch8in=1498, but ch3in=899.

Recall that I can handle the car normally (with limited speed) in Manual, Acro and Steering modes, although with appreciable latency. Guided and Auto modes don’t work at all all possibly because a big error, as if in this modes the controller would not “know” to command steering for reaching the desired point.

[rmackay9]

Webillo,

Ah, so if the steering moves left when using the motor test page then that means that SERVO1_REVERSED is incorrect. The steering is reversed which explains why the vehicle would drive in the opposite direction from where it was intended to go. Once you correct that you’ll probably find that manual doesn’t work anymore. the best way to fix this is by reversing the PWM direction in the transmitter, if that’s not possible then I think you can change RC1_REVERSED.

[Webillo]

Hi. Thanks a lot. From the rover documentation:
RC1_REVERSED: RC reversed
Reverse channel input. Set to 0 for normal operation. Set to 1 to reverse this input channel.
SERVO1_REVERSED: Servo reverse
Reverse servo operation. Set to 0 for normal operation. Set to 1 to reverse this output channel.

The best characterization of the problem was in Guided mode:
-If choosing a point to go at the north, and even orienting the car north, the car turned south.
-If choosing a point to go at the south, and even orienting the car south, the car turned north.

So what you suggest makes sense. Since the compass works correctly, inverting SERVO1_REVERSE should make the car start correctly in Guided mode, and inverting RC1_REVERSED I can maintain the same control at the transmitter and not touch it (so simply connecting receiver to servo and ESC the car would behave as without the Pixhawk).

So I reversed both RC1_REVERSED 0->1 and SERVO1_REVERSED 0->1. I can control the car normally in Manual, Acro and Steering modes, and hope to test at the circuit Guided and Auto modes within a few days (it is raining now).

In the Motor Test page, Test motor B button tests steering servo, but now wheels move to the right (as if with pulse shorter than neutral). I don’t know if this is what is intended, since now left steering is not tested.

Going back to how much the compass is affected by the motor magnets, here is what happens if inserting a mumetal sheet between a traditional compass and the motor:

The interference can be reduced, but depends a lot on where is the mumetal sheet placed. Has inserting mumetal between rover motor and compass been tested?

[rmackay9]

Webillo,

OK, sounds good. I suspect the vehicle will mostly drive in the correct direction now but I guess we will find out after the next test.

There was a lot of discussion of mumetal many years ago with Copters when we were first discussing how to resolve the massive magnetic interference many users were seeing. I haven’t seen too many people use this solution though, in general they all just buy GPS/compass module masts.

[Webillo]

Hi.

Like night and day; close to perfection. A first test is here:
Ardurover mission test in real car R/C circuit (test 1)
(4K 50 fps)

The speed will be increased in next tests, since here it is limited with:
WP_SPEED,2
CRUISE_SPEED,2
SERVO2_MAX,1580

Another improvement will be to trim the waypoints:

as well as testing a mission with several laps. I don’t know if the trajectory will be repetitive.

In Acro, Steering and Auto modes (not in Manual) at times front wheels move from left to right and back, oscillating, although trajectory is followed.

In relation with compass calibration and use of mumetal, it is clear that when the traditional compass is near the motor, the interference depends heavily on the rotor position. If it is moving (“Run” in previous photos) the interference is low. So possibly it is best to calibrate the compass with the motor out. Aditionally, a sheet of mumetal between motor and compass may provide some more isolation.

Not using the Pixhawk internal compass and placing the external compass far from the motor (on the front bumper) is equivalent to placing the compass (and GPS) on a mast, but possibly mumetal was tried on multicopters and not on a car, with much stronger motor magnets.

[dkemxr (Dave)]

Not sure if you would find it interesting but on my Rover (1/10 scale 4WD truck) I didn’t like having center throttle as neutral with Fwd/Rev higher/ lower throttle so I set up a mix with a switch (a gear selector essentially). Neutral at throttle zero and full Fwd or Rev depending on switch position.

[Webillo]

In general, in electric car R/C competitions, reverse speed use is considered dangerous. From an EFRA Handbook:
“Speed controller reverse operation must be disabled.”

On above transmitter, throttle stick has an spring, with 7:3 or 5:5 mechanical range.

[rmackay9]

Really great progress!

The waggling wheels is probably down to turn-rate tuning.

I think what you may find is that as the speed increases the turns get wider and wider. You can probably make the problem better by setting do-set-speed commands between waypoints but in the near-ish future (Rover-3.5 maybe?) we will introduce some better speed limiting for corners.

[rmackay9]

Webillo,

We’ve done some work over the weekend to improve the speed control on race tracks. This isn’t in Rover-3.4 but it should be in 3.5 assuming we don’t find any issues with it… Here’s a video showing the difference and I think it is directly relevant to what you’re trying to do.

[Webillo]

Impressive. And impressive simulation.
Kart circuit
Better stay in the track so as not to knock the tires!

Anyhow, I have now several aspects that must be heavily improved, that appear in this video:
Ardurover rectangle tests
(4K 50 fps)

The mission is this (two laps (almost) following a rectangle):

There are 4 pairs of waypoints. When the car stops I switch to Hold and back to Auto on the transmitter knob (I will change this, copying and pasting waypoints), so the mission starts again. The points are more less marked with four pineapples (occasionally knocked; I will use inverted plastic plates next time).

On the video and on the kmz gotten from the logs:

it is clear that the trajectory is not repetitive. Can this be improved? Note that speed is very low.

Regarding the waggling wheels and turn-rate tuning, I tried to play with ATC_STR_RAT_x parameters, but didn’t find the problem and left the default values. If you watch the video at 4K on a big screen you can see that wheels oscillate a few times, but most of the time they don’t. If I am not wrong, if these parameters were maladjusted they would oscillate always. What can be the problem?

[rmackay9]

Txs for the videos. A dataflash log will help enormously figuring out how to improve performance. Getting the feedforward on the steering (aka turn rate) controller is the most critical thing, then we can look at the navigation controls.

[mroberts]

Randy, that lane based stuff looks very interesting. Have you confirmed what’s making it take such a wide path at higher speed before you implement the speed decrease? Is it actually hitting the turn_max_g?

I’m finding that 3.4 in sim is behaving differently than 3.3 - it seems to be turning much wider and limits the applied steering well before it hits turn_max_g.

Are you able to post that demo waypoint file and param file, and any changes to the SIM_Rover model?

[rmackay9]

@mroberts,

I don’t fully understand the L1 controller yet (although I’ve documented what I know here on the wiki) but it seems that if the vehicle goes faster, it ends up taking wider turns so at the moment, the key to tight turns is just going slower. The current method in master for slowing down at turns scales down the speed which means that if the WP_SPEED is set higher, the vehicle will definitely make wider turns (assuming no other parameters are touched). The new method limits the speed to ensure the vehicle doesn’t turn too wide. Maybe this was clear already but just to be sure…

Here’s a link to the waypoints file.

I’m not sure why 3.4 would make wider turns than 3.3. All that comes to mind is that we’ve got the acceleration/deceleration limiting working well now. We’ve also changed some defaults including reducing the TURN_MAX_G default… but I’m guessing, I’ll try and investigate…

[mroberts]

@rmackay9

Thanks. Is that run with otherwise default beta r3.4 parameters and the standard SIM_Rover model?

I’ll run it in 3.4 and 3.3 and see how it looks.

[mroberts]

@rmackay9, I can’t show what I was hoping specifically there. It must have been some funky combination of parameters.

I’ve found something interesting re 3.4 - I’ll post over there.

[Webillo]

Here is a mission file:
Rover_20180606_203.BIN.txt (11.2 KB)

which should be:

(6x4 waypoints following a rectangle 6 times, with WP_RADIUS=1)

Here is a link to the log (20MB):
Rover_20180606_203.log: https://mega.nz/#!nUJAgSRa!Op_ocYv7WLlHfvJXQZP5-5WhTc99Lf_jj07A30uJOP0
and the resulting kmz (as zip):
Rover_20180606_203.kmz.zip (294.7 KB)

There appear three intervals in Auto. I don’t know the cause for the green one: the car went out of control and hit an obstacle. The other mode changes are due to selecting them with the transmitter knob.

As seen, they don’t follow at all the rectangle.

The steering wheels oscillated all the time.

Here is the param file:
Rover_20180606_203.BIN.txt (11.2 KB)