You are correct on all counts. Baked into the motor matrix code is motor output slewing. In short, this derates the PWM rate of change. This code does way more for the Solo's protection than the max PWM parameter. It is a total hack of a fix, but it was really the only way to address the problem without redesigning the ESCs. Believe me, the developers behind it hate it more than we do. It is crippling to the Solo's potential performance in the sky.

During changes in load, there is ground lifting condition on the ESC. This ground lifting results in the ESC seeing voltage drop from 3v to less than 2.5 volts. When the voltage drops below 2.5 volts on these ESCs, the signalling simply stops. The motor subsequently stops. And down you go. In most cases, the signalling comes back on within a second. Given enough altitude, the copter can often recover from the tumble. Mine did thankfully. But not before scaring the ever living crap out of me. When this happened to me, it was actually two ESCs that shut down at the same time, then came back on. Soo all that stuff the developers say about it being risky... they're not lying.

This very topic was discussed in the weekly developer's conference call on Monday again. The conference call was 2.5 hours covering all Ardupilot development matters. And in that 2.5hrs, we actually had about a 1/2 hour long discussion on all things Solo master, which was great! Lots of great input, ideas, and discussion on how to proceed. Anyway, the consensus right now is we need to put this into master, and use a parameter to enable/disable it. Default would be disabled since literally nothing but a Solo with a stock Pixhawk 2 needs it. If master is being installed on a Solo with a stock Pixhawk 2, that parameter will be enabled in the parameter file. If you've replaced it with a Pixhawk 2.1 / green cube, you can turn it off again. That's our current thought process anyway.

Doing this will allow stock solo users to safely operate master. It will allow Pixahwk 2.1 solo users to safely operate master with handicap. And it will have no effect on anyone else using Arducopter.

Love it. When could it be implemented ? Any dates ?
 
Love it. When could it be implemented ? Any dates ?
A specific date? No. But we're all ahead full now. I'm working on some commits that will fix the LEDs and notification tones now. Hoping to have that working this evening before my second beer. It's actually a lot more important than it sounds because it's the only way to know what it's thinking doing. Then I hope to finish porting over 3DR's ESC slewing protection this weekend so we can stop falling out of the sky. The home position already has a commit done from one of the developers. That will leave only the gimbal issues which still requires testing and evaluation to solve.

What I really want is for Arducopter 3.5 to fully support the Solo when it comes out of beta. I don't know if that will happen. if this gimbal takes too long to fix, I don't think anyone wants to hold up 3.5 for everyone just for the solo. So the solo might come with 3.5.1 or something like that. Best I can tell you is "soon".

Even before that time, I might compile a px4 file that has everything for some willing volunteers to try out :)
 
@Pedels2Paddles

What do you mean by
"it will allow Pixahawk 2.1 solo users to safely operate master with handicap"

I thought the problem with the esc's was not there in 2.1 Pixhawk?
Was this a slight miss print? Did you mean "without handicap!"
 
My green cube is on order I'm getting very excited lol
 
What kind of performance boosts are we looking at without the P2 handicap?

And thank you thank you thank you for the work you are doing!!!!
 
  • Like
Reactions: Pedals2Paddles
Hey Pedals2Paddles,
First of all big thank you for all your hard work!!
I loaded your master firmware on the green 2.1 pixhawk cube in my solo...
Seems to fly fine, return to home works as well, it does not seem to be as smooth as with the original 2.0 cube...it is a little twitchy....

That's all good, but one thing that no longer works is the smart shots, I tried Panorama with both Solo app and Solex...it takes the pictures but all in one direction and does not rotate the quadcopter...
Any ideas on what could be done to fix that?
Thanks
 
Hey Pedals2Paddles,
First of all big thank you for all your hard work!!
I loaded your master firmware on the green 2.1 pixhawk cube in my solo...
Seems to fly fine, return to home works as well, it does not seem to be as smooth as with the original 2.0 cube...it is a little twitchy....

That's all good, but one thing that no longer works is the smart shots, I tried Panorama with both Solo app and Solex...it takes the pictures but all in one direction and does not rotate the quadcopter...
Any ideas on what could be done to fix that?
Thanks
Yes that is well known. Pano overall and Tap2Fly in Solex don't work yet with Master. Also, don't do a factory reset since this will brick Solo. Other than this, Solo flies extremely well with the new firmware.
 
