Shop our Airplanes Products Drone Products Sales
Thread Tools
Jan 03, 2019, 11:13 AM
Wisconsin
Thread OP
Discussion

CANbus for Ardupilot with UAVCAN and UC4H


CANbus for Ardupilot with UAVCAN and UC4H


I think that CANbus is the single most important feature added to the Ardupilot eco-system for years. What is CANbus? Think of CANbus as the internet for multirotor devices like GPS, ESC, Barometer, Airspeed sensors, power modules and Gimbal controllers. Instead of serial, I2C, SPI, PWM and other protocols, CANbus unifies all the devices on your multirotor to one common protocol and, even more important, one cable/connector. In my blog I did a survey of Mini Pixhawks and found that the cables and connectors for the same features were all different on each of the boards. You could not unplug the GPS from one and plug it into any of the other boards. If you wanted to swap one mini Pixhawk board for a different vendor’s board you would have to re-wire everything!

Typical Pixhawk Build without CANBus



What is possible using CANbus, just three connections to the Pixhawk -Power-RC Radio- CANBus



CANbus eliminates the "rat's nest" of wires for Ardupilot builds. All the devices connect to the CANbus with the same connector and it is a simple four-wire cable and they are all the same interchangeable cable for all devices. No more hacking and splicing cables up trying to make one to work. No more trying to figure out for hours if the serial lines go RX-TX or RX-RX. A CANBus network is a “daisy chain” which allows one device to connect to the next and then to the next. No longer do all devices have to go all the way back to the flight controller causing a “rats nest” of long cables with all the related problems they can have.


All of the devices on CANbus are smart devices. Each device knows how to talk to the other devices in the network. The gimbal controller can listen to the position information directly from the GPS rather than going through the flight controller. But this means that each device must be designed for the CANbus. But this also means novel features such as ESC telemetry, which brings real-time ESC status, or high-precision battery information during flight. In addition, a CANbus network wiring can be completely redundant bringing a much higher level of reliability to multirotors.


CANbus was originally designed by Robert Bosch GMBH for automobiles many years ago. Pavel Kirienko created a software layer which runs on top of the CANbus, made specifically for UAVs, that he calls UAVCAN. He also started a company, called Zubax, to produce high quality commercial grade UAVCAN devices: www.Zubax.com Being that they are commercial grade, they are appropriately and reasonably priced for the commercial market, but they are expensive for the DIY user and only ESCs and GPS are available now.






DJI has been using CANbus for years but they can build all the devices themselves. They did not have to wait for vendors to build CANbus devices or the flight controller firmware to be modified to use CANbus.

UC4H for Ardupilot

OlliW, the designer of the STorM32 gimbal controller, liked what he saw in UAVCAN and decided to build an interface to use standard RC components and convert them to be used with UAVCAN and Ardupilot for the DIY builder. It was ground-breaking work for Ardupilot. He created the first system that would allow a complete build using UAVCAN and Ardupilot with all devices connected using UAVCAN.
OlliW calls his project UavCan 4 Hobbyist or UC4H.

Now, in version two, there is a general purpose board that can be used to interface a GPS, ESC, LED lights, Oled Notifier, etc. to UAVCAN for Ardupilot along with a Hall effect power module and KISS ESC carrier boards. These are commercially available at low cost from Jdrones Store. Now, any DIY builder can afford to use UAVCAN. This set of boards allows for complete, fully functional UAVCAN drones, with unprecedented features. With all devices using the same 4-wire cable type with locking, easy to release connectors.



In my first demonstration build using UAVCAN on a quad, I had only three connections to the flight controller - Power, CANBus, and RC radio. No PWM wires going to the ESCs, no cable going to the GPS, no wires going to the power sense on the power module. It is so much simpler to build. More importantly, it is simpler to build CORRECTLY so it will fly reliably.

But first the RULES. There are always rules. OlliW does not sell anything. He makes no money off all the STorM32 gimbal controllers out in the world nor UC4H. He is a hobbyist who is kind enough to share his work with the rest of us. You can use his hardware designs to build your own hardware if you like and you can use his firmware for free. You can use both to make your own commercial product if you like. But this is not open-source firmware. THAT IS HIS RIGHT. He can do anything he wants with it because he wrote it. You can use it for free all you want. You just cannot take it and change it. So let's not debate open source here.


