@Chad-Sweet

Thanks Chad.

@Matt-Turi

Apologies. Final question for now. Who is the producer of the mavlink message for the barometer data?

@Eric-Katzfey

No problem. I was wondering if I could do that bridging myself by subscribing to the uORB topic sensor_baro and then publishing onto a barometer MPA server but wasn't sure if it was possibly to subscribe to uORB topics in the voxl SDK.

@Matt-Turi

Thanks for the clarification. I'll take a look at the px4-listener parsing too.

@Matt-Turi

Hi Matt,

Thanks for the quick reply and thanks for the example that's super useful.

Just to clarify what you're saying. From my understanding when I do uorb top the topic name sensor_baro is available and I can call px4-listener sensor_baro to get an update from what I believe to be a uorb message? Are you saying that there are mavlink messages also published that will give me the same information and I can use something similar to your example to then create a barometer MPA server?

Hi ModalAI devs,

I'm wondering if it's possible to subscribe to a uORB topic in a voxl module. I want to subscribe to the barometer sensor and there isn't an MPA server for this.

The reason I ask is that when using the voxl-cross docker container I'm unsure which dependency is required to install to get access to the uORB headers etc.

Thanks,
Dan

@Eric-Katzfey

Thanks again Eric. Looks like that was the part I was missing. I'll take a look.

@Eric-Katzfey

Please correct me if my understanding is wrong. I just want to catch you whilst our time zones overlap.

I've just briefly looked through the code for MuORB and uORB. It seems that MuORB registers as a communicator with the uORB Manager and provides a bunch of callbacks that eventually invoke particular functions in the manager when the respective action happens (subscribe, callback, advertise, unsubscribe). I see process_remote_topic() calling orb_advertise() which ends up calling uORB::Utils::node_mkpath(nodepath, messageName) which in the implementation is:

//-----------------------------------------------------------------------------
//-----------------------------------------------------------------------------
int uORB::Utils::node_mkpath(char *buf, const char *orbMsgName)
{
	unsigned len;

	unsigned index = 0;

	len = snprintf(buf, orb_maxpath, "/%s/%s%d", "obj", orbMsgName, index);

	if (len >= orb_maxpath) {
		return -ENAMETOOLONG;
	}

	return OK;
}

This path (notice the /obj) then goes into node_open() which should create a file descriptor using px4_open() with the name /obj/<topic_name><index>.

Can you see point me to where I'm going wrong in my understanding as we've discussed before this directory doesn't exist on VOXL2.

@Eric-Katzfey

I was actually. That's useful - Thanks!

@Eric-Katzfey

OK great. Thanks Eric. I'll take a look and come back here if I have any further questions.

@Eric-Katzfey
Re: ModalAI uORB topic file handle location

Hi Eric. Thanks for getting back to me.

Quite possibly this is a Nuttx thing. I can use the listener just fine however I'm interested to dive a bit deeper into how you ship this data comes across from the DSP and whether I can potentially access that data directly without using uORB. I know I can use uORB to subscribe and get a file descriptor but I thought I'd ask and see if there are alternatives.

Is there documentation on ModalAI uORB implementation for the DSP?