Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Víctor Mayoral Vilches
@vmayoral
@tridge just added a section under "Learn", that's the process we are using and it link to our images that flash the eMMC automatically
there's also a manual process described in a subsection. We keep putting time into the docs so feel free to add any comments and we will address them as soon as we can
Randy Mackay
@rmackay9
For the Linux boards to take-off don't we need to make the firmware updates from the mission planner work?
I think if you can tell people, "upload the firmware just like you do for an APM2 or Pixhawk" then you'll get much better adoption of the board
Víctor Mayoral Vilches
@vmayoral
Captura de pantalla 2015-01-26 a las 9.47.12.png
@proficnc have you noticed that P8_17 layout? Shouldn't we remove the trace if it's marked as "spare"?
Víctor Mayoral Vilches
@vmayoral
@rmackay9 I like the idea of updating the boards from the GCS. We generally use Linux/Mac OS. Mission Planner seems to be Windows oriented, shall we look at APM Planner better or maybe QGroundControl?
@bugobliterator is looking into a web-based GCS, it'll be awesome to do it from there as well
Philip
@proficnc
On the latest from me, the trace is removed...
i use mission planner, and so do a lot of people...
Bill Bonney
@billbonney
APM Planner 2.0 will work better tha QGC for APM code.
QGC removed support for the APM stack in the latest code, and really focuses on PX4 Flght Stack
Philip
@proficnc
Really? Wow, didn't know that!
Víctor Mayoral Vilches
@vmayoral
thanks @billbonney
Víctor Mayoral Vilches
@vmayoral
@tridge just got a notification from the Embedded Linux Conference 2015. It seems that my talk proposal has been added to the wait list which is unfortunate.
All the best for those selected!
Bill Bonney
@billbonney
@proficnc QGC removed support for the setup screens, you can still fly (kind of) it still allows the ‘variant’ to be added back in, it just needs somebody to do it
Bill Bonney
@billbonney
@vmayoral you can get the latest beta here http://firmware.diydrones.com/Tools/APMPlanner/beta/ it’s 2.0.16-rc2
Craig Elder
@CraigElder

Hi there BeaglePilot,

In two days (Monday, February 2, 2015), your GitHub Pages site will no longer be available at its custom domain:

beaglepilot.com (hosted at https://github.com/BeaglePilot/beaglepilot.github.io)
We’d hate to see this happen, so please take a moment to update your site’s DNS record:

If you’re using a subdomain (coolthing.example.com, www.example.com, etc.), make sure you have a CNAME record that points to BeaglePilot.github.io.
If you’re not using a subdomain (example.com), make sure you have two A records set to the following IPs:
192.30.252.153
192.30.252.154
Questions? Simply reply to this email to reach our suport team. More information about these changes is also up on the GitHub blog: https://github.com/blog/1917-github-pages-legacy-ip-deprecation.

The GitHub Pages Team

Adam Erickson
@adam-erickson
Anyone test APM on the Navio+ with a RasPi2 or Odroid C1 yet? Pretty excited to see how mine goes!
Andrew Tridgell
@tridge
http://diydrones.com/profiles/blogs/first-flight-of-linux-apm-on-raspberry-pi-2-with-navio?commentId=705844%3AComment%3A1955184&xg_source=msg_com_blogpost
Randy Mackay
@rmackay9
The Navio+ guys are sending me a shield shortly so I hope to give it a try as well. I'm planning on using it with a RPi2
After my trip to SFO & EmbeddedLinuxConference I'm quite keen for ardupilot to move to Linux.
Randy Mackay
@rmackay9
I've fixed up the copter SITL test so that they should be working again. We shall see in about 1 hr after the auto builder completes
Adam Erickson
@adam-erickson
I'm curious to hear more about the Pixhawk 2. Where does that leave the PXF? It seems the Pix2 is the Arduino TRE, which is basically a BBB wrapped around an Atmel MC.
Randy Mackay
@rmackay9
I think the PXF still has a bright future. At least the linux boards in general do. I'm personally pretty keen to help move forward on that..
The Pixhawk2 is still basically a pixhawk .. it's in a new form factor and it's got some extra sensors.. but it's still not linux.
Randy Mackay
@rmackay9
.. and moving to linux is important in the long run because it opens up a whole new world of boards, development tools and applications that can be run on the vehicle
So .. definitely not bashing the Pixhawk2.. it's a good step forward.. but linux is stlil firmly on the roadmap
Craig Elder
@CraigElder
Pixhawk 2 is the current step in our evolution. Linux is next. We still have work to do
Adam Erickson
@adam-erickson
Sorry, it seems the Pix2 is an upgraded Pix1 Cortex M4 with a separate i.MX6 Cortex A9 Linux board. A very practical transition.
Craig Elder
@CraigElder
@DougFirErickson Pixhawk 2 is a redesign of the current Pixhawk but does not include an i.MX6
Adam Erickson
@adam-erickson
@CraigElder Meant Pix2 implementation in Solo, not Pix2 itself. Navio+ arrived today, excited to do some testing.
mhct
@mhct
Hi, is this thread still alive? I wonder what is the main issues with using Nuttx in the Pixhawk. I thought the real time properties and simplicity of Nuttx were the main factor for using it with Pixhawk. I have the impression that Linux on the other hand is quite "complex" for the usages needed for the autopilot. Any thoughts regarding that?
Randy Mackay
@rmackay9
@mhct, I think there's still some people listening here...
Personally I think Linux is the future because it's got a much larger set of tools available and people know it better.
NuttX is good on the real-time side but you know.. it doesn't have anything like the number of developers working on it that linux has so there are some issues. For example, it makes mistakes printing floating point numbers to the console.
Also Linux becomes especially compelling once you start adding a companion computer to the vehicle. At that point, you've already got linux on the vehicle so it might as well to the flight control as well as everything else the operator wants it to do.
Grant Morphett
@gmorph
Completely agree Randy
Craig Elder
@CraigElder
The PXFire discussion is taking place on the Erle Robotics site but there are people here too
and yes, our future is on Linux
mhct
@mhct

Thanks for the answers @rmackay9, @gmorph, and @CraigElder . I start to see the point. I strongly agree that having a large community behind the OS allows it to evolve quite fast. I simply thought that having a simpler OS was a preferred way to go with the drone autopilots, so to avoid the extra complexity that a linux kernel may bring... Are you also looking at isolation of the autopilot and the other possible high level applications that currently are being done on companion computers?

I ask this, because I am interested in the safety aspects of writing software for drones...

Grant Morphett
@gmorph
Linux auto pilots generally have more CPU available then embedded so we could do more complicated math resulting in better flight. Linux opens up a large number of devices with drivers already written. And yes, no need for a companion computer when everything can be done on the one device. That being said getting a Linux box the size of the Pixhawk2 would be tricky.
mhct
@mhct

The issue I see with running the autopilot with other application on the same computer is the possibility of bugs making rendering the autopilot unusable, for instance.

Perhaps process isolation, or visualization will be key here?!

Grant Morphett
@gmorph
Linux is already being used in hunderds of thousands of real time applications everywhere. Ours is no different really. All those problems have already been solved and ardupilot will simply be leveraging that work.
Sorry about using the marketing word leveraging - my bad ;-)
mhct
@mhct
@gmorph good point, indeed. :-)
I am still curious how the separation between autopilot and other software has been done, or better, how the separation (isolation) between critical applications (like the autopilot) and other applications (like a high level planner) has been done. Any pointers to that would be greatly appreciated :-)
Andrew Tridgell
@tridge
@mhct its a trade off. Specialised RT kernels have more bugs per line of code than linux kernel I think, because they have far less users (especially if you use esoteric features). Linux is indeed complex, but a huge effort goes into testing, validation etc, and it has much better debug tools
we isolate at the moment just by using RT thread priorities