LinuxDrone Project LinuxDrone? What is it all about?

[osnwt]

Hi guys,

we are happy to introduce this new project created by a group of former OpenPilot developers. You can read more info about us on our web site.

What the LinuxDrone is? It is an attempt to create a really open source and open hardware autopilot/UAV system based on Linux with real-time Xenomai co-kernel. The goal is to use the same processor for all tasks including hard real-time ones, not like a Linux as a governor for another flight board.

Why Linux? It opens doors to a lot of possibilities. Say, do you know AR Drone with its onboard video-based position hold? Imagine the same but completely open source, running on $35-45 board.

Why we do that? Just for fun. We have no commercial interests behind.

At the first stage to proof the concept we play with the OpenPilot project software fork, porting it to Linux as a native Xenomai real-time application. Below you can see the OP Revo software running under Linux on BeagleBone Black board. It uses only 10% of CPU time. Note that the board is running full blown Ubuntu Linux with active TCP/IP stack, Apache web server, USB serial port, USB mass storage and USB TCP/IP connection active (the latter is used to connect to the GCS). On this video you can see the native linux fw_beaglebone.elf process running. It connects to the original OpenPilot GCS which is being temporarily used for first tests.

Ok, the next step was to actually make it flying. And that's done. On the next video there is the Alex's milestone: the first flight of the penguin.

Please don't complain yet that it flies ugly. The person who piloted it has no any multirotor flying experience. Moreover, this was actually the first ever flight without any PID tuning. We used defaults from Revo board which obviously has different timings. And beyond, it contained wrong timebase and used non-realtime Linux native i2c driver which does not guarantee any timings at all. Anyway, it flies and not so bad for a new platform assuming the first take-off.

What's inside? Actually, just a retail linux board. For initial development we took easily accessible hardware:

• BeagleBone Black board running Linux with Xenomai (source: a lot of distributors worldwide, $45)
• GY-87 10DoF i2c sensor board (source: DealExtreme and others)
• 4 x AfroESC 30A (source: HobbyKing) reflashed to use i2c bus
• Orange OpenLRS receiver (source: HobbyKing) reflashed to use i2c bus
• Orange OpenLRS module (source: HobbyKing)
• 3A UBEC (source: HobbyKing)

We used i2c for a reason: to proof the concept of the system and simplify connections.

The connection diagram is as follows (wiki link):
View attachment 15638

We have no plans to produce any proprietary hardware. But in case of success and interest to the project it is expected to see some 3rd-party manufacturers to provide ready to use systems.

OK, what's next?

Our next step is to get rid of legacy OpenPilot code (both GCS and firmware) and replace it by own, written specifically for this application. And we have a lot of plans and some project roadmap.

Some of plans are:

• web-based LinuxDrone EmbeddedGCS™ (eGCS™), which will run directly onboard. For users it means that you can connect to the board via WiFi from any device: PC with any operating system, laptop, iPhone/iPad, Android phone/tablet, etc. And configure or tune board without any software or special hardware.
• javascript scripting. Scripting was one of goals of the OpenPilot, still unreached. For instance, you may write a script to take a 360 pano photo from a POI and return home with a click of a switch. We are making new system completely scriptable. The base scripting language will be javascript, running onboard under node.js, popular platform for high-performance web applications. Its Google V8 engine provides all necessary power for that.
• Linux userland: any software, applications, scripting languages can run directly onboard.
• C++ for firmware development. Yes, it should be used carefully for embedded applications, but in the end it can be as good for that as plain old C, but with few advantages.
• Open CC-BY-SA source code license. No hidden tags attached. Use if for any kind of applications, even commercial ones. Just reference us and contribute changed code back to the project.
• Free and available hardware. Unlike some other projects, we decided to use commodity hardware boards like BeagleBone Black and Raspberry Pi. There are a lot of owners of such boards, and everyone can add few components to it and start flying his LinuxDrone. Moreover, we do not use yet any specific hardware features of particular board. Yes, we can or maybe should do that (say, use both 200MHz PRU units on the TI chip of BBB to run PWM acquisition/generation), but as an alternative it could run i2c or CAN bus devices, board-independent. So any Linux board which runs Xenomai-enabled kernel should be OK. But we will provide firmware images for BeagelBone Black and Raspberry Pi only yet.