Now back to fun. On my first UC4H build I used junk box parts to hack together a spyder quad based on some plates from a DAYA 680 Folding Quad. The finished quad flew better than any of my previous 12 builds. But I was tired of hacking boards together trying to get everything to fit. So I sketched out a spyder quad with holes for all the things I would need to mount, like the power distribution board, the ESCs, the landing gear, etc. This time I was just going to bolt everything in because it was designed to work. So I sent the drawing to Nick at CNCMadness and he cleaned up the drawings and cut me some beautiful plates. It is a folding spyder quad designed for 17” props. So check out the build log here: https://www.rcgroups.com/forums/show...o#post40884557

I am going to take a pause now and reserve some posts below and copy all of OlliW’s UC4H posts on his blog to here so there is a reference. But I encourage you to visit OllW’s blog to see the latest and greatest article. http://www.olliw.eu/2018/uavcan-for-hobbyists-blog/
Last edited by mike_kelly; Jan 10, 2019 at 10:28 AM.
Sign up now
to remove ads between posts
Jan 03, 2019, 11:14 AM
Wisconsin
Thread OP
UC4H: UAVCAN for Hobbyists
29. Juli 2017 | Last update 2. Jan. 2019 | Theme Multicopter, STM32 Projekte | 12822 Views | 1 Comment
Tag ArduPilot, Drone, MultiCopter, RC-Elektronik, STM32-Projekt, UAVCAN

Want to know about the latest development? … see here ��

The UAVCAN for Hobbyists (UC4H) project aims at connecting things like a GPS, magnetometer, ESC, and so on, to a ArduPilot/Pixhawk drone via the CAN bus using the UAVCAN protocol.

UAVCAN has been made available quite some time ago, in order to bring CAN to drones. The CAN bus is renowned for it’s extreme reliability and is thus attractive for application in drones. However, to the day I think it is fair to say that only few UAVCAN devices have become available, and those which are, are clearly for the professional market, at least price-wise. So, I set out to change that, and started the UAVCAN for Hobbyists project. The initial driving force was in fact that I wanted to get rid of this dammed I2C wires, which we use for connecting an external magnetometer. Soo annoying. Thus, I thought, let’s build a UAVCAN-to-I2C adapter and connect that to the magnetometer, so that the long wires would be CAN now. The project however quickly went (much) further than this.

The project presented me with initial challenges which made me considering to quit more than once. At this point I want to express my deepest thanks to Pavel, for the tremendous work he put into UAVCAN, and for not giving up answering my early questions. Thank you so much, sir!

The project has grown considerably and now consists of many pieces:

UC4H GPS-Magnetometer-Barometer
UC4H PowerBrick
UC4H ESC-Actuator
UC4H UartBridge
UC4H Airspeed-AngleOfAttack
UC4H Notifiers: Notify, Display, OreoLEDs
UC4H IndicatorLED
UC4H FunThing
UC4H MAVLinkBridge
UC4H Bootloader
UC4H SLCAN Adapter

If you want to build a UC4H node yourself, which is really easy, then please inspect the respective chapter on the node as well as the chapters General Build Information and Build Information, more Details for relevant information. The chapter Supported UAVCAN Messages may also be of interest.

You also can buy UC4H boards from jDrones and at the same time donate to the ArduPilot project.

For the latest developments in the UC4H project please inspect the UC4H Blog.

Useful Links

UC4H Github repository, hosting the firmware binaries, Eagle design files, and some more material.
jDrones UAVCAN and UC4H Wiki

TERMS OF USAGE
The material provided in the UC4H Github repository is subject to the following conditions. Firmware files: All firmwares are free (but not open source). Besides unlimited private use you are also granted the permission to use them for commercial purposes under the condition that (1) you don’t modify the firmware, e.g. remove or change copyright statements, (2) provide it for free, i.e. don’t charge any explicit or implicit fees to your customers, and (3) correctly and clearly cite the origin of the firmware and the project web page in any product documentation or web page. Hardware files: All hardware, for which material is provided, is open source hardware, under the terms of the TAPR Open Hardware License as published by the Free Hardware Foundation, see http://www.tapr.org/ohl.html. The TAPR license explicitly permits essentially unlimited commercial use, with only few conditions such as that copyright logos are not removed.


Usage Information

For me, the UC4H nodes are working great; I didn’t had a single incident because of using them. There are of course always little things which could be improved, but overall I’m very satisfied. It’s working, I like my UC4H-ized copter, and in this sense the project has accomplished its goals. I’d like to leave some comments on its applicability.

