Why there isn't a standard hardware architecture supported?

This point has been discussed at length amongst the dev team and partners.
I’ll just raise a couple of points.
The board support abstraction (“hwdef.dat” and the underlying code) was designed to simplify the process of bringing up new boards, and enables two important things:

  1. It makes it achievable for community members to run ardupilot on many cheap boards. This was (and still is) important to make ArduPilot accessible to as many people as possible, with the hope that it would reduce the number of people starting out with old APM 8 bit boards. That has largely been successful.
  2. To enable innovation from manufacturers by reducing sunk development time, and hence speeding time to market. This has also been successful, with Cube Orange, Durandal, CUAV X7/Nora, mRo ControlZero and the new mRo H7 board, Matek F765 and H7, etc all being possible without the need for a “compulsory” pinout/standardised board definition.
    A third and important outcome has been, as pointed out by Pete, discovering vulnerabilities in some boards that result in overall more robust code.
2 Likes

1 Giving some directives on how to develop boards i don’t think would raise the price
2 I would not call a success adding a new mcu in 5 years.

What i would call innovation is having standard feedback from the escs, maybe having just one connection to all the external sensors, all of that using canbus so that builds do not look like rat nests. Some real plug and play options without going crazy in having the board recognize compasses and rangefinders.
But i see the answer are monolithic around what is considered to be the main target, having AP running on the cheapest boards avail, it is kind of frustrating but it is what it is :slight_smile:
Again thank you to all the people that answered to my post.

I would argue Hardware has really been innovating a lot in the last few years and it’s using that innovation in software that takes a little time.

The Autopilot has jumped from F4 to F7 and H7 over the last year or so and this opens up a massive amount of opportunity for new capabilities like Lua scripting. This is just starting to open up and the dev team have been doing some amazing work around this and some other visual sensors like Realsense.

On device connection CAN has been around a LONG time now on these autopilots but has taken a longer that I think anyone expected to begin to see adoption. There are some complex reason for that and UAVCAN has become a little messy with the introduction of 1.0 and backwards compatibility being broken. But Hw is coming and Profi have been pushing it along with the Here 2 as well as have others.

CAN is the future for external connection but it first need to settle it’s self and stop the issues we have seen so far.

There is good hardware out there that drives compatibly like Cube series that all are forward and backwards compatible with many carrier boards with options like Edision, ADSB and the Kore Board. Others like mRO and Durandal are doing some really nice things as well.

Hardware is far from short of innovation and while you say it’s SOC, IMU and sensors is all that’s changed but that’s really where the need has been to reliability for a few years. We are reaching a point where the hardware is stabilising in the industry for the core autopilot and gains are smaller to the eye but just as important. Better sensors, better HW testing and reliability is going to be the key moving forward and while people may like cheap $40 boards when your flying expensive payloads you need some knowledge it’s had some extensive QA testing performed.

Really we are seeing more integration of systems with things like power module, ADSB and others onboard, I seen this last week and while it’s not ground breaking innovation it’s very helpful progress for new system and simpler overall design.

Overall the options are limitless and while some of this is not plug and play it’s extremely capable.

3 Likes

I still see a new (lets call new an mcu released in 2014) mcu and a mess of serial, i2c, canbus, pwm, much like on our first uav in 2015. Maybe, as i said, it is me not seeing all this great innovation.
F7 MCU has been released by ST in 2014, we didn’t see them on new hardware untill 2019 or am i wrong? Black cube and all the rest have been released in the mean time and none of them used new tech, just the old trusty 2011 released F4 series, so late to the party to jump directly on the “new” H7 series, released 3 years ago by st, on orange cube, missing completely F7 series.
So basicly all people flying a black cube today, thinking they have bleeding edge tech on board, are running a 10 years old mcu and in some cases 7 years old sensors, not even capable of running scripting if not disabling other stuff, i do not comment on edison stuff because that board was declared dead by intel already when it was released in the cube carrier as the latest and greatest innovation.
I do not agree on good sensors been avail only recently, they have been trustable and usable since mpu6000 and mpu9250, and we are going back 10 years and mpu9250 has been on cube black for a while if i remember well and it was released by invensense in 2013…
Talking about HW testing i do not know where and who makes it, since one of the vendor you mention always releases “beta stuff”, that is why we do not use them anymore.
As i said in a previous post if we want to talk about hw innovation than GPS is the only part that really went from hobby level to very strong performance double freq RTK avail for everybody, that is innovation.
But again, this is only my point of view and always glad to hear from people from a different angle.

2 Likes

Firstly I’m say this guy @Corrado_Steri telling next step to do something new

Yeah objection @count74 I’m with you

Yes you are absolutely right , i think there is only 1 company to make different hardware but not excellent like CUAV

This is a software side not hardware , ok so I guess you need like fport , more uarts , canbus or etc etc …

