Update on Mastering Solo... Major milestone reached

Here’s an update on the progress being made to get Solo working with ArduCopter master. Or as it has come to be known: solo remastered, mastering solo, or solo masterbeta. :slight_smile: Everything below is has been done and tested by myself and many great beta testers over the last 2-3 months. The beta testing facebook group has been very active with daily posts and feedback. And it’s been an ArduPilot dev call topic for several weeks now. It’s been lots of fun!

Today I think we’ve hit a major milestone. Ibelieve everything that needs to be solved has been solved! The bugs have been squashed and features have been modified. One PR remains to be evaluated and merged by the dev team into Master. Once that PR gets merged in, the Solo will operate on ArduPilot master without any special custom build.

  • Solex GCS Android Application Integration: I’m putting this first because it a pretty epic game changer for users. The Solex app has been around for a little while now. It is a constantly developing and improving Android app by @kellyschrock that quickly overtook the 3DR app as the thing to have. But the app’s creator happens to be a fan of this project, and is participating in the beta testing. As such, he has been building out functionality in his app to work with ArduPilot features. For example, just this weekend he built a one-touch method to download and install firmware and companion computer files. This turned a complex user process into one click. He also integrated the smart battery serial number to automate battery logging.

  • Motor slew rate: The stock solo has this slew rate handicapping on the throttle output. This was put in by 3DR as a software workaround to the hardware voltage problem in the motor pod ESCs. Voltage sags from high rate of change would cause the motors to shut off, which is obviously not good as the photo below shows. By limiting how fast the throttle output could change, it mostly prevented the ESCs from cutting off in flight That is how every stock solo operates. However this comes at great sacrifice to the Solo’s throttle response. ArduCopter master does not have this code. Therefore, you need to use a proper hardware solution to the hardware problem. If you’re using stock solo motor pod ESCs, you really need to be using the @proficnc green cube Pixhawk 2.1. This uses 5v signalling, which completely solves the ESC issue. Your solo will not look like the one pictured below. The other solution is to use different ESCs, but this is really only applicable to do custom build. Eventually we would like to being the slew rate code into master, using a parameter to enable/disable it. That will allow all Solos to use master without hardware changes. But we’re not quite there yet.

  • Return Home “Smart Shot”: The Solo as designed handles return home differently than standard ArduCopter. It has a “smart shot” called Return To Home on the companion computer. It used this instead of the RTL mode in ArduCopter. It was clear this was intended to be a little more special than it was. But 3DR gave up on the Solo before this smart RTH was really built out. So as it was, it didn’t do anything differently than ArduCopter’s standard RTL. As such, it was really just an added layer of complexity and a significant point of failure. As failsafe, this was actually make things worse, not safer. I serious flaw was also found in it. This flaw was masked by the slew rate throttle handicapping, so it was barely noticeable on a stock solo. But with the slew rate handicapping (thankfully) removed the throttle could respond much faster and this flaw reared it’s ugly head. It was causing the throttle fluctuations and cut outs. The whole thing got very unstable. So the easy solution to all of this was to just not use it anymore. Any circumstance that used to call the Smart RTH, not simply changes modes to ArduCopter RTL. This includes pressing the home button, battery failsafes, radio failsafes, mission commands, etc. ArduCopter’s RTL mode is rock solid, tried, and true, very safe.

  • Home location setting: The solo’s companion computer needs to know what the vehicle’s home location is for a number of its functions. The method it was using did not work in ArduPilot master. It was looking for mission waypoint zero, which is home location. But if no mission was loaded, WP-0 was empty. All the companion computer functions and smart shots that relied on knowing the home location were bombing out because of this. @peterbarker quickly found this problem and changed the WP-0 handling to allow it to retrieve home at any time.

  • Pixhawk Bootloader: The old stock version of px_uploader.py was replaced with the latest version. The new version allows the companion computer’s WiFi to connect before and during bootloader. So if you accidentally did something that locked it up, you can still connect by SSH, WinSCP, Filezilla, etc. This proved highly useful in experimentation here!

  • Smart shot yaw: It was found that in numerous smart shots, the copter yaw was not responding. For example, in cable cam, the copter yaw never changed and in zip line and follow, the free look functions didn’t work. This appears to be a problem in ArduPilot rather than the Solo’s companion computer. The smart shots were using the msg_mount_control mavlink message which should control copter yaw and gimbal pitch. But only the gimbal pitch was working. I tried having it use the newer mav_cmd_do_mount_control mavlink command and the results were the same. I fix has not been identified in ArduPilot yet, but I needed to get the shots working. So I modified the smart shots to use condition_yaw to control the copter yaw component. This worked nicely. The old message controls the gimbal pitch as always, and condition_yaw handles the yaw. This got all the smart shots working in all respects!

  • Smart battery integration: ArduPilot master had a variation of the smart battery code, but it was somewhat stale and not working. A few of us found out the hard way it wasn’t working when batteries were going dead but reporting 10-20% still. Yay test piloting! It just so happened at @WickedShell was beginning some smart battery modifications a plane project. He was kind enough to take on the Solo’s smart battery at the same time. Not only did he get it working, but several new features were baked in. We now have individual cell voltage, pack temperature, and serial numbers being read from the smart battery. This information is reported the GCS and logged in the dataflash logs. This allows detailed battery analysis and tracking with no other parts or applications.

  • PID Tuning: Normally if you’re not changing airframes, motors, etc, you don’t need to redo the tuning. Even though ArduPilot made some changes, those changes were automatically accounted for in the firmware update process. So tuning would on any other day be a non-issue with nothing to do. However, once the slew rate throttle handicapping was removed, it changed everything. The throttle response is completely different (for the better). It was overshooting and generally drunk. So this required all three axes to be retuned. Beta testers Kelly Schrock and Dustin Fickert were kind enough to spend some time on both autotuning and manual tuning. The latter is a pain without a conventional RC remote, so that effort went a long way! The end result is some rock solid PIDs. No more overshooting and Solo is no longer a drunken sailor.

  • LEDs: The Solo uses RGB LEDs running OreoLED on each motor pod. These have a fairly large driver file, and the Solo is the only vehicle that uses it. The driver was enabled/disabled on compile only, just like the tones. This driver can’t be enabled for all vehicles by default because not all boards have enough memory. So it was off in master, and the LEDs were solid green at all times no matter what. So again the only way to make the LEDs work properly was to run a custom build with the driver enabledenabled. This was not an easy fix like the tones were. Reworking the entire notify device handling was over my head too. Thankfully @jmachuca77 dedicated some of his time and effort into this. He did the major rework, allowing notify devices to be selected by parameter NTF_BRD_TYPE. After Jaime did that, I made some additional modifications to it related to the Oreo LEDs. There is now a parameter called NTF_OLED_THEME. This allows the OreoLED driver to be disabled (0) by default and not waste memory. Setting it for 1 gives you a new aviation standard lighting theme I created while I was at it. And a setting of 2 gives you the stock solo automobile type theme.

  • Tones: This was an exercise in simplification by elimination. The solo had it’s own unique tones (beeps and buzzers) compared to a standard ArduPilot equipped vehicle. This was enabled/disabled on compile only. So the only way to get the Solo’s unique tones was to run a custom build with them enabled. After comparing the Solo’s tones to standard ArduPilot tones, we decided if it’s running ArduPilot, it should sound like ArduPilot. So the Solo’s specific tone files are being eliminated entirely. The power off tone was merged into the standard px4 tones file.

