I have a couple of questions about some issues we’ve had using Cockpit.
We get an errorcode saying “multiple joysticks detected” when this is not the case. Is this a known bug?
Also sometimes get “blocked video IP” and some comments about video sizes not growing whilst filming.
The most important problem we have is pwm adjustments made in BlueOS not being followed in Cockpit or QGC. We are trying to control one thruster (motor 3), and I can confirm that the ArduSub remembers it. If we adjust servo_3_min and servo_3_max to 1400 and 1600, it stays like this after rebooting (like it should).
But neither Cockpit nor QGC seem to care about this. Using the servo_output_raw data I have been monitoring the pwm live. It does not stop within the limits we have set. Any tips as to where the communcation fails?
I’m not aware of other similar issues being reported, so if you’re already on 1.18 please provide a Cockpit application log from the Settings > Dev page.
How is your network configured? Possibly a firewall issue, or authentication issue with your camera?
Have you confirmed whether the recording is working properly?
There was an issue about this a while ago, but the only apparent reproduction of it was from a user who actually was having issues with their recording. We ended up allowing disabling the warning, but generally wouldn’t recommend doing so unless you don’t need the video file, or are certain the warning is a false positive (in which case we would appreciate an application log so we can try to determine what’s going on).
Control station software only sends inputs to the autopilot. How it interprets those inputs and decides to convert them into outputs are solely in the domain of the autopilot’s implementation and configuration.
How are the motors configured? If your MOT_PWM_TYPE is set to Normal (0) then all outputs configured as Motor N will use shared MOT_PWM_MIN/MAX range limits. If you want to independently control different motor ranges (and/or trim values) you’ll need to change MOT_PWM_TYPE to PWMAngle (9) instead. We’ve made this clearer in the Vehicle Setup page in recent beta versions of BlueOS, because it’s been a common source of confusion.
I’ll also add this to my list of ArduSub docs content that needs to be written - this should definitely have an official explanation somewhere.
We updated Cockpit from 1.17 to 1.18.2 and “blocked video IP” has gone away, also the error about video sizes not growing.
However - our .mp4 files seem corrupt or not processed correctly. When in operation our view is perfect, but the stored videos somehow fail. Seen this before?
We are running Cockpit on a MacBook Pro 2023 (M3) 8GB Ram, with a 14.2 inch display. When we change the window size all the widgets go nuts. Is this screen format not supported?
Changing the MOT_PWM_TYPE to PWMAngle (9) worked. Is this a recently added feature? We have individually controlled thrusters before without knowing about this motor type parameter.
What is your currently BlueOS version? Could you try updating to 1.4-dev and see if the video problem goes away? To see 1.4-dev you have to enable Pirate Mode on BlueOS by clicking the robot icon in the top-right corner.
Also, can you confirm that you never had this problem on 1.17 and it only appeared on 1.18?
Pretty sure we are running 1.4.3, checked for updates yesterday and none were available (without pirate mode). Will try 1.4-dev tomorrow.
Never had this issue with processing videos on earlier versions.
If you’re talking about the widget/circuz in Cockpit it has always been there on that particular MacBook, that’s why I think it has something to do with the screen format.
The MOT_PWM_MIN/MAX parameters were enabled in 4.1, then the PWMAngle motor type was backported from master in March last year (into ArduSub 4.5.2) to allow individual limits and trim support for users who wanted or needed that functionality.
I’m not sure individual output channel limits have ever worked for outputs configured as motors (they used RC3_MIN/MAX before the MOT_* ones), but if they did I suspect the change would have been when the dedicated motor limit parameters were added, or possibly as one of the many changes that got merged in when we synched up from 4.1 to 4.5.
Not sure it’s relevant but I experienced EXACTLY this type corruption of video on an older version of cockpit/BlueOS. You can see it in this video I uploaded to the Adventure log ages ago (around the 8:22 mark).
I thought at the time that it seemed to be due to a lag between when I pressed record on a touch screen in Cockpit and the indicator showing recording had started. This lag caused me to tap quickly again and I presumed it might have opened two instances/files at the same time but this was a amateur guess rather than a expert diagnosis .
.