CANbus Quadcopter using UC4H : Son of FrankenSolo

UC4H: Finishing the notify Display

I used the UC4H Notify display as an example of flashing the firmware to a General node now I’ll just finished up that project. The UC4H is similar to the Ardupliot status display. It is really useful to get some important information before you fly without having to haul around a ground station. It is particularly important to have a good GPS lock before you fly with Ardupliot and a simple LED on your GPS indicating a 3D Lock is not adequate. The Notify display gives you the number of satellites you are using and the quality of the signal. It also has a ticker tape line that gives you the messages that you would normally have to get from the message tab in Mission Planner. It will tell you what your battery voltage is and all in plain text rather than having to decipher sequences of blinking lights or musical tones.

The notify display using a cheap and commonly available SSD1306 .96" OLED I2C module. Becareful to note that these modules can look identical from various vendors but instead, stupidly, have the power and ground pins reversed from manufacturer to manufacturer.

There are case designs in thingiverse.com for the SSD1306 you print or get printed to finish up your display.

There is a bigger 1.3" display that OlliW does now support. In the UAVCAN parameters for the Display Node set Display Type =0 for 1306 based or =1 for SH 1106 based displays.

In addition the UC4H Notify Display node offers a indicator LED option extending the built-in Pixhawk indicator led to the location of your choice. I put my indicator LEDs inside my HERE converted GPS with my UC4H GPS node. The display node supports standard RGB WS2812 LED strips, cut down.

The UC4H Notify display does not require any changes in Arducopter parameters, it just works! But the Indicator LED option on the UC4H Notify display requires a parameter setting.
In Mission Planner to activate the Indicator LED, set the NTF_LED_TYPES=33 for The UC4H the internal led and the UAVCAN UC4H Indicator.

1 Like

UC4H: adding dual GPS

Adupilot is heavily dependent on GPS for accurate position information. It uses position information for all the various modes that set it apart from other flight controllers. Auto missions, loiter, position hold, follow me etc etc all require a great GPS lock to function. Ardupilot has made great strides in recent years by implementing dual GPS capability and allowing the evaluation of the GPS signal quality and switching to the best GPS or blending the data from the two GPS. It brings greater reliability to Ardupilot.

In my first FrankenSolo I used a UC4H GPS node to convert a Here GPS to UAVCAN. This conversion caused the Here GPS to send out UAVCAN messages with GPS information to the CANbus. In the second generation UC4H OlliW has implemented a new message type that is a tunnel to send serial data to the Pixhawk. The new message has raw serial data as a payload and allows any serial device to create a tunnel to deliver that data to the Pixhawk without creating special UAVCAN messages for every serial device. So I am replacing my old UAVCAN node with a new general purpose node with the GPS/MAG/Baro firmware. The GPS data uses a serial_TUNL to get its data to the Pixhawk and the compass and or barometer send their data through normal UAVCAN messages.

There is also a general purpose node firmware to provide nothing but serial tunnels. The firmware is called the UART Bridge is used to provide extra serial ports to the Pixhawk from about any serial device.

I then took apart my Here GPS and replaced the original node with a new UC4H GPSMagBaro node.

One extra feature is that the node can support an indicator LED using the RGB strip leds. I chose two and put them in the Here GPS replacing the ones that the HERE normally supplies.

The general procedure is to get your general purpose node and download the UC4H firmware from OlliW github repository . Using your SLCAN connect to the Node and your USB connection to your computer. Use UAVCAN GUI tool to update the firmware on the bare node. When it finished the node name will change from “bootloader” to GPSMAGBaro. Now you can choose which combination of GPS/MAG or Baro you want. OPen the node in UAVCAN GUI and fetch the parameters. At the bottom of the list is the node configuration parameter which is a bitmap. GPS is a 1, MAG is a 2, and Baro is a 4. If you leave it at the default= 0 all the GPS/MAG and Baro are active. IF you set it to 1 it is GPS alone and if you set it to 4 it is Barometer alone. A 3 would configure it for GPS and MAG etc. Then save the setting and reboot.
Next open the node again and assign it a unique node ID and set the Channel_ID to match the node ID.
Now connect your standard M8N GPS using the connection chart.

Next there are a few parameters in Betacopter to set.

In the full parameter list in Mission Planner, right after the normal serial devices, you will find serial_TUNL0, Serial_TUNL1, and Serial_TUNL2.

Here you tell Mission Planner what node ID is “connected” to this tunnel and what the baudrate is needed and finally what the serial tunnel is used with. For a GPS the node type is 5 for instance. For my GPS I have node_ID’s 50 and 51 at 115 baud and type 5 each node using serial_TUNL0 and serial_TUNL1.