I’ve been waiting until it seemed a bit more stable, but I’d be interested in testing this out.

I need something to do anyway.

Is there a wiki or something? I got lazy and skimmed the full post, this works on stock Solo PH2?


Please read the second bullet point on the slew rate. You cannot safely use a stock Pixhawk 2. It will work, but it is not safe.

Must have been the part I skimmed over.

Tempting but in no way worth the cost of the Cube. I can wait till it’s working on the factory, or I’m fine if it doesn’t : )

Just figured I’d pitch in if I could.


What is not worth the cost of the cube?

Lance, Green Cube was sold at a discounted price, but given what the Cube is and does, and the range of vehicles, and the size/cost of such vehicles, the value is only questionable if you’re only ever going to fly your first Solo and not for very long.

At least in my mind, given the other vehicle types and advanced features, a Cube is a tightly packed box of awesomeness that is valuable and useful far beyond Solo, but exciting enough in what it brings to Solo in ArduCopter alone to justify a couple naked cubes for Solo carriers today. Then when I eventually, statistically destroy one, I’ll still have a platform that could drive most anything!

great post, worthy of being a blog post on ardupilot.org I think (you could do that by changing the category to “Blog”)

Thanks Randy. I changed it to Blog and it does indeed show up there now.

can we have some more information here on exactly what is the is the problem with voltage/throttle fluctuation , that the green cube (no longer available) is supposed to solve ?

  • or what exactly is the difference between the green cube ? (does it output 5v PWM instead of 3v3 ?)
    I would like to create instructions for a different fix, depending on where/what exactly the problem lies, we could up the wire gauge or add a level converter to ensure safe operation.
    Creating cheap DIY fix, would make more people fly safer, with or without slew rate.

