Now I want to connect to my PixHawk, is it juts a matter of having the UAVCAN enabled and GPS type to 9 or there are other settings involved ?
As promised I won’t comment on the ArduPilot side of using the gnss.Fix message. It’s not just meanness on my side, but that it used to be a can of worms, i.e. when I did it it took me quite some experimenting to arrive at something working, but I have not followed up any development, and I didn’t make the effort to memorize things. CAN enabled and 9 sounds a good start, but that’s all I feel comfortable to contribute here
And what about the Uart1ChannelId ? Do I leave it at -1 or I enable tunelling by setting to 0 ?
-1. You only can use either gnss.Fix or the gps tunnel (it’s on the same pins). Setting ChannleId>=0 would enable the tunnel, but also disables gnss.Fix (i.e the GpsRate setting would become irrelevant)
Fair enough , I understand that you have to set your ‘‘territorial limits’’ so you can focus on the product and not spreading out to the different uses cases.
For the GPS it is highly recommended that the UAVCAN tunnel is used (Uart1 ChannelId >= 0), and not the UAVCAN uavcan.equipment.gnss.Fix message (this requires using BetaCopter). Using the latter works fine (I flew with it for a year or so ), but it is somewhat clumsy. I stopped developing it further once I saw that the tunnel approach is going to come. It’s (only) advantage is compatibility with current ArduPilot. If it shall be used, please note: The GPS needs to be configured to 115200 bps by hand, using e.g. the ublox software tool. Description of how to do that can be found in e.g. the rcgroups discussion thread.
I guess this is whee you will change to 57600
As for tunnel = How & Where do we terminate ? (On a node or on the FC) ?
@mike may I benefit from your experience on that matter ?
How did you setted the GPS to work : As gnss.Fix or the gps tunnel ?
And do you have any configurations to share ?
you have to set your ‘‘territorial limits’’ so you can focus on the product and not spreading out to the different uses cases.
well, frankly, this is not exactly the reason, it’s rather that AP’s gnss.Fix handling is not totally trouble-free … not saying it’s all AP’s fault, the gnss.Fix message is also not ideal, and it also lies in the nature of the matter. IMHO as always.
I guess this is whee you will change to 57600
I will change the code to do what it should have done already 15 months ago, to use 115200
As for tunnel = How & Where do we terminate ? (On a node or on the FC) ?
it’s exactly the same wiring you have now, i.e. GPS <-Tx/Rx wires-> RxTx on node <-CANbus-> pixhawk.
The difference is that you set ChannelId>=0, need to load BetaCopter, and set the parameters of one of its SERIALTNL’s to use the GPS protocol (exactly as you would do it with a GPS on an UART for the SERIAL parameter), plus set its ChannelId parameter to the same value you’ve entered in the node. And of course GPSType=2 as usual. (you also can set baudrates to 115200, if you want, but it’s going to be auto-configured, so should not matter at all)
It’s shown in this video: https://www.youtube.com/watch?v=Sw24wAIoemA, start at 3:40
OlliW has tried, for years, to get Betacopter into master but among many issues he does not use GIT, because his tools are easier to use for him. His code needs to be massaged to conform, which is work nobody was willing to do.
Thanks Mike, I have read this and you used Arducopter 3.6dev (Not Betacopter ) as I was expecting to do the same with the GPS/MAG node…
Ok now I see your reference on the rcgroup thread:
“So I loaded up OlliW’s Betacopter fork of ArduCopter and after a bit of troubleshooting got all the UAVCAN settings correct in Mission Planner.”
I"ll look what I can do to get Betacopter into master.
Yes, why not, I may have some hanging around. I dont see much detail on connection and annunciator configuration, do you have a link or video ?
Tunneling question:
The 3 serial tunnels act as additionnals serial ports, right ?
There is a lot of interest to get additionals ports, so UAVCAN Tunneling seems appealing , but how these additional ports are managed by ArduPilot, does it create new instances?
Here is a practical example, lets say we create an avoidance node with 3 UC4H UartBridge Node fed with serial rangefinders (TFMINI). These 3 nodes would be connected with TS0 - TS1- TS2 with 115kbaud and type 9 for rangefinder.
How would the proximity library would consume these 3 streams ?
I dont see much detail on connection and annunciator configuration, do you have a link or video ?
you couldn’t find any since I haven’t put up any … I’ll provide you with the info later (just need to remind myself what the pin was you need to use).
Do the 3 serial tunnels act as additionnals serial ports ?
yes, they do work one-to-one exactly like any of the other serial ports. No difference (except that you need to in addition specify ChannelId of course).
(I think that’s the neat aspect of my tunnel implementation)
There is a possible bandwidth limitation. E.g., if you configure each of the 3 tunnels to 115200 and would use each at full bandwidth this would be roughly 4000 CAN frames/s or more than 50% of the CAN bandwidth. In the BetaCopter code you’ll find some more detailed comments. But except of that there is zero difference to the normal SERIAL ports.
Here is a practical example, lets say we create an avoidance node with 3 UC4H UartBridge Node fed with serial rangefinders (TFMINI). These 3 nodes would be connected with TS0 - TS1- TS2 with 115kbaud and type 9 for rangefinder.
How would the proximity library would consume these 3 streams ?
exactly like if the rangefinders would be connected to normal uarts. All these libraries call the SerialManager (IMHO) to get an uart handle, and would never notice what’s behind the scene.
I should say that I of course have never tested such a situation, so I can just comment on what my understanding is. What I can say, and you can see much of this being demonstrated in the video I’ve linked to earlier, is that I had connected two GPSes and a STorM32 to the three SERIALTNLs (that’s why there are 3 ), and configuration and operation was one-to-one identical to when I would have used normal SERIAL ports.
I can’t see any difference. Unless the proximity library is doing some “strange” uart stuff I predict you’ll find this remarkably simple to do.
@olliw42 did you ever though of adding serial3 to make a 3 ports UC4H UartBridge ?
An avoidance node could be a nice add-on , and the RangeFinder could work as effectively @ 38kbaud
Will do some tests and probably make a wrap up of all the above on a blog