Set the GPS_Type to 1 for auto or in my case 2 because I know my GPS use the ublox chipset.

Done. Dual GPS via UC4H UAVCAN!

For more detailed information about using UART tunnels to add serial ports to Pixhawk see ppoirier excellent article:

1 Like

The continued epsiodes of the Son of FrankenSolo build. Using Olliw’s UC4H and a 3DR Solo surplus motherboard to create and advanced DIY quad.

I have gotten the UC4H powerbrick, UC4H ESC’s, UC4H Display Notifier and UC4H GPS/MAG/Baro installed. Kinda the required basics to get flying.

Now for some frosting on the cake. I have wanted to experiment with a downward facing sonar since the APM days but the sensors available have always been marginal or quite expensive. The old HC-SR04 did not do much. The Maxbotix had noise isssues to deal with and the true LIDARS were in the hundreds of dollars.

For low altitude measurements Pixhawk depends on it’s barometer. But the Barometer senses air pressure and that changes with the weather. So adding a better sensor for low altitude height measurements could improve landing and AltHold flight mode.

The new kid on the low altitude sensor block is the Benewake TFTmini LIDAR. It is not a true LIDAR (Light Detection and Ranging) because it does not use a laser. It instead uses a less costly LED light. But it seems to work well and is moderately priced at around $50.

OlliW took advantage of this new sensor and added it to UC4H. The UC4H Rangefinder. It could use the UART Tunnel technology but it is easy to setup and use as a UAVCAN device or the generic mode.

First install the UC4H Rangerfinder firmware on your General Purpose node.[/SIZE] using the UAVCAN GUI tool. Choose a unique node ID and leave the Channel ID=-1, to use the UAVCAN mode for the node. RangeRate> 0 sets the node in the generic mode.

Mount the TFTmini so it has a clear view of the ground.

In Mission Planner goto the advanced Parameter list and the category RNDFND.

RNGFND1_TYPE=83 sets the rangefinder to UAVCAN/UC4H

You must set the RNGFND1_MAX_CM= to a reasonable and low height so that the limit of the Rangefinders accuracy is not exceeded, like 700cm which is about 20ft. Above that the Pixhawk will switch back over to using the barometer.

You can check to see if your Rangefinder is working by taking a look at the status tab (under the HUD in Mission Planner) the parameter Sonarrange will change as you move the quad up and down.

Now time for a nice soft landing!

2 Likes

fantastic!
as I might have written somewhere else, the moment I did install the TFMini UC4H Rangefinder I was in “love” with it. IMHO a must-have addition.
great that you’ve added it and that it was easy to get it running

UC4H: Mavlink Bridge, bringing UC4H to Mission Planner

Like most things CANbus Ardupilot is a little behind the game. We have come a long way on this project from setting up power, installing the ESC’s, adding GPS and Mag, getting information from the Notify display and adding the rangefinder for more accurate altitude measurements. The SLCAN tool and the UAVCAN GUI software has given us a great way to monitor data on the CANbus and configure our can devices and troubleshoot. It still allows us to troubleshoot those devices even buttoned up inside the multirotor. We get an unprecedented view of what is going on inside the quad in real time instead of waiting until the flight is over to review the logs. With UC4H we know what the rpm of the motors are and what the temperature of the ESC’s is at. We know how many satellites we have locked and that the EKF2 as initialized as examples.

But some of use grew up using Mission Planner and with all the benefits of UAVCAN GUI it would be nice to integrate Mission Planner and UAVCAN. So OlliW developed a way of linking Mission Planner to the CANBus and allow us to connect with CAN devices on our multirotor just like connecting to the flight controller and downloading the parameters. With the UC4H Mavlink Bridge we can get our CANbus information right in the Parameters with all the other aspects of the flight controller we configure.

http://www.olliw.eu/uploads/uc4h-mav…mp-gui-v01.jpg

The UC4H Mavlink Bridge sits on the CANbus and connects to the Pixhawk via a serial connection. It is created using our multipurpose General Node. So simple and so powerful.

All good things come to and end and so it is with the Son of FrankenSolo. What a fun project.

I built a gimbal for this project using OlliW’s STorM32NT gimbal controller. OlliW has provided excellent compatibility with Ardupilot and your choice of connection methods. You can use PWM, Sbus, Spektrum or serial connections between the flight controller and the gimbal. You can use Mavlink or OlliW’s own STorM32 mode serial. Lastly you can use native mode STorM32 as I did which is a serial connection and the Betacopter branch of Ardupilot which includes OlliW’s improvements for his gimbal. Native mode has the richest set of features.

