UAVCAN for Hobbiests

finally the newly designed v1.0 PCBs have arrived and I’ve build a couple of them

below a photo of all world-wide existing v1.0 uc4h modules :smiley:

so far all looks good, they all have passed the bench tests and all pcbs are like I wanted
tomorrow I’ll plan to test-fly mine, to have the final proof

(I guess I will start a new thread once some “data” comes in for them… )

cheers, Olli

3 Likes

I did a couple of test flights today, and the modules appear to work great, could not see any issue with them

even though I’m largely talking to my self here, I want to share this part of the story, however, since I think it’s a great example of what two GPS units can do:

In these tests I had an issue with my copter, in that the standard ublox gps, connected as usual to a serial, had serious outages in the first flights. I can’t remember having seen that before, and I’m absolutely sure that this was because of the wiring of that GPS - I still use the crappy wires with which it came delivered… and rattling on them made the issue go away. Anyway, the good message, the uc4h GPS did not had any issue at all, and ArduPilot happily went along. In fact, and this is now really the point, I didn’t notice ANYTHING of that during the flights, the flights felt just normal! I saw that only afterwards in the logs, and was in fact “surprised”, you know, I didn’t had noticed anything before … I think we can safely assume that if I would not have had the uc4h gps on-board, I would have noticed immediately, in one way or the other :stuck_out_tongue_winking_eye:

Well, you of course could say, “Get your dammed wiring right”, and you are of course right, but … I’m glad I didn’t had an incident :rofl:

Great stuff this GPS blending thing!

In terms of data it looks like this:
(in the map please notice that the green line is GPS2 or the uc4h gps, while you can nicely see the outages of GPS1 in the blue line)

In the lower center of the image when the blended (yellow) averages the two gps ,which have drifted apart a considerable distance, the blended “short-cut” track is about half way between the two GPS. Did you experience any abrupt changes in flight or did it smoothly take the blended path?

Cheers

good question, I too wondered about what this is supposed to mean, as well as the behavior of the red line
such cases are also visible in the top right loop
no idea

no, I did not notice ANYTHING of that, the flight was perfectly smooth, as usual, no jumps, and certainly not by 3 meters

this might not be so in hover, in the very first of today’s flights the copter was quite jumpy in hover, maybe I should dig out this log too

but at the end of the day, I guess I’m too lazy, the copter now finally got new wires for gps1, and all that is totally gone and is as before, I should have replaced them long ago … too lazy (or too busy)

edit: we should not forget that this is on master, which is not yet perfect

1 Like

Well it also indicates well for the blended GPS code since previously with two GPS, that did not agree, the aircraft could abruptly change when Arducopter switched to the second GPS.

Hello Pavel ,
With Arduplane 3.8.2 I am not able to have the Zubax working, I still receive a “no gps” status from Mission Planner.
I have configure the node_id and set “gps_type” to 9 .

BRD_CAN_ENABLE and GND_PRIMARY parameters do not exist anymore.
A new CAN category is now present.

How can be configured the Zubax with Arduplane 3.8.2 ?

UPDATE: Setting CAN_P1_DRIVER to 1 makes the GPS to work :slight_smile:
How to configure the Barometer and the Compass with Arduplane 3.8.2 ?

@olliw42 first off, I’d like to say how impressed I am by what you’ve done with UAVCAN for hobbyists! I didn’t know about this discussion until it was raised in the weekly dev call today, and I’m kicking myself for not paying closer attention and seeing it previously given it has been going on for many months. I’m really amazed at your persistence and the fantastic progress you’ve made.
You had a Q on the dev call topic about custom DSDL and what to do about it. I think the answer depends on the nature of the DSDL. If the DSDL is for messages that @Pavel_Kirienko is happy to consider for upstream acceptance then going via Pavel and getting it upstream is best. If the DSDL is not something that Pavel wants to consider for upstream but we do want to accept it for ArduPilot then I think it should go into the ArduPilot git tree.
Let’s take the example of DSDL for I2C-over-UAVCAN or serial-over-UAVCAN messages. Pavel has made it clear that he doesn’t want that in upstream UAVCAN, but I think it is something we should have in ArduPilot (if only to make hobbyist and prototyping easier), so the DSDL for that should be in the ArduPilot git tree. I think putting it in a libraries/AP_UAVCAN/DSDL directory in the ArduPilot git tree would make sense. @EShamaev, would you be happy with that?
One thing I’d really like to see with your work @olliw42 is to create a github fork of ArduPilot with your work. @james_pattison pointed out on the dev call that you do have it in a github repo here:


