I recently started exploring the world of visual recognition and was particularly interested in SLAM. I have tried and tested different SLAM implementations on a laptop from openslam.org
I'm still new to the field and still learning about it. I want to implement SLAM on an android device. Can anyone point me to any such implementation. Or can you suggest which implementation of SLAM would work best on an android device. I have access to top of the line android devices such as the Galaxy S6 or the Nexus 5.
Before starting to work on my idea I just wanted to know which implementation would work best in terms of efficiency and accuracy on an android device.
Thankyou
Those guys are quite good, the source is available under GPLv3 license (in user friendly form) and a friend of mine was able to run it on android in real-time (It was developed for MAVs and they state that it should reach 50FPS on current embedded computers).
https://github.com/uzh-rpg/rpg_svo
(Check out the video on the homepage as well)
orbslam is a open source slam system basing on sparsity method.
on pc orbslam can reach about 35 FPS，on smartphone it can‘t perform like on pc， so you can't move the phone too fast. That is because the feature extraction process of orbslam take so much time.
svo is a good choice as for speed, however, svo is only a visual odometry, it dosen't have a loop closing module, therefore when run for a long time, the drift may be large.
therefore, i recommend orbslam.
many people have migrate the code to android, you can search on github:https://github.com/search?q=orb-slam+android&ref=opensearch
Related
I'm stuck at home with a rather bad webcam. I was considering upgrading, but then it struck me: phones these days have really good cameras embedded in them. So why not use it as a webcam?
However, as I was researching this further I was really disappointed with the available apps for this. As far as I was able to find, we have Android apps that work roughly as follows:
Present phone camera as a network attached camera. Then you can use local software to use that feed as a webcam. See e.g., IP Webcam. This may be sufficient, but it's a complicated setup, and network latency makes this far from ideal.
The Android app sends the camera feed to an custom host application that in turn creates a virtual web camera. See e.g., DroidCam. This mostly solves the latency problem, but it is still rather complicated, and requiring us to install a specific third party application is troublesome in regard to user privacy. Especially since the applications are closed source.
So, I took the engineering approach and tried to see if it was even possible to improve the situation. As far as I was able to find, Android supports being used as a custom USB accessory. And looking over the USB video class documentation, it strikes me that it should be possible to create an Android app that presents the phone as a generic UVC webcam, such that we do not have to resort to tricks such as the ones above.
Ideally, I would have liked Android to add another USB device option ("Use USB connection as webcam") in addition to debug mode, file-transfer, etc. This seems quite unlikely to happen in the short term however.
So, my question is this: Does an application that does the above already exist? My searching thus far haven't yielded any results, but I might be missing something as googling for this turned out a bit harder than I expected.
Alternatively, am I wrong in my assumption above, such that there is some fundamental issue why an Android application cannot be made to work in that way?
There does not seem to be any complete app yet as of 2020-10, but the parts are mostly there:
https://github.com/tejado/android-usb-gadget has code to switch the Android device into gadget mode (but no UVC yet)
https://git.ideasonboard.org/uvc-gadget.git feeds v4l2 into the uvc gadget output
Sources:
http://www.davidhunt.ie/raspberry-pi-zero-with-pi-camera-as-usb-webcam/
https://www.raspberrypi.org/forums/viewtopic.php?t=148361
https://www.reddit.com/r/androiddev/comments/iabc2o/can_i_use_my_android_as_wired_camera_ie_as_a/g1nrijl/
It appears Google has started to take notice on this issue and are currently working on a "DeviceAsWebcam" service, which is exactly the solution to this problem, as seen in the Android review below:
https://android-review.googlesource.com/c/platform/system/sepolicy/+/2410788
Naturally though, this is a Android 14 feature, so it will like take a while before this is usable on a lot of devices. Hopefully, someone is able to backport this feature to older versions of Android.
If android / the version of Android that comes on your target phone provides / permits use of the USB gadget driver, then libguvc,
https://developer.ridgerun.com/wiki/index.php?title=USB_Video_Class_Gadget_Library_-_libguvc
can be used to "make an application appear as a USB webcam".
Potentially relevant to get you started would be https://stackoverflow.com/search?q=Android+USB+gadget (other SO references to the use of the USB gadget driver on Android).
I own a Samsung Galaxy 3 and want to port kernels available for other Android Devices. I have all building environment ready. I have C knowledge also. What exactly I dont understand is how and what all things porting involves, which codes should be modified in what way?
If someone could help me. It would be great.
Thanks in advance.
Ok I got it. But the real problem is I dont understand one thing.
What needs to be changed in the source code so that to make it compatible in other device? Can someone explain me that?
Idolon gives a good suggestion. In theory what is written there is true. In practice, it's a little more involving. I've been porting Android Kernel for months now. My goal was to have a custom S5PV210 processor module on my custom board with my custom I/O. I have the source code for Samsung's galaxy tab and several Samsung's android smartphone as well as a few versions (Froyo, Gingerbread) for the Samsung's Evaluation board (SMDKV210 for S5PV210 CPU). FYI, S5PC110 is a close derivative. Here is what I found out.
Eventhough all the device drivers are supposed to be built in a very modular way and independent from each other and you should be able to replace them with similar devices, the way Samsung did it is not exactly that. To give you one example is about power management. In many low level drivers dealing with hardware devices, it calls some specific routine for other hardware devices like power management chip. So, When you change the choice of drivers in the "make xconfig" or "make menuconfig" it will remove the source code of what you don't want and add the one you want but, there are still other modules that are calling the low level function you removed. When building, you will get tons of unresolved external because you removed a power management chip that your hardware doesn't have but is used in the source you started with. I looked through several Samsung's device source code and they have branched very early on. They have been adapted by different teams and it would be a major amount of work to go from one device to the other from one source kit.
Here is how I succeeded: I bought an S5PV210 evaluation board with an already ported Android Kernel (Gingerbread). All the power management and inter dependant issues where already cleaned-up. Then, form a working kit, I could change the device I needed (the one you can't buy without a 100K unit/yr commitment) without getting stuck with the interdependancy. Then I could even change LCD resolution (from 800x480 to 1024x768), touchscreen, Cell modem etc etc. The whole thing takes about a month worth of work with only one guy (me).
Starting with a Galaxytab or other commercial device made me waste months of headakes with no useful results but the thing I've learned.
There is one requirement to succeed on my approach. You have to know the hardware you are working on. As an example, you need to know what touch screen your hardware has (chipset) to select the driver and were is it connected to hook it up to the right device (USB, Serial etc). That the same thing for all other devices (power managemnt chip, keypad, backlight, LCD etc etc)
Hope that is useful to give you an idea of the work involved and how you can do it.
You should take a look at the cached copy of Android Platform Developer's Guide and at android-porting google group.
There is also an old but useful article about porting Android to Nokia N810, which will give you some hints about Android Linux kernel porting.
I am also into android porting stuff for quite some time I suggest the following route :
Read
You need to have basic knowledge of android porting and AOSP source code, directory stucture hierarchy.
I suggest you to start reading https://books.google.co.in/books/about/Embedded_Android.html?id=plHsngEACAAJ&hl=en
and also refer https://source.android.com/devices/index.html as good guys pointed out you can also google android porting related groups and become a member there, if you are stuck on a issue there are chances similar issue might have been faced by someone else previously.
Observe
AOSP code :
Parallely you need to dive in to the android source e.g from links like https://android.googlesource.com/ observe which components are placed where in the source code, what are the updates from previous android release (like ART replaced dalvik in LL), at top level there would be generic code, code specific to your hardware called HAL in hardware/ and device/ folder.
Kernel code :
In the kernel also you need to observe the directory structure and know which things lie where like SoC specific code will be in arch/ directory defconfigs (used for selecting kernel configuration) will be arch//configs/ directory.
Also there are good books available for linux kernel, you can google them and start reading them also.
While porting kernel you need to take care of following
1.If in the new kernel there is already support of SoC which is used in hardware to be ported then you need to add only device specific changes like suppose you want to port new kernel version to samsung galaxy s3, you can take a reference android kernel having exynos support and then you need to make changes only for adding support for samsung galaxy s3.
For that you need to have reference of some old kernel having support of s3, from there you can study patches which have been added to add support for s3 and port those patches to newer kernel.
Experiment
First you can only port the bare minimum changes required to up the platform, compile and flash it on your platform, then observe the output, if everything looks fine than go on for next changes otherwise try to solve the issue.
Thanks,
Devarsh
I am new to the development as well as the prg world. I want to learn android and want to make applications for it. So one possible way is to buy a new android phone to test it live and not on emulator. But I have two spare phones, Nokia N70 and Motorola MotoRokr E6. So I was willing to port the OS on those machines. As a result I wanted to know is that possible then what all do i need for that considering both Software and Hardware Aspects.
ThankYou in Advance...
Its possible however I would strongly recommend against it.
While android is open source and nominally can be run on any system you choose, in reality you would have to start worrying about keyboard incompatibility, drivers for any integrated peripherals your phone has, lacking buttons that are standard to all android phones etc.
Getting android running well on one of these phones would be a large project in its own right. I certainly wouldn't recommend testing your android apps on it as a first port of call as the problems you uncover are as likely to be with your android port as with your app.
Neither phone has anywhere near sufficient memory.
You need 96-128 mb, preferably more like 256 mb of ram.
Something that was already linux-based would be simplest as you would start by adding the android kernel modifications. Alternatively, something that is a winmo cousin to a vendor's existing android phone and has basically comparable hardware so you can hopefully recycle drivers or leverage an existing porting effort.
But if you need to aquire a phone anyway, get one that already runs android.
I started developing android applications. And am testing with the android emulator. Do I really need android phone before releasing it for public usage?
Short answer No. You can test and build a android application package with the SDK and an emulator. But I would say there are usually many things which it would be wise to test on a device.
Personally I have noticed that the emulator does not give a good indication of response times for UI controls. It is usually necessary to move functionality which has long processing times into background threads to maintain user interactivity without the 'force close' pop-up. Testing the effectiveness of your UI responsiveness must be done on a phone to be meaningful.
Network connectivity is another aspect which can be vastly different on a phone, 3G or wifi.
Device sizes and Android platform versions can be tested effectively on the emulator.
Some phone allow hot-swapping of the SD card (replacing the SDcard without turning off the phone). I am not sure how to replicate this on the emulator.
There may be many more things which may only become apparent when using your application on a real device. I would strongly suggest to always test under real conditions when feasible for any commercial project.
From a technical perspective there's no reason why you can't develop purely on the emulator. You're not going to be able to test on every available device, so there's always going to be possibility of device specific bugs that you've missed.
However, I'd strongly recommend getting an actual phone to test your application on.
For me the biggest difference between an actual device and the emulator is the difference between using the interface with your fingers and using a mouse. Interactions which make sense in the emulator sometimes don't work as well when you start using touch on the screen. So if you develop purely on an emulator you'll won't lots of little improvements to your UI that would obvious when you used your app on a phone.
You can't feel a real app in your hands until you have a real phone. (I'm telling you as an Android developer)
So, developing w/o real phone is possible, but real phone gives you a lot more experience, fun & usefulness.
It depends on what type of application you're developing, for serious ones you need at least one device to test it on. For complex applications you would need a range of devices, for example with or without hardware keyboard, different navigational button etc. For basic, simple applications you'll probably do fine with just the emulator.
I would imagine with games you would definitely need to test on real devices.
Thanks to you all. I am going to get HTC Legend and test it, so that I can hope that my apps can be used by others :)
You guys suggest me HTC Desire or HTC Legend?
Does anyone know of a cheap Android or programmable device that has wifi?
I need it for a project for a company that needs a Wi-Fi handheld device for the shop floor.
I'm not too fussed about the language the device uses though I'm not really interested in the iTouch as there's no intention to release the app in the app store and I don`t really want to jail break everybody's iTouch.
Ideally it would be small, iTouch size for example and relatively cheap $100 or less. Nothing fancy, just ability to write a simple UI and have Wi-Fi. Voice is not needed.
Not too fussed about touch or qwerty keyboard either.
How cheap is cheap? On the weekend I searched eBay for "android slate" and found a bunch at US $99. I bought one immediately. It may not have the world's fastest CPU or a heap o' RAM, but at that price, how can I complain?
Like you, I want to develop apps for use in an industrial situation. I'll list voice as a feature if I use handphones, but don't really need it.
Would you please publish your final purchase decision here and I will likewise if I find a "better" option.
Bear in mind that it's not all about the cheapness of the device and consider the development effort.
Android has at least 2 good things going for it.
1) Generally programmed in Java (although you can use C & C++ if you jump through a few hoops). I may be wrong but it seems that new grads these days only know java (no offence intended to anyone reading this) and even "old hands" with C++ can quickly pick it up.
2) Android was designed from the start for developers and has an excellent development environment and good tools.
I bought a bunch of Android books and really liked Unlocking Android: A Developer's Guide, but you might want to check Amazon for readers 5 star votes.
And I have just noticed Android Wireless Application Development which I will have to buy; I think that you might benefit from it too.
Oh, and if you want to outsource any development at competitive rates ... ;-)
There were some cheap Android devices at http://dealextreme.com