What is the major reasoning for going with this type of set up vs Stock? Are you gaining better distance, connection quality ?? TYIA!
NM Found the other thread that has much more detail about this topic... #searchfunction:)
 
The fly-me-there and other guided mode special functions on Solex have been solved. The next version of Solex will have that fix in. So if you're using Solex on master, it will no longer seek out terrain :)
 
  • Like
Reactions: OldCoder and carpy
A specific date? No. But we're all ahead full now. I'm working on some commits that will fix the LEDs and notification tones now. Hoping to have that working this evening before my second beer. It's actually a lot more important than it sounds because it's the only way to know what it's thinking doing. Then I hope to finish porting over 3DR's ESC slewing protection this weekend so we can stop falling out of the sky. The home position already has a commit done from one of the developers. That will leave only the gimbal issues which still requires testing and evaluation to solve.

What I really want is for Arducopter 3.5 to fully support the Solo when it comes out of beta. I don't know if that will happen. if this gimbal takes too long to fix, I don't think anyone wants to hold up 3.5 for everyone just for the solo. So the solo might come with 3.5.1 or something like that. Best I can tell you is "soon".

Even before that time, I might compile a px4 file that has everything for some willing volunteers to try out :)

So, outta curiousity, did you ever compile that px4 file? Just asking before I go set up up a full toolchain and compile myself. I'm jonesing pretty hard to utilize Optical Flow. And knowing I'm future proofing by being on Master gives a certain piece of mind.

Thanks for all the work and the many pieces and parts sacrificed
 
So, outta curiousity, did you ever compile that px4 file? Just asking before I go set up up a full toolchain and compile myself. I'm jonesing pretty hard to utilize Optical Flow. And knowing I'm future proofing by being on Master gives a certain piece of mind.

Thanks for all the work and the many pieces and parts sacrificed
Have you purchased the green cube yet? That is currently a requirement.
 
Have you purchased the green cube yet? That is currently a requirement.

Ah. I I have not. I misunderstood, it seems. I thought what I'd read indicated that it was possible to safely run Master on the stock Solo pixhawk.

Guess I'll go ahead and slink back into my cave.
 
Until the annoying slew rate code is moved over to master, it will not be safe on a stock solo. And that slew rate is honestly the bottom of the to-do list right now. The green cube is the hardware solution to the hardware problem that really should be the route right now.
 
  • Like
Reactions: OldCoder
P2P,
I've been following your progress at:
Solo Slew Rate software fix for ESC signal issues · Issue #5988 · ArduPilot/ardupilot · GitHub
and can't agree more.
I started looking at picking up a GreenCube for one of my Solo's and got distracted by the link on their store page to the GreenCube's schematics: GitHub - proficnc/pixhawk2.1: Repository for Schematics for the Pixhawk2
There I found the Altium project files for the IMU, PSM, and Edison carrier board, but there was nothing for the FMU.
I was expecting to see something similar to that from the 3DR GitHub repo: GitHub - 3drobotics/Pixhawk_OS_Hardware: Design files for the open hardware designs used by 3DR
Any idea where the rest of the schematics for the GreenCube are?
 
  • Like
Reactions: andrew.baker.142
Until the annoying slew rate code is moved over to master, it will not be safe on a stock solo. And that slew rate is honestly the bottom of the to-do list right now. The green cube is the hardware solution to the hardware problem that really should be the route right now.

I'll start saving additional pennies. Until then I might look into designing an outboard solution to prop up the signaling voltage on the stock cube. Just as a mental exercise mostly.:cool:
 
  • Like
Reactions: OldCoder
I'll start saving additional pennies. Until then I might look into designing an outboard solution to prop up the signaling voltage on the stock cube. Just as a mental exercise mostly.:cool:
Funny you should mention that. @human just posted in mod club about that very idea. Using a logic level converter to step up the 3.3v signal to 5v. The general consensus from the hardware geeks is it could work but couldn't say for sure with confidence. Converting the level has some unknowns and you would be a test pilot proving the concept.

This is also a good time to point out that ProfiCNC will soon be releasing UAVCAN (canbus) ESCs as motor pod replacements. Way better ESCs, canbus two way communication (like rpm and error feedback to pixhawk), and they don't randomly turn off in flight.
 
  • Like
Reactions: OldCoder

New Posts

Members online

Forum statistics

Threads
13,095
Messages
147,750
Members
16,063
Latest member
No idea