but that isn’t a fork of the ArduPilot git tree, so we can’t use normal git tools to merge, rebase, cherry-pick etc. We’d have to manually edit files to track changes. Would you be willing to redo your work as a normal github fork with your changes on top?
Perhaps we should add a small sample DSDL message in libraries/AP_UAVCAN/DSDL to act as an initial example? Maybe a simple message with a string that gets displayed as a MAVLlink STATUSTEXT? Just something to get started with our project specific DSDL, and get the build rules right and tested.
Cheers, Tridge

they should be working if you set CAN_P1_DRIVER. I fly my ranger with a Zubax1 and its working for me. Do you not see them?

Hey Tridge,

thanks for chiming in and spending your precious time on this.

As regards my persistence you should not be impressed; it is limited. It is actually essentially exhausted, and I plan to sell off my pixXXX’s (except one). I have aimed at too high hanging fruits here and am too dependent on others for my lack of skills; the two topics you address are two examples :).

DSDLs: At the end of the day I would not care where or by whom they are placed. I just strongly feel that the current situation, where I had to fake them into the standard DSDL section (since I didn’t know better), isn’t the proper way. I also note that the concept of “vendor specific data types” is part of the UAVCAN concept. To me that implies that it doesn’t have to be either “accepted by Pavel” or “go into the ArduPilot tree”, it also could be just a folder which anyone who makes a fork for her/himself can place her/his messages. An example to explain that could be the UserCode,UserVariables files. You offered a place for anyone to put their stuff, but whatever anyone puts in there rarely goes into the ArduPilot tree or even higher upstream.

In the git issue I suggested a folder structure like (taking your suggested folder as base):
libraries/AP_UAVCAN/DSDL/ArduPilot
libraries/AP_UAVCAN/DSDL/ThisAreYourPrivateDSDLs
libraries/AP_UAVCAN/DSDL/ThisAreMyPrivateDSDLs
libraries/AP_UAVCAN/DSDL/…
this would only require adapting the build system such that it also dsdl-compiles everything it finds in libraries/AP_UAVCAN/DSDL/.