I was unhappy with all the Nex sized gimbal frame kits I bought. Some the adjustments on the axis were not long enough to properly balance the camera. If you can’t balance the gimbal it is game over no reason to continue. Some I did not like the way the anti-vibration plate worked. In my opinion the rubber anti-vibration balls must be in compression. This means the yaw motor must attach to the top plate of the anti-vibration platform and not the bottom. It is critical to stop vibrations from the multirotor affecting the video. Next I want the cables to be dressed neatly and not floppy around in big loops. This means using hollow shaft motors and running your cables through the center of your motors. You can’t have gimbal balance if your cables change position as the gimbal moves around. As OlliW pointed out to me you can’t have the cables going through the motor jam up and cause the motor not to rotate freely, however. It seems appropriate for the Son of FrankenSolo project that I build a FrankenGimbal from all my gimbal kits acquired over the years. I was able to cherry pick the parts that worked for me and finally build a gimbal I was happy with.

So one of the most difficult aspects of building a gimbal is the management of cables. That is one advantage of OlliW’s NT gimbal system because in the distributed motor module version, which I did not use, the only wires going to each motor are the NT bus which is tx, rx power and ground with power to the motors for 5 wires.

The most difficult of the whole project is getting control of your camera. You need to get video from the camera up to transmit to the ground and you need whatever control you want to trigger or zoom etc your camera. This is a good reason to consider these factors before you decide on a camera.

The camera and gimbal is a major payload for the multirotor and never forget that every gram counts. A heavy gimbal and camera can instantly weight down your multirotor such that you end up with 5 minute flight time. Don’t forget that adding battery power to get more time is a lost cause. You end up adding battery just to lift the new battery you added with no change in your flight time.

It is a complete system and when you design a multirotor you need to consider the payload right from the start.

I am using a Ricoh GR because it produces high quality images and it is lighter than most camera in this size class at 245grams. The gimbal wound up weighing 505grams. The AUW weight is 4000grams with the 10500mah TItan LI-ION battery.

I love using the Solo motherboard for DIY projects. I have the Solo Controller running Solex on my Tablet with video from the Son of FrankenSolo displayed on the tablet. But for actual flight I will use my goggles. I just can’t see the tablet display in sunlight. Solex has voice commands which is nice. The only thing better would be OlliW’s new Pixhawk cube carrier board with the Sololink IMX6 board piggy back.

I like the lights on the quad. WIth OlliW oreo lights the status of the quad can be easily seen and my Flytron Neo light strips are a lifesaver for me. I have a real hard time determining direction of the aircraft in the air and the neo lights have a running white light that moves toward the front of the aircraft, pointing me to the forward direction, red lights on the right and green lights on the left rear of the aircraft help determine orientation.


Using OlliW’s UC4H via UAVCAN has been easy to build and easy to troubleshoot. It is a complete system now with a general purpose CANbus node, available off the shelf from JDrones, that can connect all your existing peripherals to your multirotor on a robust common bus.

Now the final step to see how it flies and determine the flight time.

2 Likes

Great project, thank you for sharing!

I would like to use a Ricoh GR for my next copter too and I wonder how you trigger it. Would you share any information about that?

My attitude is that with the size of SD cards these days why would I bother triggering it? The Ricoh Gr has an intervalometer function built-in. SO I can set it to take a shot every 1 sec and just pause over a subject for 1 sec. For video just start it when you take off.

Now if for some reason you don’t like that answer you can use a Gentles trigger cable #122 (https://www.gentles.ltd.uk/gentwire/videousb.htm) to control shutter and video out.

That is what makes the Ricoh GR a good aerial camera.

1 Like

Thank you! I think it saves a lot of work if you do not have to sort out all the pictures you did not want to make.

Gentles seems to be another Brexit victim… . We will see whether it is still possible to order there from Germany when I will build my Ricohpter. Its a shame.

Also VP-Systems makes camera triggering gear.
http://vp-systems.eu/camremote.html

1 Like

UC4H: Son of FrankenSolo Maiden

I got a chance to maiden the Son of FrankenSolo in between rain storms this afternoon. Yes OlliW I removed the gimbal :slight_smile:

All I can say is WOW. It was so smooth with no tuning at all. Very precise control. No jumping around. Unfortunately I had a “Bad Loggin” problem which looks like an on-going problem with Arducopter. I turned down the logging and the log buffer on the IO heartbeat and BAD logging errors are gone. But I will have to do my basic test again to get logs to check the vibs and battery usage trends. I can’t wait to take it up with the gimbal.

