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. 
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.pywas 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_controlmavlink message which should control copter yaw and gimbal pitch. But only the gimbal pitch was working. I tried having it use the newermav_cmd_do_mount_controlmavlink 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 usecondition_yawto control the copter yaw component. This worked nicely. The old message controls the gimbal pitch as always, andcondition_yawhandles 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 calledNTF_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.