In principle, the UC4H nodes can be used in any UAVCAN network. That’s the idea of UAVCAN. I only can speak for ArduPilot, however, since that’s what I’m using. With ArduPilot, these restrictions apply:

ArduPilot
ArduPilot master has recently seen substantial changes in the UAVCAN section and is not totally compatible with earlier ArduPilot versions. So, I currently would recommend ArduCopter 3.6.x, to which I refer here.

ArduPilot 3.6 supports the GPS, magnetometer, barometer, ESC, actuator, and IndicatorLED UAVCAN messages. With ArduPilot you can thus use the UC4H GPS-Magnetometer-Barometer and UC4H ESC-Actuator nodes out of the box.

BetaCopter 3.6
This is a fork of ArduCopter 3.6, and has compiled binaries for v2 (Pixhawk), v3 (3DR Solo, Pixhawk2), and v4 (Pixracer) flight controllers. It has full support for the whole family of UC4H nodes, as well as the STorM32 gimbal controller. Thus, if you want to make best use of the potential of the UC4H project, then you want to flash BetaCopter 3.6 (you need the 'u' version, e.g. BetaCopter 3.6.1 v0.14u, see the github repo for details).

The code additions in BetaCopter are basically vehicle independent, i.e., it should be possible to compile the source also for other vehicles such as planes and rovers with only minor changes, and it therefore probably should be called BetaPilot. However, I’m using only copter, and only can test for copter, and for (only) that reason I speak of only copter. ��

The BetaCopter sources and binaries are available from my github repo: here.

The „feature matrix“ thus looks like this:

(1) Not available in ArduCopter 3.6, only in ArduPilot master.
(2) The UC4H Airspeed sensor is not supported by current BetaCopter; there exists a special branch for it however, which is recommended for testing.

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


Supported UAVCAN Messages

The UC4H nodes support a variety of UAVCAN DSDL data types, which are listed in the following. Each node configures its hardware CAN filters to those DSDL messages, which it is listening to, i.e., all other received messages are rejected at the hardware level.

Messages supported by all UC4H Nodes

uavcan.protocol.GetNodeInfo
uavcan.protocol.NodeStatus
uavcan.protocol.RestartNode
uavcan.protocol.debug.LogMessage
uavcan.protocol.dynamic_node_id.Allocation
uavcan.protocol.file.BeginFirmwareUpdate
uavcan.protocol.file.Read
uavcan.protocol.param.ExecuteOpcode
uavcan.protocol.param.GetSet

UC4H GPS-Magnetometer-Barometer

uavcan.equipment.gnss.Fix
uavcan.equipment.gnss.Auxiliary
uavcan.tunnel.Broadcast
uavcan.equipment.ahrs.MagneticFieldStrength2
uavcan.equipment.air_data.StaticPressure
uavcan.equipment.air_data.StaticTemperature
uavcan.equipment.indication.LightsCommand

UC4H PowerBrick

uavcan.olliw.uc4h.GenericBatteryInfo
uavcan.equipment.power.BatteryInfo

UC4H ESC-Actuator

uavcan.equipment.esc.RawCommand
uavcan.equipment.esc.Status
uavcan.equipment.actuator.ArrayCommand

UC4H UartBridge

uavcan.tunnel.Broadcast

UC4H Notifiers: Notify, Display, OreoLEDs

uavcan.olliw.uc4h.Notify
uavcan.equipment.indication.LightsCommand

UC4H IndicatorLED

uavcan.equipment.indication.LightsCommand

UC4H Airspeed-AoA

uavcan.equipment.air_data.RawAirData
uavcan.equipment.air_data.StaticTemperature
uavcan.equipment.air_data.AngleOfAttack

UC4H FunThing

uavcan.equipment.esc.RawCommand
uavcan.equipment.actuator.ArrayCommand
uavcan.equipment.ahrs.MagneticFieldStrength2
uavcan.equipment.power.BatteryInfo
uavcan.equipment.power.CircuitStatus
uavcan.equipment.air_data.RawAirData
uavcan.equipment.air_data.StaticPressure
uavcan.equipment.air_data.StaticTemperature
uavcan.equipment.indication.LightsCommand
uavcan.tunnel.Broadcast
uavcan.olliw.uc4h.GenericBatteryInfo
uavcan.olliw.storm32.Command
uavcan.olliw.storm32.Control
Last edited by mike_kelly; Jan 04, 2019 at 08:19 PM.
Jan 03, 2019, 11:18 AM
Wisconsin
Thread OP
2nd Generation UC4H ESC KISS Carrier Boards installed and tested
23. Nov. 2018

