Boat seems reluctant to run WayPoint Missions.

[Colechr56]

Won’t go to WayPoint action.

INAV Configurator v7.1.1, FC firmware v 7.1.2. (SpeedyBeeF405Wing). F405WingApp, BOAT, TX16S, receivers (both tried) R168, or X8R. BZ-251. No VTX. INAV LUA widget.

Boat is fitted with bow and stern thrusters, 2 main motors, and rudders. Boat performs OK in “Manual” mode. The control includes differential turns with rudder, on motors & thrusters, and sideways movement on roll control.

Pre-Arm checks are good, and the GPS gets a 3D lock within minutes. I have set a (single WayPoint) Mission in Mission Control, with RTH after WayPoint, saved it to the hard drive, saved it to the EEPROM, and after bootup at the pondside saved to the FC. After a moment, “Mission Valid” is good. (nav_WP_safe_distance = 500, and the pond is not much bigger than 100m x 400m?)

The modes have been set on the TX16S, such that Arming is on switch SF, and the 6 position switch is used for modes:
6P1 Manual
6P2 NavWP
6P3 NavCr

When the GPS 3D lock is confirmed, the boat is in the water, and then the FC is armed, with the mode still set for “Manual”. Boat can manoeuvre round the pond, without problem. Then back at the starting point, the mode is changed to 6P2, “NavWP”. The TX16S & telemetry both report NavWP mode. (I set the special function to play the navwp track, and INAV LUA plays a similar track from the INAV sound file.)

However, the boat does nothing. I can, though, drive the boat on the transmitter sticks, (without changing anything,) as if the boat is still in manual mode. The INAV LUA widget green section, does show the WayPoint, and the distance from it, to the boat, and the boat icon relative to it. Sometimes the LUA reports “ACRO Mode”. (I haven’t set Acro.)

The GPS is exact, on the laptop, and a cross check on google maps. However if I try SpeedyBeeApp, the map shows the location, some 50-100m away in the housing estate! Is the change from 6P1 to 6P2, too quick, and does it require that the Manual mode is switched off before switching on the NavWP?

What am I missing? I attach the last CLi dump file, but though I have a mem card in the F405, and possibly BlackBox may have recorded something, I am unsure how to get at it without dismantling the FC. I do have quite a few “sensor lost” messages, and occasionally battery critical. The battery is fine, a 5300mAh 3S, at levels of at least 70% capacity, when doing trials. Max current draw is only 20A.
Many thanks.
INAV_7.1.2_dumpcli_20240729_091112.txt

[stronnag]

A blackbox log would probably resolve the matter.
You should be able to read it via USB in MSC mode (type msc in CLI and wait until the OS reports a removable drive).

[Colechr56]

I have had a look and think I got the blackbox files? see attached
LOG00032.TXT
LOG00031.TXT
LOG00030.TXT

[stronnag]

Superficially, there is no evidence that the FC gets the mission mode

$ inav_states.rb ~/dl/LOG00032.TXT 
INAV 7.1.2, states from 7.0.0
LOG00032.TXT: INAV 7.1.2 (4e1e59eb) SPEEDYBEEF405WING
Iteration	Time(s)	Elapsed(s)	State	FltMode	navFlag
        0	 460.9	(   0.0)	nav_state_undefined (0)	ARM|MANUAL	
   534144	1003.7	( 542.8)	end of log
[jrh@eeyore]$ inav_states.rb ~/dl/LOG00030.TXT 
INAV 7.1.2, states from 7.0.0
LOG00030.TXT: INAV 7.1.2 (4e1e59eb) SPEEDYBEEF405WING
Iteration	Time(s)	Elapsed(s)	State	FltMode	navFlag
        0	 707.4	(   0.0)	nav_state_undefined (0)	ARM|MANUAL	
  1174432	1901.3	(1193.8)	end of log