Where do you see it no longer available?? It is in stock still. http://www.proficnc.com/3dr-solo-accessories/79-the-cube.html

The green cube is hardware wise no different than a normal Pixhawk 2.1 from ProfiCNC. What makes it “for the Solo” is that the internal jumper is pre-set for 5 volt signalling instead of 3.3 volt signalling. And it’s green to make it obvious which one is which.

ok, so - the Green cube is the same as Pixhawk 2.1 , with a internal jumper (I guess a solder blob) - to provide 5v PWM (or other signals as well ?)

if PWM is the whole issue here, then I could publish a DIY solution, after all, we have seen that people are reluctant to buy a new one for this, and as long it improves safety, it is good if more do fix that issue one way or another.

Can you confirm that the whole issue is about PWM level only ?

I’m all for Andre-K’s idea.

I have lots of spare parts, electronic components, etc.
I can hack in a logic converter, or a power supply, or pop it open and solder a jumper, or a cap or diode or whatever…add whatever component is required - if it’s possible. I’d even help with the instruction to do so.

My issue with cost, is that I have a perfectly fine, stock factory Solo.
I don’t much feel like paying 170 US to test, and waiting 2 months for the thing if I did.

I guess in the end, I’m hoping the intention for the Solo on Master project doesn’t require us to do so. If that’s the intention, I’m thinking you have a pretty small group of people you’re doing all this work for, but that’s my opinion

If the intention is to actually use the stock PH2, even if a bit of DIY work is required I’m thinking you’ve got a good amount of folks who’d be willing to use it.

I’ll willing to help anyway I can, I’ve been putting my craft at risk, and on more than one occasion, crashing them, for a bit of time now. That’s not my issue.

I can’t contribute much otherwise, and there doesn’t appear to be a large amount of people willing to risk it.
I’m happy to do it for what I’m receiving out of it. Just don’t wanna pay another $200 to do it is all I’m saying :slight_smile:

Feel free to come up with other solutions to the issues…

Yes, the main issue is signal loss on the ESC’s due to the Ground lift effect.

A well designed level shifter per esc will fix it, a well designed option to completely isolate the signal would be best…

The issue here is offering a solution that just works.

The green cube has an engineered solution that is proven, and yes, it’s $168, but the hand modification was done at no additional charge, and Hex throw in the Sorbathane mod to do at the same time… free.

You also end up with the new sensors that have 4x the sampling rate, the heater (critical for boat mode) and some other modifications that reduce mechanical stress on the sensors compared to earlier versions of the 2.0

The intention was never to make money here. I was lead systems engineer for Solo, and we designed it to be the best system available. I wanted to complete that project, and make it as I intended it to be from day zero. Remove the bugs that were in it…

At the current price of Solo, this upgrade is a no brainier.

1 Like

I’m new to Solo but am interested in integrating a GPS PPK solution for precise photo center coordinates. A user on another post wrote: "Only problem with solo is the CAM__FEEDBACK feature was not added until APM:Copter3.4, and solo is stuck on a modified version of APM:Copter3.3. So the Solo has no way of logging precision camera fire times."_

Will this parameter be updated in this release? Please confirm, Thank you!

Anything functioning and available in 3.4 and 3.5 will be functional and available on the Solo! I’m not deeply familiar with RTK and camera triggers. But if it’s part of 3.4 and soon 3.5, the it will be on the solo.

The biggest question is is there a AUX pin available on solo for using with the feedback signal?

If you are really good soldering really tiny pins on the 80 pin cube connector, yes :slight_smile:

Thanks guys. Do you think that it is feasible solution for an amateur “hack” such as myself? :grinning:

I have no idea what your soldering skills and equipment are. Let me add some perspective… You will need a magnifying glass to do it.

I just hope the green cubes stay available, need to order another one for my primary solo, but have some other purchases ahead of it.
Solo flies awesome on the cube and rc7