How can you help us?

We are a group of skilled people, and we can implement all of above. But the more people join us - the better. At the moment we run own git repository, but there are no any releases yet, and new code is not stable or nice to look at. We plan to mirror the sources to a github as well as to Atlassian fisheye web site for easy guest access. It may take some time, but if you are interested in authoring, please send us your public git keys, and we will add them into our repository ASAP.

Tasks waiting for developers: anyone can find a task. Some of them are:
- RTDM I2C driver for Xenomai;
- TI Sitara PRU drivers for PWM/PPM;
- Javascript coding including server-side node.js scripting and client-side web application.
- a lot of other tasks.

We don't invite testers YET, but if you want to build your own system and try it - there is some info on our wiki, and more will be added soon. We will provide Linux+Xenomai images, built firmware, sources, give advices for development environment. But some Linux background is desired at this stage. When we make a final release, it will NOT be necessary like it is not necessary to run, say, your home router or SmartTV. That's the goal of the project.

Last but not least. Running own forum isn't an easy task. We decided don't do that at this stage having more time for development. I wish to thank Bart for providing us with this place to talk. Thank you!

And finally. The more feedback we see - the more info we share here. So don't hesitate to ask any questions, even stupid ones. We like questions, we like learning to new things, and we like healthy community around.

 

[osnwt]

Active project links (full list here):

www.linuxdrone.org - main project site using wiki as a front-end
code.linuxdrone.org - web repository browser with code reviews
forum.linuxdrone.org - project forum, courtesy of multirotorforums.com

More to follow...

 

[osnwt]

Reserved for FAQ.

 

[peabody124]

Very cool and exciting Oleg. Something like a beaglebone will be a really powerful future-proofed platform that I bet will be really exciting.

 

[osnwt]

Yes, because it often isn't advertized, but actually BeagleBone Black internally has 3 processors: the main one @1GHz, and two others @200MHz each, called PRU, Programmable Realtime Units. They have access to pins, peripherals, shared memory of main CPU and work independently of the main CPU. So we can easily offload the main core running Linux of low-level realtime tasks. At the moment we do not use it, trying to utilize the main CPU and have relatively hardware independent code (it already runs also on Raspberry Pi). But if we can do real-time i2c in software using proper drivers and hardware support, we hardly can do accurate software PWM (unless we use hardware timers instead of Linux services and make things non-portable). For many applications we can avoid PWM (like now with I2C only system). But if someone will go for a purpose-made board, PRU can help generating accurate PWM, for instance.

Programmable Realtime Unit Subsystem

Now Andrey works on PRU, Alex and Voha discuss architecture and write base code, Sami waits for his BBB, I do what I usually did in OP (environment, Makefiles, etc), and few other guys learn what we already have done to start coding. Time will tell, but the first results are promising.

PS. Actually, Arduino developers have been working in cooperation with BBB developers on a new Arduino platform which is based on BeagleBone. It is expected to see Chinese clones of that board as soon as it arrives. So we will have:
- cheapest Linux board, BBB-compatible (both original and clones);
- Arduino shields (including 3.3 to 5V level shifters);
- a lot of users as a result.

It should be perfect as a development platform. And still, purpose-made boards can be smaller, lighter, better suited for small UAVs. The more choices - the better.

 

[Gary Mortimer]

Subscribed

 

[osnwt]

I think, is better to subscribe to the "Project progress" thread, since we post all info there. Or to the whole forum section (upper right corner, forum/thread tools -> subscribe).

Just posted there a new video showing some ideas about confuguration editor.

 

[osnwt]

It seems I can't edit #3 in this thread reserved for FAQ. So I have to answer to one question here:

Q: I am new, what should I do?
A: We started this project to be fun for all of us. As such, we have some desired roadmap, but no deadlines or dates of releases. For many of us some areas are completely new, but we took this opportunity to learn Xenomai, C++ in firmware, javascript and nodejs, programmable real-time unit subsystem assembler, web GUI... So we have no central board of directors or designated project leader. Everyone takes a task which he finds interesting for him and implements it. In many cases we discuss possible solutions, but often some people just do something cool and show us the results.
We do not assign tasks, we can only offer some directions. If you see a problem with build or want to write something - read, learn, write, share, have fun
If we will assign tasks - the project will not be fun for people, since one would expect some results from another (who may be busy with main job or family). So we have to adopt the development model as said above: pick the task and do that. Say, write a module, or language binding, create a part of web GUI, write a list of components for issue/task tracker, test our build system and fix scripts, at last. Anything you tried and had problem MUST BE FIXED. If you can - do that please and send/commit patches. If you can't - please let us know. That is also extremely important.
Since it's a new project, it changes very fast. So we adopt another rule from KDE development: who writes - decides. This means that if you write a new part of the system which had no yet a template - you can make reasonable assumptions about best implementation. Of course, sometimes it may require some rework. Don't be offended if we ask to change a bit of code later, that's possible in agile projects, and some code is better than no code. And we always can improve it.

Q: Who should I talk about the code?
A: It depends on areas of your interests. Different people here informally lead different parts of the system. The best way to join is to post a new topic in our forum section and briefly explain your skills and interests. We will try to give some ideas where you can help.

 

[xtrmtrk]

This is very cool.

I don't have a whole lot of spare time to explore projects, but over the last year I've experimented with two multicopter things: An embedded web based GCS and a ground station based OSD. I've always thought having a separate GCS made development and use harder than it needed to be and strictly limited the usable platforms. And I've been intrigued by the possibilities of having better video and compute capabilities in a ground station to display flight management data than you could have onboard.

Are you planning on making OpenLRS a fundamental part of this project? I think it'd be a good idea. If you have a BeagleBone Black on board and a Raspberry Pi running your ground station-based OSD, all connected with OpenLRS's built-in serial telemetry, I think you've got the makings of an amazing and affordable system.

Good luck to you guys, you're going to have a lot of fun with this (isn't that what it should be about!). For now I plan to watch from a distance but if I have some spare time I might jump in and help.

 

[osnwt]

Thank you!

Yes, having cross-platform but compiled language GCS is a limitation. So the embedded one. Having system running Linux it is a matter of good web application - and now there are a lot of people who writes exactly web applications. So we decided to make a core system for that and invite people experienced in web apps to help us to write a cool GUI.

RasPi as an OSD - well, I didn't think about that. Definitely it's possible, but still requires some reliable data link. In case of video it is not so crucial. But why we need an OSD? Usually for real-time FPV. If so, how do you feed an on-board video to RasPi? What about latency? Honestly, I am not sure if it is easy to do properly. But I am not an expert in that area. Maybe Sami can tell more since he has a good experience doing STM32-based OSD.

OpenLRS: our goal is to make a general-purpose real-time platform. If used as a UAV brain, it should use many possible interfaces like PWM/PPM/S.Bus/DSMx/Serial/etc. OpenLRS was used for few reasons:

• we used its i2c output to get controls from radio;
• we used its level shifter to connect to i2c ESCs (AfroESC reflashed to SimonK firmware);
• alternatively we used it to use receiver PWM outputs fed by i2c bus from Linux board (so we receive controls from radio via i2c bus and send data via the same i2c bus to receiver to generate servo signals - and don't need a level shifter).

So it was an easiest way to take off using OP firmware which we removed later. Since now we have working PWM input/output system running on PRU, is not necessary to use OpenLRS. But it still is possible due to open source firmware and affordable hardware (I bought Taranis and Orange OpenLRS Tx/Rx exactly for that). We have not decided yet how to use the telemetry channel. We prefer to use the same web-based link for telemetry. But we need a kind of protocol able to use low speed high latency links. We can use the same BSON over TCP on top of PPP link, but I am not sure if it will work well enough having PPP and TCP headers and checksums. We can also run a kind of special procotol similar to MAVLink or UAVTalk. But we have not decided yet.

Again, thank you for your interest to the project. If/when you want to join, I think, we will have more established base for easy jump into that. I'll be happy to answer any question you may have.