[jrh@eeyore]$ inav_states.rb ~/dl/LOG00031.TXT 
INAV 7.1.2, states from 7.0.0
LOG00031.TXT: INAV 7.1.2 (4e1e59eb) SPEEDYBEEF405WING
Iteration	Time(s)	Elapsed(s)	State	FltMode	navFlag
        0	  37.0	(   0.0)	nav_state_undefined (0)	ARM|MANUAL	
    97472	 136.1	(  99.1)	end of log
Disarmed by: FAILSAFE

[stronnag]

The heading reported and direction of travel do not correlate. The compass is not reading correctly, either due to misalignment, mis calibration or EMI.

That there is no GPS heading may be because the GPS dynamic model is inappropriate. Setting it to PEDESTRIAN may help.

It may also be the case the the ground sea speed is so slow that INAV doesn't believe you are "flying" and therefore refuses to enter WP mode.

This needs somewhat deeper analysis, which I'll try and find the time for later this week; the above is more "notes to self" than anything else.

Abd finally, a CLI diff is much more useful than dump for diagnostics. That way we see only what is changed.

[Colechr56]

Hi
Attached is the DiffAll file from after modifying the gps_dyn_model.
I like the satellite view. Is that something that is generally available, to analyse courses etc?
regards CC
INAV_7.1.2_cliDiffAll_20240801_080939.txt

[Colechr56]

Hi Jonathan You have set me thinking, and I had a look at the settings for the 6P switch, and it looks like I have corrupted the global value settings, so that the 6P values were not actually changing. Resetting, and on the garden table, I can see the configuration modes changing colours. Manual is light blue when selected, but navwp goes dark blue, probably because the mission is emptied after reboot, though navrth is light blue. It looks a lot better. The GPS compass was off kilter too and I had to reconfigure the compass/accelerometers. I will have a look at your further recommendations tomorrow, but it does look more promising. Very many thanks. CC

…

On Wed, 31 Jul 2024, 20:55 Jonathan Hudson, ***@***.***> wrote: The heading reported and direction of travel do not correlate. The compass is not reading correctly, either due to misalignment, mis calibration or EMI. That there is no GPS heading may be because the GPS dynamic model is inappropriate. Setting it to PEDESTRIAN may help. It may also be the case the the ground sea speed is so slow that INAV doesn't believe you are "flying" and therefore refuses to enter WP mode. This needs somewhat deeper analysis, which I'll try and find the time for later this week; the above is more "notes to self" than anything else. Abd finally, a CLI diff is much more useful than dump for diagnostics. That way we see only what is changed. image.png (view on web) <https://github.com/user-attachments/assets/a1a4bec0-d777-4b89-b658-c7b1b9abc15d> — Reply to this email directly, view it on GitHub <#10268 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBZMUYSWFTLV7SWXPZDR67TZPE6KHAVCNFSM6AAAAABLZB3JUSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRQGQ4TGOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[breadoven]

Light blue on the Modes tab means the mode is selected but not active. Dark blue means it's selected and active.

Looks like WP mode didn't work initially simply because it wasn't selected in the first place probably because the Tx switch wasn't working as expected.

[Colechr56]

Yuup.. I am sorry about that. There is so much going on at one time, I lost track of the basics. I was getting confused as I was getting many sensor lost messages, I have a whirling/resonance noise issue with the prop shafts, and couldn't see what was going on, as the Inav lua screen was intermittent. Not sure how settled the TX16S is as eg when I set the lua screen widget to full screen, the display locked up. I don't have a vtx display, so was relying on the tx messages, and the SpeedyBeeApp which was giving big map positional errors. Microsoft are not allowing new access to Bing Maps, and I can't get the key, and Azure is still on the way. The Tx is on the latest EdgeTx version. It's all good fun and quite exciting working through it all! Many thanks CC

…