The v1 UC4H ESC KISS Carrier board worked great for me, but it has two design issues. First, it also should be upgraded to the „2nd generation“ principle (see the main thread for an explanation), to make its CAN frontend electrically fool proof. Second, I wanted it to be also able to drive an OreoLED, but the pin which was accessible turned out to be not usable because of a hardware fault in the STM32F103 chip, and the layout wasn’t optimal anyhow. So, here they come, the v2 UC4H ESC KISS Carrier boards. I’ve build and installed them and am flying them since some days. They fully satisfy my expectations .


Last edited by mike_kelly; Jan 03, 2019 at 12:10 PM.
Jan 03, 2019, 11:18 AM
Wisconsin
Thread OP
UC4H ESC KISS Carrier Boards v2 with integrated OreoLEDs
2. Dec. 2018

This is something I wanted to do since about 10 months, since I’m installed the v1 UC4H ESC KISS Carrier boards, namely to operate and drive the OreoLEDs directly from the carrier boards. The main advantage is obviously the massively simplified wiring, and that one UC4H node less is needed. With the v2 KISS carrier boards this now became possible. Doing the firmware was not really difficult since I gladly had essentially all modules at hand, and the synchronization scheme I had in mind, and which is required to keep the OreoLEDs to blink in sync, turned out to work well out of the box.

Initially I thought that I will have to do a special firmware for that application, but gladly I could avoid this. So, the OreoLED support is now part of the „standard“ esc-actuator firmware, v0.22. Available as usual from the UC4H github repository.

Last edited by mike_kelly; Jan 03, 2019 at 12:13 PM.
Jan 03, 2019, 11:18 AM
Wisconsin
Thread OP
2nd Generation UC4H PowerBrick
2. Dec. 2018

Also this was long overdue, the remaking of the UC4H PowerBrick. First, it now also follows the „2nd generation“ guide lines (see the main thread for an explanation). Second, I removed some pin headers from the design which made it slightly smaller. And finally, the 5.3 V voltage is now available on two pin header ports, which is very convenient for powering the flight controller and realizing a more reasonable CAN bus power scheme.

It passed all test flights without any issues. Well, why should there be any, the predecessor I had in use for more than a year without any issues .

Last edited by mike_kelly; Jan 03, 2019 at 12:14 PM.
Jan 03, 2019, 11:19 AM
Wisconsin
Thread OP
Dual UC4H Magnetometer Setup: First Tests
6. Dez. 2018

Since I’ve installed the dual GPS setup about a year ago or so on my flame wheel, I also wanted to use the magnetometer on the second GPS module as an additional external magnetometer. However, at that time back I couldn’t get it to work with ArduPilot. I now decided to look at this again. First, things have progressed since then and it should work now. Also, my current external magnetometer on the first GPS module started to develop a strange behavior in that it wouldn’t startup properly if it is too cold outside (I could proof that beyond doubt). So, I installed a UC4H general purpose board with a second external magnetometer, configured things, et voila:



MAG is the internal magnetometer, and MAG2 and MAG3 are both external UAVCAN magnetometers on node id’s 44 and 80. Calibration was a bit of a pain, but that’s normal for ArduPilot. Otherwise the setup was straight forward.

Clearly, it would be cool now if things would work such that ArduPilot would select the better external magnetometer at startup, and would choose the proper calibration data if one of them should be found to be unhealthy at startup. Unfortunately, ArduPilot itself can’t do that (which is a longstanding complain), so trying to improve that in BetaCopter would be the next step.
Last edited by mike_kelly; Jan 04, 2019 at 06:18 PM.
Jan 03, 2019, 11:19 AM
Wisconsin
Thread OP
UC4H Airspeed v0.3 arrived
6. Dez. 2018

The new UC4H Airpseed v0.3 PCBs just arrived, so I had to assemble two of them. The „new“ feature of the v0.3 board is that it allows installing different differential pressure sensors using a small add-on PCB. Per default it hosts a DLHR sensor, and I also did one hosting an RSC sensor. I plan to do some comparative tests of these two sensors.

Last edited by mike_kelly; Jan 04, 2019 at 07:56 PM.
Jan 03, 2019, 11:19 AM
Wisconsin
Thread OP
Differential Pressure Sensors: DLHR vs RSC Comparison II
8. Dez. 2018

