The PX4 is here and soon it will have a fully supported version of ArduCopter:
From what I have been able to glean, Chris and Company are now in the process of revising this controller for better use by our group including an enclosure.
I Do not know for sure if they are planning on modifying the board itself but indications are that they are.
Now this is completely unsolicited by DIYDrones and may even be an annoyance to them, but there are some things I would like to see in there and I'll bet some of you would as well, so now is your chance to sound off before it becomes a fete acompli.
Whether it will do any good or not I haven't got a clue.
An enclosure is good, but a internally vibration damped enclosure that was truly effective for reducing Accel vibrations to a fully tolerable level would be great.
Also, the existing PX4 pretty much requires that you use a PPM-Sum receiver with it.
PPM-Sum receivers are great, but only a few are available (Futaba and FR-Sky) not counting Graupner for obvious $$$$ reasons.
Personally I would like to use my plain old vanilla Hitec Aurora 9 and I think a lot of people would be a bit put off by having to upgrade their whole radio system because they didn't want to include a few extra RC inputs.
That's the 2 biggies I can think of, this is the place to put in your thoughts and we can see if anyone is listening.
This feedback is certainly unsolicited, I hope it is not also unwelcome.
Comments
The serial communication is what we are going to be for processor to sensors, external communications, servos and ESC's. The issue on the PPM Sum is laid upon the compatibility. There are glitches of FrSky on PPM Sum signal, Futaba S.BUS and so on. The R/C industry has their own echo system and less standardization.
I guess the fact of the matter is that PPM-Sum is going to be the path of the future in any case, microcontrollers have become ubiquitous and having them distributed along the communication chain is pretty much normal in most computer communications, so why not here. I'm not going to beat on that horse, I'll adapt.
The other issues: distributed versus monolithic and soldered versus interconnected have benefits in both camps.
My personal preference would be for monolithic where practical and distributed when absolutely necessary. Combining the GPS and Magnetometer in a remote module makes sense, but building in or at least hard wiring the receiver to the flight controller main unit might also make sense.
I do understand that keeping your Accels and Gyros at or near the CG or at least the center of airframe rotation is beneficial, so that might justify a remote module, but keep in mind that is also the module that needs to be really effectively vibration damped.
As for connector versus hard wired, both have severe disadvantages, so keeping external wires to a minimum is a big plus and even if we do use connectors, they could be a lot more electrically secure than the ones we are using now.
Gary, some of us know how to wield a fine-tipped soldering iron, if connectors are such a big issue. Stop and take a 3-rd person view at the trends: lately we're using Z-accel for alt-hold and X/Y-accel for pos-hold is coming. We really really need to separate the sensors from the processing power and gpio. One small IMU unit is easier to manage then a whole AIO board. Less wires to transmit vibrations, less inert weight to add for inertia and less special vibration dampening silicone rubber.
There's some chinese companies that went on this road and I bet their balance sheets look promising.
Then there's the battle for the area at and around an aerial vehicle's CoG. The advent of brushless gimbals combined with the counter-balancing of cameras with lipo packs will make the CoG a sensitive real-estate area. And its management is a bitch if you look at a 70x60 mm AIO board. If for instance you had a 15x15x10 mm cube of vibration-dampened IMU, things would seem easier by a big order of magnitude.
Regarding PPM-sum, heck, I'm using a $50 9X radio with $50 more of mainly FrSky upgrades, and it's serving me well.
Gary, I actually agree with you; if they're redesigning the board, why not consider adding this? my point was that there is still a solution out there, requiring a PPM Sum input isn't really a reason not to go with the new board.
I have to say tho, I really do hope that if it IS true and they are redesigning the board that they steer away from "flying lead" type modules wherever possible. our copters create an awful lot of electrical noise, and the larger & more powerful they become the more pronounced the problem will be, and if we are using a system with lots of modules and leads for "flexibility" it will become extremely unstable due to electrical noise...
Interesting comments about PPM Sum, another advantage is that it minimizes wires and connectors. I knew about FR-Sky and from what I can see here so far the consensus is that PPM Sum is sufficiently superior to multi-channel so that you are better off without it. Basically better to go forward and not worry so much about legacy.
Gary, Thank you for the link to the PX4 group, but this is something that is coming to this group soon and we have an opportunity to say what we want, in so far as options exist, so it is relevant here too.
And Jesse, that certainly looks like one solution, but if they are remaking the board why not get normal multi channel RC input done on board, one less part and one less learning curve. Still probably a lot better solution than having to buy another whole RC system.
And Jack, I have seen the incredible stuff you build, but this, in the long run isn't about an autopilot or about simple. For me it's about Robotics and surfaced referenced navigation and path finding. With that capability things really start to get interesting. So I'd prefer something with a whole lot more memory and processing power and still might add it on.
And Para, we have watched 3DR bounce from on board GPs and magnetometer to off board and off-board sure seems to make sense for some sensors at least they are currently doing off board GPS with the option for the magnetometer.
On the other hand there is certainly a problem with connectors too. Each connector adds an at least short term loss of signal possibility and we all know how well our Firmware and MultiCopters like that. Guess you could go mil-spec quarter turn, but that would more than quadruple the weight of the whole thing to say nothing of the cost.
Why not cross that bridge when we actually come to it? It's not that you *couldn't* use the old systems. You'd just need a $20 PPM Encoder.
Also, you don't need to spend 250-500 on a decent radio. Well, you won't for long. FrSky should be releasing their 9 channel transmitter in a few months. Should be about $150-200, and should be great. It'll have higher quality components than the Turnigy, and use the Open9X firmware.
Also, I'm not sure there will ever be a time where nobody will want to use a real Tx. Some of us still want to be able to fly.
@R_Lefebvre: "Not to mention, from what I've seen, the systems that can't output PPM Sum also don't have an effective failsafe scheme. So why would anybody want to fly that stuff?"
Maybe because one would not want to shell out 250-500US$ for stupid Tx controller (which is a real relic in this story), more than a price of the rest of the electronics combined. Such controllers would probably go away in a few years, and we would all switch to a WiFi link to drone. So my vote goes to: divorce the future controller from stupid PPM sum, and give a people ability to fly with order of magnitude cheaper Tx/Rx, and not shed a tear when these Tx/Rx are thrown away soon.
I agree. I'm glad to see the 8 input channels go away! It's a complete anachronism. Not only that, but it seems to be the #1 persistent problem with the system. What are we always talking about? The PPM Encoder firmware. No offence intended to JAB and others who work on it. They've done well considering how complicated this thing is.
I mean, lets look at it rationally here:
The Tx gathers analog position data of 6-8 pots, combines them into a single PPM stream, and transmits it. Then the Rx takes that, and splits it into 8 individual PWM pulses. Then you use 8 wires going to the APM, which feed the PPM Encoder. The Encoder looks at the independent PWM pulses, and combines them back into a single PPM stream. And then feeds that to the AVR chip. Then the AVR chip splits it back out into 8 seperate control inputs.
How many steps is that to do such a simple job? It's insane.
I think if the SMT32 can take 8 PWM inputs without needing an encoder, fine. But if an encoder is needed, leave it out! Sell an easy to use stand-alone Encoder board for people who don't want to upgrade. Maybe something with a nice 3x8 female socket rail, that simply plugs into the Rx output header. 3 wires coming out. Done.
I mean, it's not like there isn't cheap and easy ways to get PPM Sum anyway. $20 for an FrSky Rx. Come on. Not to mention, from what I've seen, the systems that can't output PPM Sum also don't have an effective failsafe scheme. So why would anybody want to fly that stuff?
But I agree with many of the other comments.
- We need a single GPS puck, with a Mag built onto a single chip. It just makes sense!
- Either have a separate IMU, or put the IMU on a daughterboard with a ribbon cable goint to the main board, and the daughterboard has some mass, and vibration damping. Where have we seen this before??? Again, it just makes sense.
- I also like the thing where the PX4 has a separate output board. I think this could be improved if it was easily possible to join the IO board to the STM32 section via a small signal cable. Then you could mount the IO board remotely, which is good if have an Octo with 8 ESC wires, or a heli or airplane requiring 4+ big heavy gauge servo wires.
- While we're at it, offer light duty, and heavy duty IO board. The HD one would have a power rail capable of feeding big power hungry servos.
- And then continuing the evolution... Make a daughterboard that plugs onto the processor board, and holds an FrSky receiver.
@Jack Crossfire. I see your point, but you have to keep mind, we are building a system here which is highly flexible, and capable of complex operations. We're not merely interested in building something that flies around in our kitchen. Yes, I think the cart has gone before the horse to a certain extent, but I think it's turning around finally. MAVlink is necessary for higher functionality.
So I would like a source link for this revisiting thing before speculating what it means. I can immagine them perhaps moving a component or two to make assembly easyer but not much beyond that.
I personally dont think the ppm thing is an issue, Id call it a pro since there is no reason anymore to waste boardspace and weight on headers when you can get a full 8 channel receiver at 4grams and connect it using a single cable to the FC.
-
11
-
12
-
13
-
14
-
15
of 15 Next