On Thu, 1 Aug 2024, 08:54 breadoven, ***@***.***> wrote: Light blue on the Modes tab means the mode is selected but not active. Dark blue means it's selected and active. Looks like WP mode didn't work initially simply because it wasn't selected in the first place probably because the Tx switch wasn't working as expected. — Reply to this email directly, view it on GitHub <#10268 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBZMUYRSS3UWAJIMY4NMQNDZPHSTXAVCNFSM6AAAAABLZB3JUSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRQHEZDOMY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Colechr56]

WayPoint Missions does work. At least now NavWP fires up, and runs the main motors and thrusters. GPS is repositioned closer to the FC, but with a home made screened cable.
Been to the pond, and did a run round 1st on manual, then returned to pond edge. Started the phone SpeedyBeeApp. Checked the Mission Planner and still the map shows the man standing in the estate, about 100 further south! I loaded the 1 waypoint mission from eeprom, valid mission, then saved to the FC, again valid mission. FC armed and mode set to NavWP. Main motors and thrusters start and try to drive the boat south, not as expected north to the WP1. Switched to manual, and drove towards the WP, at least away from the pond side, and mode changed back to NavWP, boat immediately turns south. Not sure if it's looking to go to the home position (on shore) or the map has the WP in the wrong place. Note the laptop wasn't connected, but had been checked along with Google Maps confirming the Mission and WP are correctly "in the pond!"
Still getting many "sensor lost," and intermittent INAV LUA display. The test stopped as the system was reporting Fuel 0%. The LiPo was checked at home to be 11.69V, 3.89V/cell, 59%, a 3S 5300mAh with max current draw at +-20amps.
See the txt file and the pic of the current GPS position.

LOG00043.TXT
Many thanks CC

[sensei-hacker]

It might be interesting to look at Bing maps and Google maps on your phone while at the pond. To see if THEY know where the pond is.

[stronnag]

1. You should scrap the R168. These are just cheap junk, in particular they have no ability to provide reliable telemetry.
2. Your compass does not read correctly.

• The calibration / alignment may be incorrect
• There may be electromagnetic interference (metal screws, is the blue object a motor?).

From the attached images (from mwp as you asked earlier), see top right that the Mag heading and Course over Ground (widget between RSSI and AHI) differ by c. 90 degrees. WP and RTH will not work with unless these correlate. The "paper plane" vehicle icon shows the compass heading, which is obviously way off the track and grossly erroneous.

Until you fix the compass, WP, RTH and other navigation features cannot work.
Until you replace the R168 RX, you will have unreliable telemetry.

Otherwise, you're wasting our time ...

[Colechr56]

OK I will go back to the X8R. Yes the blue thing is the stern thruster motor.

…

On Sat, 3 Aug 2024, 16:37 Jonathan Hudson, ***@***.***> wrote: 1. You should scrap the R168. These are just cheap junk, in particular they have no ability to provide reliable telemetry. 2. Your compass does not read correctly. - The calibration / alignment may be incorrect - There may be electromagnetic interference (metal screws, is the blue object a motor?). From the attached images (from mwp <https://github.com/stronnag/mwptools> as you asked earlier), see top right that the Mag heading and Course over Ground (widget between RSSI and AHI) differ by c. 90 degrees. WP and RTH will not work with unless these correlate. The "paper plane" vehicle icon shows the compass heading, which is obviously way off the track and grossly erroneous. Until you fix the compass, WP, RTH and other navigation features cannot work. Until you replace the R168 RX, you will have unreliable telemetry. Otherwise, you're wasting our time ... image.png (view on web) <https://github.com/user-attachments/assets/00ec0441-3763-4e91-96d5-cf8610ed622c> Screenshot.from.2024-08-03.16-22-51.png (view on web) <https://github.com/user-attachments/assets/0cc0c310-b5cf-4a1a-8b22-61c6e4334e2a> — Reply to this email directly, view it on GitHub <#10268 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBZMUYQNNTFU3M3EOK5U5A3ZPT2KFAVCNFSM6AAAAABLZB3JUSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRTGEZDMNA> . You are receiving this because you authored the thread.Message ID: ***@***.***>