Both the Honeywell RSC Trustability and AllSensors DLHR differential pressure sensors are very promising candidates for application in state-of-art airspeed sensors. I’m interested in understanding better their relative advantages. So, I’ve added support of the DS18B20 temperature sensor to the UC4H Airspeed node firmware, for independent temperature measurement, and built a setup there both sensors are connected to one and the same pitot-static tube. In this first set of experiments I focused on the zero-pressure offset, with respect to its noise and dependence on temperature variations. For achieving different temperatures I put the setup repeatedly in ambient air, in the fridge, and the freezer.

The RSC sensor datasheet provides an autozero algorithm, so the data were taken first without this being done, which shows the „raw“ offset and then with autozero applied. The autozero procedure is not simply an offset subtraction, so it was interesting to see if it does anything.

In the comparison of the data the different pressure ranges of the two used sensors has to be considered. RSC: ±20 inH2O, DLHR: ±10 inH2O (±20 inH2O correspond to ±5000 Pa).

The noise analysis reproduces the findings I’ve obtained earlier here. The temperature dependent results indicate a significantly better offset stability of the DLHR sensor.



Last edited by mike_kelly; Jan 04, 2019 at 07:58 PM.
Jan 03, 2019, 11:19 AM
Wisconsin
Thread OP
UC4H Airspeed v0.4 released
8. Dez. 2018

The v0.3 version of the UC4H Airspeed node PCB is working very well, but I realized I easily could do a minor but significant improvement which furthers its usage range. So I did that, yielding the UC4H Airspeed v0.4 version. The design of this node was a long story now, and went through 5 different versions. However, the v0.4 version I expect to last for quite some time, so I just have released it. The Eagle files and other material you’ll find as usual in the github repository.


Last edited by mike_kelly; Jan 04, 2019 at 08:00 PM.
Jan 03, 2019, 11:20 AM
Wisconsin
Thread OP
Differential Pressure Sensors: DLHR vs RSC Comparison III
13. Dez. 2018

In continuation of my efforts to evaluate the Honeywell RSC Trustability and AllSensors DLHR differential pressure sensors, I’m trying to also get some „dynamic“, actual airspeed data. An article by xDevs.com reported a scale error of ca 5% for the RSC sensor; the DLHR was found to be within specs. Unfortunately, I don’t have the means for reliable measurements. I did had the chance to use a simple wind generator with airspeed meter. It was clear that it won’t be very accurate, but I thought it might be worthwhile to use. I was wrong.

The setup and recorded data are shown below. The DLHR data I corrected by subtracting an offset of 4.85 Pa, and the RSC data by subtracting 0.83 Pa. There is some info in here: The DLHR zero-pressure offset reported some days ago (here) was ~5.4 Pa, which implies a „zero-offset stability“ of ~0.6 Pa. For the RSC the offset was ~0.6 Pa, and now is 0.83 Pa. With that correction, the data of the RSC and DLHR are pretty consistent – within experimental error – which is pretty low here as seen by the huge noise in the data with the wind turbine on. A further point to note is the quantization in the temperature data of ~0.25 K. The resolution of the temperature sensors themselves is much better than that. The 0.25 K comes from the airspeed UAVCAN message, which uses float16 and Kelvin as units; the offset of 273.14 K significantly cuts down the resolution which would not happen with Celsius. This is just another example of the general observation that the UAVCAN messages of the standard DSDL set are very poorly designed. I also tried to „calibrate“ the RSC/DLHR against the simple pitot tube. The reproducibility was some few m/s, but a clear mismatch has to be noted. For two wind speed settings the simple pitot tube was measuring 160-165 Pa and 80-85 Pa, and the RSC/DLHR sensors were reporting 140-145 Pa and 75-80 Pa. Clearly, this experiment wasn’t even close to accurate enough to draw any conclusions as regards the scale accuracy of the RSC and/or DLHR sensors. I need to find a way to do better. LOL.





Last edited by mike_kelly; Jan 04, 2019 at 08:10 PM.
Jan 03, 2019, 11:20 AM
Wisconsin
Thread OP
UC4H AngleOfAttack Node
15. Dez. 2018

The second SPI port on the UC4H Airspeed Node needs some usage, right? So I did this little, quick addition, for the sake of the fun, and because I could. LOL. Thanks to the T-STorM32 project I was already familiar with magnetic rotary encoders, such as the TLE5012B or AS5048A. I had the code pieces and hardware pieces available; I „just“ had to put them together. The result you see below. Please don’t tell me that this is a very crude setup mechanical wise, I know this 🙂 You are welcome to do better. The good message: If you decide to do so, you now get a UAVCAN AngleOfAttack sensor. Maybe I do a test-flight with the AoA sensor mounted on a copter … not that this makes sense, but … it’s fun. LOL.

I guess I should start to consider getting me a plane 😀 😀 … UC4H servos, airspeed, AoA, ESCs …



Last edited by mike_kelly; Jan 04, 2019 at 08:09 PM.
Jan 03, 2019, 11:20 AM
Wisconsin
Thread OP
UC4H PowerBrick: Cell Voltage Support by using a FrSky MLVSS
23. Dez. 2018

One feature which was missing so far was monitoring of the voltages of the individual cells of the battery. I was actually pondering about this for a while, and how a solution could look like. I didn’t wanted to have the required additional electronics on the UC4H PowerBrick board, since it would make it bulkier. So I ended up thinking that if a FrSky lipo voltage sensor (MLVSS or FLVSS) is good enough for many it should be good enough for us here too. The advantage: It is readily available, relatively cheap, folks are used to how to use it, and anyone can decide freely if she/he wants to add this feature or not. Gladly, I had put a solder pad on the UC4H PowerBrick, which I now could use to connect to the FrSky sensor. Also, gladly, I had prepared the uc4h.GenericBatteryInfo UAVCAN message for cell voltage support. So, adding respective code to the PowerBrick firmware and the BetaCopter code wasn’t very difficult. And this is the result:





One disadvantage of the FrSky sensor is that it is very slow. For a 3S/4S cell it provides a new data set only every 0.6 s. However, it’s main purpose is to detect battery issues, and this should be good enough, right? And after all, this is the same sensor everyone is using so happily ��

I am of course planning to design a new PCB for the UC4H PowerBrick, which offers a FrSky S-Port port. I in fact started already, but this will take time LOL.
Last edited by mike_kelly; Jan 04, 2019 at 08:13 PM.
Jan 04, 2019, 08:46 AM
KD2PBU - Fly No Evil
davidbitton's Avatar
You taking over for OlliW?
Jan 04, 2019, 10:03 AM
Wisconsin
Thread OP
UC4H Mavlink-Bridge: First working Prototype
30. Dez. 2018

Another feature which was badly missing is the possibility of configuring the UAVCAN nodes seamlessly in a user-friendly way with „ArduPilot tools“, i.e., without the need to connect an extra SLCAN adapter and use special software, such as the UAVCAN GUI Tool. I’m not claiming to have solved that completely now, but this might be a significant step forward.

As regards configuration of parameters, a solution has in principle been defined several years ago as UAVCAN-MAVLink bridge, see here (and it appears to be implemented in PX4 since 2016). As usual with UAVCAN, ArduPilot is behind, and doesn’t have anything of this. Interestingly, MissionPlanner in contrast has already some support!

In principle, the MAVLink bridge should be part of the ArduPilot code, but this I couldn’t yet achieve. However, I could do it with a „piece of on-board equipment“, such as a general-purpose UC4H node. As usual with UAVCAN, the UAVCAN messages have not been well designed, which results in some not-so-nice issues code-wise and makes it trickier and more resource-hungry than needed. I guess I’m going to add my own UAVCAN messages. Anyway, a first well-working prototype I have now completed:





Finally, I have to say that I’m not convinced that the UAVACN-MAVLink bridge concept is the final answer. An alternative approach would be an integrated on-board SLCAN adapter, which would decouple the development of the UAVCAN configuration tools from the ArduPilot development, which would be much more efficient workload-wise and likely would give the user much better tools. I guess I’m going to try this approach too.
Last edited by mike_kelly; Jan 04, 2019 at 08:15 PM.
Jan 04, 2019, 05:15 PM
KD2PBU - Fly No Evil
davidbitton's Avatar
Quote:
Originally Posted by mike_kelly
Too important to let it die here. OlliW is not slowing down with this project.

I think OlliW's new MavlinkBridge is major new benefit. Control of setting params and viewing values from right inside Mission Planner.
I thought he washed his hands of all of this.


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Mini-HowTo DIY UAVCAN: STM32 (F1, F3) step-by-step MGeo DIY Electronics 28 Jan 29, 2019 09:15 AM
Cool Uavcan for Hobbyists OlliW Multirotor Drone Electronics 918 Dec 02, 2018 03:51 PM