GIT: Well, that’s a problem. I’ve explained that already to james pattison: I’m not using git and find it difficult enough to be extremely reluctant to learn it. I in fact had made several attempts to read and comprehend the AP docs, but every time got lost half-ways in the middle and stopped. I don’t need it for what I’m doing, and I don’t find it a comfortable tool. I’m a hobbyist. The set of tools you guys use is above my level.
(you may find it not too difficult to find the changes though, searching for //OW does it)

Cheers, Olli

Hello tridge and thanks for replying.
I suspect that yes in Arduplane 3.8.2 both baro and compass work since I was able to calibrate an external compass .
A doubt remains about the baro , is baro 0 always the Pixhawk baro ?
A message during Pixhawk boot with “CAN baro detected” and “CAN compass detected” would help user .

Recently I tried my second Zubax 2 with Arducopter 3.5.3 and had problems.
First I notice that the CAN configuration is quite different from Arduplane, you have to go in BRD parameters to allow CAN operations , this make things a bit harder for the user.
I loose quite time with a defective CAN cable (will order today some JST GHR-04V-S connector and do my own cables) and then discover that both Compass and I suspect baro do not work.
External compass ID is a weird number and even if apparently it is detected, no way for me to get it calibrated.
The baro of my Pixhawk is defective , get always “bad baro health” message, so I selected with GND parameter the Zubax baro, baro 1, but still receive the “bad baro health” .
Where can I see if the Zubax baro is working ?

In Zubax website , the documentation to explain how to use it with recent version of Arduplane and Arducopter is obsolete, it would be fair if Pavel would update it , Zubax is a great product , it deserve a great documentation.

These are bitter words Olli …

I have a great admiration for your work and your skills that I fiercely envy, your work with UAVCAN for hobbiest is a great example of Open Source meaning , thanks!

they are not bitter but true :slight_smile:

well, if you consider the truth bitter, then … … this becomes philosophical hihi

@lucamax For a reference, this is where the docs are posted at: https://kb.zubax.com/display/MAINKB/Using+Zubax+GNSS+with+ArduPilot+autopilots

I suppose you were referring to that page in your post. Yes indeed, these instructions may be a bit outdated. I am considering to drop them completely in favor of the ArduPilot’s wiki. Would someone please volunteer to draft up an updated setup manual on the ArduPilot’s wiki? I can’t do that myself because I don’t currently use ArduPilot (sorry everyone).

GIT: Well, that’s a problem. I’ve explained that already to james pattison:
I’m not using git and find it difficult enough to be extremely reluctant to
learn it. I in fact had made several attempts to read and comprehend the AP

If you ever decide to try again and get stuck with anything, stop by the
ardupilot gitter channel. We help many people on there with git
stuff.

hey Folks

I did some more flights these days, and as a result have just decided to officially declare the UC4H project as “working”. :slight_smile:

The UC4H nodes are working well. There are of course little things which still could be improved and changed, but overall I’m very satisfied. It’s working and I very much like my UC4H-ized copter, it is more reliable than ever before. In this sense the project has accomplished its goals.

I’d like to leave some comments on its current applicability:

In principle, the UC4H nodes can be used in any UAVCAN network. That’s the idea of UAVCAN. However, in practice the options boil down to ArduPilot, with these additional restrictions:

(to the best of my knowledge! please correct me where I am wrong)

ArduPilot master:
You need to flash at minimum from master. The “new” UAVCAN support is only in master so far. As much as I know this holds true for both Copter and Plane. However, master only supports the GPS and magnetometer UAVCAN messages, but not the UC4H power brick. With ArduPilot master you can use the UC4H gps-magnetometer node.

BetaCopter 3.6dev:
This is a fork of ArduCopter master of 12. Aug. 2017, and has compiled (and flight tested) binaries for v2 and v4 flight controllers. It has full support for the UC4H gps-magnetometer and UC4H power brick nodes (as well as for the STorM32 gimbal controller). Thus, if you want to make use of the full potential of the UC4H project, you want to flash BetaCopter3.6dev-v005 (binaries are here: https://github.com/olliw42/storm32bgc/tree/master/betacopter/betacopter36dev-v005/ArduCopter). The limitation is that it is only for Copter, and v2 or v4 flight controllers.

The UC4H SLCAN adapter is of course independent on any flight controller support, and also UAVCAN, and thus can be used in any CAN bus network.

I admit that I would have expected the project to attract more interest among hobbyists; I even thought it could evolve into a sustainable source of funding for ArduPilot LOL. But I’ve grossly misjudged that; I have failed to realize that CAN and UAVCAN in particular is pretty much unknown to them. It’s not on their plate (thx Mike for teaching me :)). However, I myself have benefited a lot. I have now a SLCAN adapter to work with CAN without having spent 80$ or more, and I never would have put a CAN transceiver onto a STorM32 board otherwise. Even if it would be for these side effects only, it was a great endeavor.

I’d like to close with saying a big thanks to all those who have supported this with answering my pesty questions, THX to EShamaev and Pavel! Especially Pavel!

Hopefully ArduPilot will tighten up its lose ends related to UAVCAN rather sooner than later. It would be cool to see the new UAVCAN environment become part of AC3.6.

Thx, and cheers,
Olli

1 Like

Olli, thanks for pushing the boundaries: it’s people like you who keep projects like ArduPilot moving forward.
If you have suggestions about how to keep this moving forward, or how ArduPilot can support contributors like yourself a bit better, feel free to drop me an email.

1 Like

well, as said, UC4H is IMHO working, I don’t see significant lose ends which would need immediate attention. I do see lose ends on the ArduPilot side. The magnetometer support could need attention, the GPS support is even dodgy if not buggy, hints point to that the GPS blending has edge issues, the circuit status PR is not merged, there is no possibility to configure UAVCAN node parameters, the DSDL messages are somewhat of a mess, there is the issue of supporting custom DSDLs, and so on. I note that there hasn’t been any improvement for many months. Zero. For at least 1/4 year. And as said I do not have the strength to solve them. So, I think the best support would be if ArduPilot’s UAVCAN would reach a state where one could wholeheartedly recommend newbies, dummies, hobbyists to use UAVCAN nodes. UC4H, for the moment, is fine. IMHO.

You are just too fast and a little too early! Keep up your great work!
Are you planing to sell the parts?

Olli, I have to admire you blazing such a trail and just doing this, and working around obstacles. And not just doing this on the bench but in flight, and producing really nice hardware designs as well. I too just found this thread – not that I was looking.

I hope it can result in Ardupilot embracing what you have done and finding a way to get this into master. We really could use CANBUS and your approach just seems to work and has the merit of being affordable. And i2C cable runs just suck!

Olli – you are too modest. You should just directly ping the principal devs when you need something.

a discussion with mike_kelly has brought up this

WARNING:
On the power brick, the labeling for the CAN connector on the bottom side is INCORRECT.

On the SLCAN adapter and the gps-mag node the labellings are all correct.