https://www.youtube.com/watch?v=bpyh84oJLhk

very cool, congrats!!

I’m glad you find it to fly so well. Let’s hope you get the log done … and be ale to convince yourself of all the goodies you’ll find in there thanks to UC4H and betacopter :smiley:

one “complain” however: the OreoLEDs are hardly seen :smiley: :smiley: :smiley:
you could have made them big LED-strips too and replace your others (it currently supports 10 LEDs per strip, it would be easy to adapt to more however)
just joking :slight_smile:

I guess with a UC4H Cube IMX6 carrier the build would be even slimmer, cleaner and simpler
… the race would then be open who does the “Ultimate 3DR brain transplant” first …

I could not see the Oreo Led’s if there were ten! That is why I need those Flyron strips and even those when it gets up high can’t be seen. I was disappointed that the logs did not work because I did want to see all the detailed info on battery drain that UC4H offers etc.

The UC4H Cube carrier would be my ultimate build. I would never make another aircraft that I have to take to whole thing apart to get at something like I will now have to do to work on the sd card/logging problem. The UC4H CUbe carrier is small enough to put a “hatch” in the top plate to access the interior without taking the top plate off, thereby releasing all the arms etc. A real pain. The other real advantage is that the USB cable and the HDMI cable can not be installed at the same time on the Solo motherboard because they block each other.

But if my gimbal works that will be satisfiying given I have been working on building a good gimbal for many years/

I could not see the Oreo Led’s if there were ten!

well, they might not be as bright as the Flytron strips, I really can’t tell, but I’m surprised you find the OreoLEDs that hard to see.

I suspect there must be something wrong. I do have 5 per each arm and use 50% brightness, and you can check yourself in that video how bright/lame they are: https://www.youtube.com/watch?v=x2qrssv0e8s (start at 6:30).
You power them from 5V, not 3.3V, right? Are yours WS2812b or WS2812 (without the b)? (according to the data sheet they have somewhat different timing, maybe a reason)

EDIT: I just googled Flytron strips, and found this: https://flytron.com/led-light-systems/300-strobon-neo-4-stripes-pack.html. If that is what you use, the OreoLEDs should be as bright as them, since these also use the WS2812B, and 10 of them per strip!
That is, you could connect these strips to the KISS escs instead of your single LED, and they all should light brightly …
… this makes me think even more that something is wrong with your present OreoLEDs

I don’t think there is anything wrong. The single units are quite visible, even in daylight. But I am slightly color blind so I never use colored lights as indicators because I can’t easily tell the difference in the colors. That is why I like the Notify Display so much because it tells me in text what the status is rather than blinking lights.

The Neo are there to help me tell orientation which I have a really hard time with. My eyes also don’t work in “stereo” that is why I can’t solder the little tiny encoder wires because even at 10x I can’t tell when the wire is right next to the pad or above it.

I’m still a bit puzzled what the story is.

In the video the Neo/Flytron LEDs come across sooo much brighter than the OreoLEDs, that I understand that one would not prefer them.

However, as much as I can infer from that Flytron web page, the Neo/Flytron LEDs are also just WS2812B, i.e., exactly those which are supposed to be also used for the OreoLEDs. Thus, there is no reason why the OreoLEDs should be sooo much dimmer than your Neo/Flytron LEDs. Both should be equally bright.

It is even better than that. The UC4H KISS Esc carriers came with servo wires for connecting the OreoLEDs, didn’t they? From the picture on the Flytron webpage I infer that the Neo/Flytron LEDs also have servo plugs. So, you should NOT have to do ANY soldering to connect them to the KISS ESC carriers. From the web page I infer that they even have the correct pin sequence. Hardly can be simpler, I would argue. Especially no soldering needed.

From your video the Neo/Flytron appear to be green and red with some sweeping white lights. The OreoLEDs are also red, green, and white. I’m thus not sure I understand the color argument.

Sure, the OreoLEDs are there for indication, but not only for this! Once in air, they are also there to tell the orientation … as the Neo/Flytron do !!

So, I conclude: The OreoLEDs should be as bright as the Neo/Flytron are, they use the same colors, and they tell orientation as much as the Neo/Flytron do.

That’s what I observe by comparing. And that’s all what I’m saying :slight_smile:

I don’t know what the brightness level on the Oreo lights is set at. IT might be low power when I was testing on the bench. It is the sweeping white light that is important with the NEO strip. I even wrote Flytron and asked them to add a mode where the background lights are off to save power. The sweeping white light “points” forward. Which the Oreo lights can’t do.

