Hello everybody,
After updating one of our customers ROV to the latest companion (v0.0.26) and Ardusub ( v4.0.2) firmware the CPU frequency is throttled and capped and the temperature is around 85 degrees Celsius. After all newer udates should fix issues and not offer new ones. How to work it out because we need to returnt it back to the customer?
Regards,
I had to manually pull the MicroSD card and flash a ‘new’ older companion image on my BlueROV2 in order to downgrade companion versions. I have had problems with 0.0.26 and I have heard that at least one other person also had similar issues. You could do that too if you need to get it back to them quickly.
Apparently you could do it from the web page, but I wasn’t able to get it to work: Git · GitBook
I am partially against software updates if you don’t have a problem or don’t care about the new features, since you are gambling the the new version won’t add new problems with no real benefits to yourself. The ROV isn’t connected to the internet so outdated software doesn’t matter.
FYI, ArduSub 4.0.3 is the latest version.
A temporary fix I use is to lower MAVproxy streamrate from 10 to 2:
http://192.168.2.2:2770/mavproxy
That does seems to help, but what are the downsides or other effects of reducing the mavproxy streamrate?
By using streamrate 2 instead of 10, telemetry streams at 2 Hz instead of 10 Hz
So far I have not noticed downsides
So the mavproxy streamrate setting is just the telemetry update Hz? I just started to learn about the software and wasn’t sure what that setting did.
Yeah, mavproxy is a program that runs on the companion computer to facilitate communication between the top side computer and the Pixhawk. The streamrate is the rate that it gets parameters from the Pixhawk, so reducing it just means that the topside gets less frequent data updates (the Pixhawk itself still runs at the same internal data speeds, including collecting depth and accelerometer readings and so forth, it just sends updates to the top less frequently).
Main potential issues I can think of are things like heading integration in PingViewer may not be as smooth/effective, and if you’re trying to control precise orientations/motion from the top side (manually or through pymavlink/mavros) then the slower updates can make that more difficult/take a bit longer (it’s easier to overshoot when you have less frequent measurement display updates). In saying that, for human-based control there shouldn’t be much difference between 10 and something like 5 or even 3, and if you don’t need to control precise orientations at all then 2 should likely work fine (as you’ve suggested).
Mavlink itself supports streaming individual messages at different rates, which could be useful here, but I’m not sure if that’s possible with mavproxy - I’ll have to look more into it and discuss with the software team.
@Synchron there are a couple of others who’ve had issues with mavlink using excessive CPU, and we’re working on an update at the moment that should reduce/resolve that, along with some other issues, which (as far as I’m aware) should be releasing this week. If your timeline is more urgent than that then it may be worth reducing the streamrate parameter for now.
These changes are now available in the 0.0.27 update: