This blog reports on the progress of the UAVCAN for Hobbyists (UC4H) project.
13. Jan. 2019
UC4H MavlinkBridge v0.06:
• Initial release of firmware for the UC4H MavlinkBridge. Use MissionPlanner beta.
UC4H Gps-Magnetometer-Barometer v0.27:
• Baudrate for GPS mode (gnss.Fix) changed from 57600 to 115200
• Support for QMC5883 magnetometer added
UC4H PowerBrick v0.10:
• Support for FrSky Lipo Cell Voltage Sensor. Use MissionPlanner beta.
BetaCopter 3.6.4 v017u:
• Based on Copter 3.6.4.
• Battery cell voltages support for UAVCAN/UC4H battery monitor (DataFlash, Mavlink).
• Report of detected and usage of compasses to improve user experience.
Firmwares as usual in the github repository: https://github.com/olliw42/uavcan4hobbyists
UC4H Mavlink-Bridge III
12. Jan. 2019
I was trying to convince MissionPlanner to show parameter information, such as range or description, also for the parameters of the UC4H nodes. It unfortunately was necessary to modified the UC4H MavlinkBridge such that it replaces all blanks in the parameter names by _. The good thing: By copying some info into MissionPlanner’s parameter meta data file it indeed shows now the descriptions. I actually find this of great help, since one doesn’t always have to memorize or look up what is what. Very useful. The bad thing: The parameters are now also organized into sections, which I don’t like much. So, my opinion is a bit mixed on this. I really would wish that MissionPlanner would provide some better means to present UAVCAN node parameters. But for the moment that’s the best we can get, I guess. 🙂
UC4H Mavlink-Bridge II
2. Jan. 2019
The UC4H MavlinkBridge has matured. It now also has passed flight testing, i.e., is ready for prime time. A short demo video:
Many thanks to Michael Oborne, the MissionPlanner maintainer, for having swiftly added some UAVCAN Interaction features to MissionPlanner. Thx, sir!
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.
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.
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 …
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.
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.
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.
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.
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.
2nd Generation UC4H PowerBrick
2. Dez. 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 :).
UC4H ESC KISS Carrier Boards v2 with integrated OreoLEDs
2. Dez. 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.
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 :).