In my case I can’t swap them even to play. The connector for the Flytron is in the center of the frame and the connector for the Oreo is at the end of the arms.

I got a chance to maiden the Son of FrankenSolo in between rain storms this afternoon. Yes OlliW I removed the gimbal :slight_smile:

All I can say is WOW. It was so smooth with no tuning at all. Very precise control. No jumping around. Unfortunately I had a “Bad Logging” problem which looks like an on-going problem with Arducopter. I turned down the logging and the log buffer and the IO heartbeat and BAD logging errors are gone. But I will have to do my basic test again to get logs to check the vibs and battery usage trends. I can’t wait to take it up with the gimbal.

https://www.youtube.com/watch?v=bpyh84oJLhk

I finally got the logging issue taken care of for SOFS. IN the latest versions of Copter firmware there is a new Log_Backend parameter. Because the Solo has a co-computer it can, and defaults to, copying the logs to both the flight controller and the co-computer which does not appear to work right. So I changed the parameter to 1 which uses only the flight controller as normal.

Vibrations
I was really pleased with the vibration charts but it is not surprising given how well the quad flew in it’s maiden flight. In the old graph of vibrations acceptable is -3 to +3 for the X and Y axis and -5 to -15 for the Z axis. SOFS is recording values for X and Y of less than .3 to .5 and Z axis vibes just as low. I included the barometer graph right below to show it really was flying during the vibration plot.


I was concerned, and still am, about the battery. It is a 10.5amp Titan LI-ION battery. It has much higher energy density than a equivalent LI-PO but it is limited in it’s discharge rate. Think real low C, like 3C. But the battery power graph looks good. It shows about 360w and around 16amps. But this is without the load of the gimbal. So I will have to see how it does on the first gimbal flight.

So far so good. Now to test the quad with full gimbal load.

1 Like

I am relieved to find that with the gimbal attached the Son of FrankenSolo flies just as well as without the gimbal. I am disappointed to find that the logs once again not available. So I can’t compare the power usage and determine if it is within the “C” limits of the battery. I am pretty confident that it will be fine but I am not going to do a flight time test until I know for sure. I am not willing to let the battery fail half way through the test.

I started out on this journey in 2012. I knew nothing about RC and RCGroups.com was pretty intimidating. I could not believe how many forums about so many different RC vehicles there were. I wanted to do an abstract photography portfolio that I needed an aerial view to do. I got a delta wing kite kit that was and is a very nice plaform but I needed to hover rather than fly to get what I wanted. I gave up until I saw an article about the new DJI Phantom in late 2013. I got excited about it like everyone and his brother. Until I realized it could only carry a gopro. But that was the beginning. I built my first DJ450 afterward. The first flight it shot up about 40ft and came tumbling down out of the trees out of control. It took me a full 4 months to figure out that the pitch in mission planner radio cal moved the opposite of every other stick if setup correctly. I built a dozen more aircraft over the years. I have a drawer full of half finished gimbals.

So this is a significant point for me. Only took me 6 years and a LOT of reading on RCGroups to get here.

Many thanks to the generous members that spend their personal time helping others all over the world to better enjoy this endeavour.

So here is the maiden flight of the Son of FrankenSolo with it’s STorM32NT gimbal attached. I really don’t have any way of evaluating the video. I have never gotten video this good to critique. It is not perfect but at this point I am not sure what is due to the camera or my older computers playing it or gimbal. It really does not matter because it is the best I have ever gotten.

https://www.youtube.com/watch?v=zc5-0Nl7bmk

1 Like

Matthew, OlliW has shared really three different ways to play with UAVCAN. You can make all of his UAVCAN UC4H adapters with simple “Blue Pill” STM boards. Jdrones has produced finished General nodes which can be used for all of his different UAVCAN pheripherals. Lastly he has custom boards, that do the same things, like the ESC Kiss carriers or Rangefinder boards that just make a cleaner more finished look but run the same firmware

The AUW is heavier than I wanted at 4000grams. The landing gear is part of that extra but I really like them. In typical fashion they turned out to be a thin carbon layer on the outside and fiberglass on the inside. The gimbal turned out heavier too at 500g because I started with carbon fiber gimbal and found I could not balance the Ricoh on the platform the way ti was designed. I really wanted to use the Ricoh because it is only 250g which is considerably lighter than a similar Nex.

It is always a battle to get your weight under control and still have the features and the flight time. Every gram counts.