Excellent idea to me!
Very nice work and post.
However I challenge the real world interest of swapping our current DIY’er unrestricted vast devices choice in exchange for the advantage of a reduced set of wires having a huge disadvantage to be restricted to a very limited set of UC4H compatible devices. UAVCAN is theoritically great at the moment all devices will be UAVCAN designed.
And then we should also mention the CAN bus reliability problems car manufacturers have experienced and still have with the sensitivity and wiring fiddliness of CAN bus with parasitic signals and noise (not only EMI, EMF, etc but also metallic structures, magnets, etc). Wiring , terminating and balancing correctly a can bus is way more trickier than regular point to point cables. I’m not sure this is a win or easier or more reliable for the hobbyist DIY’er who does not master the do’s and don’t of a correct CAN bus wiring. You cannot mix devices with different baud rates either which is another limiting factor. You cannot mix CAN bus wires with non CAN bus wiring (due to parasitic noises between each). You cannot have different length CAN bus high and low wires. You cannot have unbalanced CAN bus segments between each hops. And I probably forget many other restrictions/issues.
Am I wrong ?
I see with UAVCAN lots of potential to extend features , capabilities and sensor capture distance.
The integration of some functionnality within Mision Planner (thanks to @Michael_Oborne ) , and the availability of affordable nodes from jDrone, is really appealing. I guess we should finally see the release of additionals devices from @proficnc and others suppliers pretty soon.
I think we (Devs, Beta Testers and Advanced Users) have to jump in the bandwagon and start experimenting and documenting the implementation of this technology and the rest will come naturally.
@olliw42 would you comment on this ? Does using tunelling alleviates this restriction ?
First of all the distances we are dealing with are much shorter than a car. Two the purpose of the UC4H project is to let DIY people learn about and experiment with UAVCAN with the hope of encouraging manufactures to jump in and make native UAVCAN components.
my comments would be that it probably would be useful if not every thread on CAN stuff would be increased in size by discussions on general points but would probably be better placed in their own thread, and that I’d prefer to not comment.
on the QMC5883 matter:
I did add now something, however: As best as I could from looking at the datasheet, but couldn’t test since I don’t (yet) have a QMC. I actually would not bet on it that it works; there are some points unclear to me, e.g., ArduPilot accesses registers 0x0C,0x20,0x21, which are not documented in the datasheet, and I could not yet find a source doing similar. Also, the correct orienting isn’t yet clear to me. Anyway, attached pl find a firmware version, which at least for the HMC5883L still works LOL, and which offers a MagSensorType = 2 option, for the QMC5883. I’ve ordered a GY-273 module which should come in few days. So, you could test now, or if you prefer to not spend your time pl wait until I could test myself.
uc4h-gpsmagbaro-v027a-4ppoirier.zip (45.8 KB)
EDIT: well, I can’t resist to comment on this:
Two the purpose of the UC4H project is to let DIY people learn about and experiment with UAVCAN with the hope of encouraging manufactures to jump in and make native UAVCAN components.
I respectfully but strongly disagree. It’s purpose is to allow DIY folks to build a fully functional fledged out UAVCAN copter. And I believe to have largely accomplished this goal.
I cannot claim to represent any significant portion of DIY’ers, but for me the reduced number of wires is the least of my concerns - its kind of a bonus, with a very small hardware reliability impact (fewer wires to nudge while removing/installing a battery).
I do agree that moving to a purely UAVCAN system is not yet achievable without temporarily sacrificing access to our immense hardware ecosystem, but efforts are underway to alleviate this shortage of purpose-built sensors and equipment by means of generic nodes which serve as gateways for the unrestricted vast number of devices already available.
For me, the greatest offering that UAVCAN brings to the table is that of bidirectional communication at scale - without the limit of UART ports, the single-ended nature of PWM, or the distance and (greater) interference issues of I2C. The bidirectional nature of UAVCAN permits a suite of complex behaviors that are hard to implement otherwise:
- Telemetry reporting from critical elements (ESCs, Servos, and Airspeed Sensors, for what I use). These are available in ways specific to each - S.BUS2 for servos, and BLHeli_32 for ESCs come to mind, but they are disparate by manufacturer, and have limited adoption in my circles as of yet. We still have a chance to set a popular standard for this kind of telemetry.
- Live configuration of devices on the network (configurable parameters for each component through the UAVCAN GUI Tool, and perhaps eventually on-the-fly)
- Equipment accountability - from failure detection and correction to merely finding out what’s to blame for your crash, the message-based nature of UAVCAN should make it easier to log for these purposes.
Regarding reliability, I would make the simple “cop out” that UAVCAN ought not to be any worse in reliability than current interfaces which are popular, including UART and I2C (both of which are explicitly not suited for external runs and EMI-laden environments). The exception would be PWM, which is so simple that it is hard to mess up, with the exception of very intense interference, shorts to any one PWM line (losing one control surface is just as fatal as losing all of them, I think), and physical disconnection. These failures apply to any interface to operation-critical components.
The only defense I can give regarding automotive comparisons, is that the difficulties suffered by automotive manufacturers should be alleviated by the smaller scale of our CAN networks, both in physical span and node density. Additionally, the environment proffered by automobiles is more harsh than most DIY vehicles - in temperature range, EMI, timing criticality, chemical exposure, humidity, etc.
As for DIY’ers being able to apply engineering best practices for CAN buses, I do agree - there will be challenges in implementation at large scales. That said, my experience with the devices show the implementations to be robust at our scales - merely using existing I2C cables, hubs, hand-soldered extensions, I’ve not had difficulty in achieving functionality. Bullet-proof reliability, however? That remains to be seen . . .
Please don’t misunderstand my attitude - all of your concerns are valid and need to be addressed as we move forward - especially, I think, the ability to use the hardware we wish. But I also do not believe that they are show-stoppers for progress, despite the unique challenge of an end-user dependent implementation process (DIY for short ).
excellent post, thx.
well, I think especially on a plane, and especially on the ones there the wings can be taken off, the much reduced wiring due to daisy-chaining and two CAN ports should be a real benefit, in simplicity, maintenance, reliability … I find that very convincing … I’m actually amazed that all these plane folks don’t loudly crying for CAN …
I tested your load, but it shows error , and I confirm that the compass is workis as I tested with the Arduino compas.ino as STMduino loaded on the bluepill
Then I switch to my GPS Compass (original HMC5883l), and I get NODE OK, I bitmasked to MAG an enable Debug, but still cannot get the mag values:
Do I miss a dictionary ?
many THX! It would have been a lucky punch. So, you’ll have to wait few days.
LOL, this is funny … would never have expected this. Yes, you seem to miss the newer
MagneticFieldStrength2 dsdl file, but it’s actually not that new, it is part of the standard DSDL, so should have come with it. I’m not sure I can give a recommendation of how to correct this. It can be done manually by grabbing the respective dsdl file and copying it into a folder mentioned on the UAVCAN web page (I think you are on Linux not Win, so I can’t tell you which it is). Probably it would however be better to get a “correct install”, whatever this means, I mean, who knows what else is missing…
the good message, it seems to work for the HMC5883L
I have come across randomly missing dsdl definitions, namely airspeed related and less commonly used ones . . . So it may be a distribution bug?
Wouldn’t s.bus servos be a much better use?
maybe, I have my install for already so long that I’m unfortunately totally useless here
some additional, maybe helpful, info: the UAVCAN GUI compiles all dsdl files in “it’s dsdl folder” on each start of the gui. Thus one “just” needs to find the folder there it grabs it’s dsdl files from and copy the needed files to where. For me, on Win, it would be the folder C:\Program Files (x86)\UAVCAN\UAVCAN GUI Tool\uavcan\dsdl_files\uavcan
the picture is from Futaba… if that’s all you need, sure
Hugues, Actually the value of uc4h in particular is that you don’t lose access to that vast array of devices.
As far as wiring is concerned, figuring out the myriad of pinouts needed for wiring is a major impediment to new builders.
Evan110011: Canbus allows redundant wiring for a significant improvement in reliability.
In addition the jst-gh is a big improvement over previous choices like the dreaded df13
I have downloaded the dsl files from here: https://github.com/UAVCAN/dsdl
And copied over here: C:\Program Files (x86)\UAVCAN\UAVCAN GUI Tool\uavcan
Now I can get messages, and value on graph
another UC4H node was given birth
just to know, what was the trick why you didn’t got the values at first? the entries in the bottom looked correct
I’ll need to go to bed now, need to get up very early tomorrow … it’s called day job LOL
,forgot to applied local node ID (top left button) == the node was anonymous …
thats a tricky one that I have to get used to… anyway, thanks for your help
Olli – I am sending Patrick my GPS/Mag node and Power Module. My mapping quad could punch well over 100A so I had to take the power brick off and work and other stuff has piled up and up. I fly planes whenever I get a spare minute! I felt great guilt that I have not used them in the spirit they were lovingly hand made by you. Monsieur Poirier is going to make productive use of these!
Yes I will, actually I like @khancyr proposal that we start a well structured wiki. I will continue experimenting with the different options with the aim to produce / help produce a user friendly wiki with simple step-by-step building an connecting including testing and implementation methods.
That is badly needed as @olliw42 cannot individually get us up to speed as he did so nicely and generously since the last 3 days
Just a note that Jani has a UAVCAN/UC4H wiki already created on his site.
That is pretty nice wiki well detailed, nice pogo pin adapter board for programming, that’s a good ecosystem