Real Time Processing on Android for Drones and Automation

@Ben, I’m not sure whether it is a good idea to pick separate projects instead of sync’ing all of them together. I can imagine there is a lot of dependencies, so you will probably end up needing more then 100 or 200 projects. Syncing all of them by hand sounds pretty insane :slight_smile:

If you want to save time, download only shallow copies and limit it only to the needed branch:

repo init --depth 1 -u <URL> -b <BRANCH> -m <MANIFEST>.xml
repo sync -c

@Igor Yeah that’s a good point. Just winds me up to see Nexus and asus device projects taking hours to download when they’re completely useless lol. All done now though which is a good thing, but I’m sure that command will be helpful for others.

Found this guide for building the OS for Cyanogenmod, thought it might be helpful to post it here.

Next up is finding the Dragonboard specific package, can’t remember where I saw it…

Hey Ben, how is your progress on this?

Hey Igor! I’ve just come back from a three week holiday so no real progress since my last addition, but now I’m back I’m starting all my side projects back up, so hopefully I’ll get some time for this soon.

Great! I’m also pretty busy right now, but please keep me up-to-date with your progress. It would be awesome if we get a working RTAndroid port for the Dragonboard.

Trying to get back into the swing of this, from what I remember and my last comment before leaving I was looking for the Dragonboard specific package, but looking around it seems the project source code downloaded from CodeAurora actually includes everything you need to build Android for the Dragonboard. Can anyone confirm this?

If that’s the case it looks like the next step will be to build the OS, which will probably take up my laptop for a good while. Have to see if I have the time for that this weekend.

Just wanted to post an update here to say I’m still going with this, not giving up yet.

I’ve had some difficulty building Android in the Builduntu VirtualBox, the main issue being that the image comes installed with Java 8, and the DragonBoard build environment requires Java 7. Managed to get over that hurdle, but have yet to get a successful build of Android. It usually craps out after a few hours with very little debugging info.

I have managed to build the kernel however, so I am getting there slowly. Next time I attempt to build the OS I’ll post the error here if @Igor or @jro are around and available for help.

On a slight side note I have built and flown the drone! Entirely 3D printed and currently controlled with a classic RC transmitter and a microcontroller based flight controller. Le voila:

I’ve also been working on a Wifi direct app to use on the DragonBoard for < 100m RC control and hopefully even video streaming between the DragonBoard and a phone.

Hey Ben,

I’m glad to hear you are still on it. Now you understand why I can’t tell you anything about porting until I know how long it takes to set everything up. Don’t hesitate to post your build errors, maybe I’ll be able to help you.

Hey Igor,

Great to see you’re still around. Yeah I understand perfectly, it’s not exactly a straightforward process. Hopefully if I can get it running with the closed VirtualBox setup we can detail the steps to get most if not all people up and running consistently.

Tried building again last night, and this is the error I got: https://drive.google.com/file/d/0BwtRlQKb8YRPMlVwcXVjNlpHcTA/preview

I’m thinking I need to give the VirtualBox more memory, is that correct?

Seems Google Drive doesn’t play nice with embedded images, so here’s a link to the drone photo:
https://drive.google.com/file/d/0BwtRlQKb8YRPMVFtRVhmMURKSVE/preview

Correct. You need at least 4 GB of RAM to build older Android releases. Starting with Android Nougat, 8 GB is required.

Right, that’s been bumped up to 5GB then. Fingers crossed for the next build, probably tonight.

Okay, next build error:

clang: error: linker command failed with exit code 1 (use -v to see invocation)
build/core/host_shared_library_internal.mk:51: recipe for target &#039;out/host/linux-x86/obj/lib/libart.so&#039; failed

This is host_shared_library_internal.mk at the line of the error:

my_host_libprofile_rt := $($(LOCAL_2ND_ARCH_VAR_PREFIX)HOST_LIBPROFILE_RT)
$(LOCAL_BUILD_MODULE): PRIVATE_HOST_LIBPROFILE_RT := $(my_host_libprofile_rt)

$(LOCAL_BUILT_MODULE): \
        $(all_objects) \
        $(all_libraries) \
        $(LOCAL_MODULE_MAKEFILE) \
        $(LOCAL_ADDITIONAL_DEPENDENCIES)
	$(transform-host-o-to-shared-lib) &lt;------ Line 51

endif  # skip_build_from_source

https://drive.google.com/file/d/0BwtRlQKb8YRPZU5MRjNHWW53aE0/view

Hello @kalkov , to be clear RTAndroid is not open source? I would be reading changes to pie and up bcz of device and new API changes. I would most likely have to rebase your work on top of it and patch the kernel.

I am only dealing with native code and some android framework (camera2ndk, surfaces, and mediandk). Those framework parts I am dealing with are mostly native bits too. Perhaps I can stick with RT patches in the kernel to keep latencies bareable and keep Android as-is. What is your opinion on this? I can explain the use case more if needed.

Puh, this is an old thread :slight_smile:

I left the university about 3 years ago and have no access to the old projects anymore, so I can’t provide you with specific patches for the runtime. Your approach to patch the kernel first and keep Android as-is sounds reasonable, at lease as long as you are not sure what exactly will affect the predictability.

I am still working on Android-based solutions, but now as part of emteria.OS (see https://emteria.com) and without the focus on real-time applications.

I’m curious about what the motivation is for using Android in this kind of application? Wouldn’t it be more rational to use an actual rtos than to use a ui-centric userspace on a general purpose kernel?

Thanks for responding @kalkov. As for my motivation @doitright, it’s a project called [Openpilot].(https://github.com/commaai/openpilot)
Everything there has to be as close to real time and predictable because ya know, it’s driving a car. In the EON (current android phone) they are tackling this by migrating all android tasks to one core and using others for openpilot. It’s not perfect but it works. They are also pinning all irq requests but some problems like modem request and slightly lags the running model, etc.

I am porting a much newer and powerful phone OnePlus 6 so I did my research and came here :slight_smile: .

This project is a bad idea.

Implementing this, you are risking people’s lives, and not just your own.

At the most basic level, you should not be implementing self-driving features on cheap off the shelf hardware (oneplus), you should not be mixing self-driving and UI features on the same machine. You should not be using software that hasn’t been properly vetted.

Even the readme files from the software project say this “We repeat, driver alertness is necessary, but not sufficient, for openpilot to be used safely” which means that even with an alert driver, the thing you are implementing might take over control and do something dangerous, like suddenly swerve for no reason, or lock the brakes.

Don’t do this.
You need better hardware (robust).
You need proper RTOS.