Allow sending a param with a different component ID #5356
Conversation
|
Just FYI for here as well: QGC doesn't need a hearbeat to track additional component params. It works as you describe with respect to PARAM_VALUE. |
|
Linking #5277. @LorenzMeier @DonLakeFlyer In order to fully leverage the node health monitoring capability of UAVCAN, we may need to somehow proxy the network health information to QGC through MAVLink. My current proposition is to map the node status codes from |
|
@pavel-kirienko I think that's a very complicated and not very scalable solution. I would instead advise to start by sending an ESC status message with typical ESC information. The vehicle could also send a config summary message with indicates how many motors in which geometry it has. Then display this graphically in QGC (temperature, current, etc). |
|
@LorenzMeier I want to make sure that we're on the same page, because your proposition, while makes sense in general, is actually more complex than mine. Provided that QGC does implement the bad status alerting capability, the approach I outlined introduces virtually zero new entities to the system, and only about one new logical block - the NodeStatus to Heartbeat converter. We already have the node health reporting on the ESC side, QGC already handles Heartbeat messages from different components, we just need to bridge the two together. It is likely that I am underinformed about the way MAVLink works, so it could be that I am missing something important here. The above concerns only the overall health monitoring, which I believe is the most important feature. Additional information such as temperature, currents, and other raw parameters should be less useful to the user, since the health code essentially reduces all of that information into a few discrete states by applying it to the model of the ESC (e.g. temperature and current limits). This is not to say that I don't see the value in displaying this information to the user, I certainly do, I'm just suggesting that it may be a slightly unrelated problem. |
|
What you're missing is that QGC needs to do something sensible with the information - just a list of components is not going to get the user anything useful. Supposed you have 6 CAN nodes and one is "red" - how do you fix it? Its not enough to just get a status somewhere, we need to define the whole workflow to also address the underlying problem. Which also means that you need to give the user enough info so he has a chance of troubleshooting. If we don't do that we just add another confusing "general error" to the system which will leave very frustrated users. |
|
That said we do deliver currently some "general error" messages for e.g. sensor calibration which I consider not acceptable - just to make clear that the status quo for other subsystems is really a bad example not to repeat 8). |
|
I agree that notifying the user about the existence of a failure somewhere is a UX disaster indeed. But your proposed approach of proxying low-level ESC status variables seems like an ad-hoc solution for this very specific case. Besides ESC there will be other nodes that also will benefit from generalized health monitoring, so I propose to rather look into some kind of a more abstract identification of nodes for the user. The status bridge partially resolves the problem, but it needs extension. Can we look at the problem from the top level? What kind of GUI do we want to show for the purpose of CAN node monitoring? From what you outlined above, I imagine that it should be something like poor man's SCADA, with schematic depictions of motors and some kind of generic boxes for all nodes other than ESC (e.g. cargo grippers, cameras, GNSS, etc). |
|
I just tested this while connected via USB, and no node parameters are shown in QGC. This is issue from before as well, so not related to the PR. For some reason, the params didn't load via USB, but did load via the companion link (till date, on master) . While we're working at uavcan params in general, we should get this fixed too. Still haven't tested whether the fix works via the companion link. Need to reassemble vehicle. |
|
@LorenzMeier @pavel-kirienko Confirmed that this fix works fine for me. Only a small issue that the QGC param pull often times out because it takes some time for all the node parameters to be reported. This is also why they don't show up via USB sometimes. |
Times out in what way? |
|
@mhkabir @pavel-kirienko What is the current status of this? |
LorenzMeier
force-pushed
the
uavcan_param
branch
from
d6e8fc2
to
28081ff
Compare
|
Rebased. @pavel-kirienko We need testing! |
|
We're fine on testing. I've tested with pretty much all the UAVCAN boards (GNSS, ESCs) that are available today. It works as it should. |
|
From my perspective that means its not working. Can you raise that with @DonLakeFlyer? Until this really passes testing it makes no sense to merge it. |
|
Someone is going to need to get me some boards so I can test/repro this. |
|
Also attach a QGC log from ParameterLoaderLog would help. |
@DonLakeFlyer Emailed you just now in regards of the hardware. |
|
@mhkabir Can you attach a QGC log with ParameterManagerLog and ParameterManagerVerboseLog turned on for the case where it is not reporting the uavcan parameters correctly? |
|
@pavel-kirienko Thanks Pavel. I have the ESCs now. I've daisy-chained them all together. Now I assume I need to power them all. How many volts do I need? I assume there is no way to test them with powering via USB or something? I need a real battery connection. |
|
@DonLakeFlyer Yes, you need a high voltage supply. Anywhere between 9 to 18 volts should be fine. The documentation can be found at https://docs.zubax.com/zubax_orel_20 |
|
Hi @DonLakeFlyer, were you successful in powering up the boards? Feel free to ask questions if not. |
|
Havent had time to break out the soldering iron out yet and build a harness to power then up. |
|
@DonLakeFlyer How does the soldering iron do? 8). |
|
I did this:
I don't get any additional components reported back from PARAM_REQUEST_LIST. |
(you should have received a USB CAN adapter, which can be used with UAVCAN GUI Tool to monitor what's happening on the bus; it may come useful) |
|
Do I daisy chain the usc can adapter in? Not sure how to connect it |
@mhkabir @pavel-kirienko This allows to send a param with a different component ID. I already did what I think is required for UAVCAN (in the 2nd commit). Please compare and let me know.
@DonLakeFlyer If its not already the case: I would advise to allow component params without receiving a component heartbeat first. Essentially instantiate the component as soon as you see a PARAM_VALUE message with the same system ID but different component ID.