Yes there are so many technology out there like
:yum: :- firstly i recommend smart battery system
In built OSD system ,
Fport option ,
Specifically 1 Led driver port , soo many more options out there this is a random guys in my mind this are always need me

But this little board (recently known as a f4 series also kakute f7 series and so on) almost do all work as pixhawk '2.4.8 or APM 2.8" and so many others , using betaflight gcs (ground control system = betaflight configuration)

Hmm , i like this thread and I guess it’s like addressable esc telemetry , right ?
And number 10 @iampete it’s decently true your all golden words

Yes, you are right , but couple weeks ago some ESC protocols adding on mission planner like oneshot , dshot series. Btw what is a “AP” ? :sweat_smile:

Yes yes you are completely honest opinion I’m always looking my collage friends when project is coming so all thinking about dji naza flight controller and I’m questioning why you choose this fc and then say it’s easy to install no more defence like all sensor calibration , just plugin and fly.

Ohhh yeah that’s the difference between others and our community :sunglasses:

Hey why are you forgot me :sweat_smile: I’m also huge big fan of opensource community :sunglasses::sunglasses::sunglasses:

Yes. I like this new opportunities adding lua script like a new innovation :thinking:

Number 24 blog = ohhh my god excellent job @Corrado_Steri I’m impressed are you giving soo many details on this forum , thank you sooo much :kissing_heart:

Happy flying :yum:

There are two standard architectures supported: Linux and STM32
:slight_smile:

If and when new STM32 processor families are released and are supported by ChibiOS, ardupilot will be able to support them as well. I really do not get your point.

I was answering about hardware innovation in the boards, i wasn’t by any means questioning software

How will you address The issue of Remote Id nonsense going forward in the US market segment if cube is used in commercial applications?

The project is open source and guidelines are defined:

https://dev.px4.io/v1.9.0/en/debug/reference-design.html

Software adaptation to other cards (not following the open source design) is the problem.

Do you mean some kind of standard is defined but not followed by some manufacturers?

Open source standard is defined. Some manufacturers use closed source (deviation or not from the standard but not shared), and developers chose to adapt software (ardupilot) to other sources hardware (originally cleanflight or betaflight friendly) with common processors…

Ok understand, thanks.

I would like to add my two cents to this discussion. I think ArduPilot should be as Microsoft Windows or Android in mobile phones. Like in PC computers it should be modular and there should be possibility to use different hardware from different vendors. ArduPilot should collect more money from manufacturers for support of their products. ArduPilot firmware should operate all new hardware as fast as possible in the time when new GPSes, rangefinders, sonars etc are released. Now it’s clear that there are too few programmers or they do not have enough time to prepare drivers for all this new hardware. For me this means that too little money is spent on programmers. If we are waiting for a year or more for RTK GPSes, or HD video transmission, gimbals, optic flow sensors, rangefinders, support… that’s to long. If you know that everything is ready to buy in for example in DJI Mavic.

The chance for growing of ArduPilot ecosystem are professional users not only for hobbyist who would like to experiment with unmanned machines. Actual prices for autopilots, sensors etc. are quite high and customers can demand that they buys hardware with final state of software not beta releases. And professional users need whole system not only flying machine but also gimbals support, rangefinders etc. There should be some kind of certificate or information that will give sureness that this hardware is ready and safe for flying (in hardware and software part). If ArduPilot will be to hard to use for normal users without programming knowledge sooner or later DJI will eat whole this business. That only a matter of time when DJI will release a cheap and easy to use plane for photogrammetry (with 20 km range) or small racing drone and 90 % of customers will buy a ready to fly solution. They will resign from building drones based on ArduPilot. We know what happened when DJI Phantom appeared. Whole market of DIY multirotors died. ArduPilot must have better components and technology than companies like DJI and for now in some aspects it’s true. For me the biggest advantage with ArduCopter is that I can prepare for much lower price multirotors for professional cameras (DSLR, mirrorless) and they fly great ! But earlier I was using Mikrokopter and I can see also that there are many still not ready functions.

Yeah, have fun with that. If the AP Devs start trying to push people around things will get ugly real quick. I know if I was designing an FC and was told to conform, I’d tell 'em to KMA.

Besides that, AP is Open Source, so if some one comes up with a new hardware platform they are free to make their own custom version. That’s exactly what RadioLink did for their custom Pixhawk.

Personally, I suggest you take some time and read up on the history of Open Source, 'cause the abomination you’re suggesting ain’t it, not my a long shot.

1 Like

Ok :slight_smile:

Corrado

From my own point of view which is purely hobby, I like making my own hardware as I can design each one for a specific use which I and a few friends fly. When Ardupilot moved to chibios and I was able to put it on a sparky2 and test I thought that was amazing.
I for one hope it stays open source and not just for one or two hardware designs.

This is my own board for small wings without Ardupilot it would never exist.

9 Likes

That a good point, if you see the M300 can fly with one motor failure, without the esc telemetry, It’s much hard to know, Is there a motor failure? ok yes, then which one?