I am having an issue where i execute the startTakeOff() method, and the callback of this method is returned before (0.5 meters) the drone got to the height he suppose to (1.2 meters) - this part is documented (startTakeoff()) - which is a bit weird. After the callback is returned i am loading the actions to the timeline (getting a success callback), and then firing the startTimeline() method, i've also registered a listener that prints all timeline's event status, and what i see is that the timeline started, then the GoToAction (first in the timeline) is started but the drone doing nothing, doesn't move or do anything.
If i clean the timeline, reload the actions, and fire startTimeline() again (w/o calling to stopTimeline()) it works as it suppose to.
My question is - is there a 'clean' way to delay takeOff's callback? Or make the timeline run w/o reloading it? By 'clean' i mean that i can set a custom timeout that will load and start the timeline, but it is not the best practice...
No the OSDK fires the callback as it leaves the ground, your only option is to observe and wait for it to reach 1.2m.
OSDK only provide you with some sample. It is not 100% sure of working. You should think and get a solution to your problem.
In your case, the delay they put is without any guarantee. you need accurate feedback to make it sable
You can use a system such as SVO to achieve this. https://github.com/uzh-rpg/rpg_svo
SVO gives you feedback of ur current drone status. So instead of using delay
start take off
while uav not at 1.2 meter -> (take off running) do nothing
while uav airbone -> do the thing you want
Additionally you can put timeout in, in case overloads and drone cant take off successfully.
I saw people getting SVO / PTAM / Vinsmono working on android phone before. So i think you could do the same.
Related
I am uploading photos in my app and want to provide the User with the upload progress. The way I was going to do this is have a global tag, UPLOAD_MEDIA_TAG and use that whenever I am creating a OneTimeWorkRequest. That way I can just observe the WorkManager.getInstance().getStatusesByTag(UPLOAD_MEDIA_TAG) LiveData, and whenever a job completes I would show a percent completed. (I.E. Uploading 3/10 photos would show 30%). Then once all 10/10 photos have been uploaded, I would hide the progress bar. This works great as it easily supports leaving the app, coming back, and you will see the Progress Bar as soon as the app launches right where they left off.
The problem is that once all 10/10 jobs are finished and marked as completed, those jobs will stick around until the WorkManger prunes them. So if the user uploads 5 more photos, the LiveData is returning 15 statuses instead of 5, throwing off the percent calculation.
I noticed there is a method OneTimeWorkRequest.keepResultsForAtLeast(duration) but what I would want is something like, keepResultsForAtMost(duration) or a WorkManager.getInstance().forcePrune() method that would cleanup all the completed jobs from the database.
Any help would be great!
After submitting an issue with Google, they are saying there will be a function called, pruneWork in Alpha03.
As of alpha release, you don't have much control over job pruning since it is managed by WorkManager. You can however observe the lifecycle of WorkManager to get job status and take necessary action as follows:
WorkManager.getInstance().getStatusById(myWork.getId())
.observe(lifecycleOwner, workStatus -> {
// Do something with the status
if (workStatus != null && workStatus.getState().isFinished()){
// Stop observing data or do other action
}
});
Note:
Use [WorkManager 1.0.0-alpha03 which has several bugs fixed and new features introduced. One you might be interested is:
Added WorkManager.pruneWork() to remove completed jobs from the internal database
I am trying to incorporate Android GraphView project into my app and all the time I have some strange problem with it.
My app requires drawing graph from real time data. I have thread with all the communication that is providing the data. In main thread I am reading this data and simply use mSeries1.appendData(new DataPoint(counter,data[0]),true,100); where counter is int that is incremented after each update.
Unfortunately at some point it freeze. I've tried putting it in synchronized block or changing the line of code to mSeries1.appendData(new DataPoint(counter,counter),true,100); and still this same result.
This is how the memory looks like during app running and when it freezes:
Does anyone have any idea what might be wrong in here?
EDIT:
This is my current method for updating my graph view:
public void onEventMainThread(ReadingsUpdateData data) {
mSeries1.appendData(new DataPoint(counter,data.getData()[0]),true,100);
counter++;
}
Maybe it's too late, but I had the similar problem and finally I found that when GraphView is appended a new data of "NaN" freezes.
So check the situation in which the result will be NaN such as divide by zero or something like that.
Although you do not specify the rate at which you add points, and how long for the app runs without crashing, you should expect things to go wrong at some point (you're potentially generating an infinite number of point objects, while the memory is indeed limited).
Do you need to have all the points the app has received from the beginning drawn ? If not, you could implement a sort of circular buffer that only keeps the X last values generated by your "provider thread", and update the graph each time you receive a new value with the method
your_series.resetData( dataPoint[] my_circular_buffer_of_data_points );
This thread is quite similar to your problem, have a look at it !
I'm a beginner at App Inventor and I don't know what I'm doing wrong with the listpicker.
I am trying to create and app to reproduce the music I have stored in my server but when i display the listpicker I can't click any of the options and also I can't go back to the first screen. Here I put my code:
Image 1
Image 2
I tried to remove the line that says call listpicker.open but it only made appear a totally black screen.
The result of the code I just posted is exactly what I spect a list with the name and the link of the 2 songs I already upload to my server but when I click them it didn't do anything.
Thanks for your help.
The Web component works asynchronously, which means, it takes a little bit, until the result is available. The result you will get in the Web.GotText event.
Therefore it does not make sense to call the updateListpicker procedure in the Listpicker.BeforePicking event, because the result still is not available and you get displayed an empty listpicker. The listpicker will be opened, before you have received the result!
Set the listpicker to visible=false and use a button.click event to call the updateListpicker procedure. Then as you already do it in the Web.GotText event, assign the received list to the listpicker and open it.
I have been working on a android project.
Then I came up with 2 question.
Q1. how to implement navigation drive ?
My logic and some work
- I am be able to draw path between 2 address. And my thought is that, use the onLocationChanged(current) method then call https://maps.googleapis.com/maps/api/directions/output?parameters with the current location and destination which through some method to draw the path on the map.
Upon every onLocationChanged() method call, I redraw the path on the map again.
" Is it how we would do it for navigation ? "
Q2. how to implement voice navigation to work with Q1 ?
- Did some research, can't find anything that seems clearly helpful. All I know its that, in the return JSON from the /api/directions, there are direction instruction in it.
" Do I use it for voice from the return JSON ? Or there is a better way ? "
Would be very helpful with some link or example in details.
Thanks in adavnce
Here is what I know, hope it helps you out.
Regarding the first question:
After retrieving the directions and the necessary data, you have to draw the direction once and only once! yes, you have to use the onLocationChanged() but not to redraw the whole thing again.. if you notice in most of the navigation application they still keep the main route, they don't remove the passed parts... but you have to use onLocationChanged() to check if the user is out of the drawn path (by maybe 100m) so you have to re-calculate and redraw it again... redraw the path every time the user move is a costly operation it is better to be avoided...
For the second question:
As you said, the data retrieved already has the navigation commands.. so what you have to do is create a class to map the command with the voice.. and if you notice within the legs -> steps tags, there is a start and ending coordinates for each sub-path, so you can use these data to calculate the distance between them on each 200m say the command that "how far the user is to turn left" for example.
Hope this gives you a general idea of how it works. Good luck and happy programming.
I am currently writing an app that should display a real time measurement curve in a scrolling fashion (think ECG recorder or oscilloscope). An unexpected system call in the UI-Thread makes the display stutter.
The data rolls in via bluetooth. All works fine and the display is reasonably smoothly scrolling with an average update rate of 26 frames/s. But, nevertheless the display is stuttering remarkably.
I used traceview to get more insight and according to traceview the stuttering is the result of a call to android/view/ViewRoot.handleMessage which lasts 131 ms per call on average.
If I dig down further in traceview the cycles are burnt inside android/view/ViewRoot.performTraversals. 92% of these CPU cycles are consumed in mostly recursive calls to android/view/View.measure.
From there it gets complicated due to the recursive call structure. But I can find calls to the onMeasure() method of LinearLayout, FrameLayout and RelativeLayout. The onMeasure() method of each Layout type consumes about the same amount of CPU cycles. Which is very strange since in my activity I use only a simple LinearLayout with just 2 Elements.
I just see no reason on why a supposed re-layout of a LinearLayout with 2 Elements performs calls to non-used Layouts and takes a whopping 131 ms to do that.
Further info:
Platform HTC desire HD with Android 2.3.1.
I use a handler to perform the drawing in the UI thread.
The Layout is a simple LinearLayout with 2 Elements: a custom view and a textField.
The status bar is hidden with getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);.
The drawing is performed on each new block of data, which arrives approx. every 50 ms.
The drawing itself uses a canvas and is performant enough to keep up with the incoming data.
After that long explanation, here are the questions:
What is calling the android/view/ViewRoot.handleMessage? (the calls are relatively equal spaced every 850 ms and have no obvious link (no direct calls, number of calls and relative positions are not linked to the message handler for drawing) to any activity of my Activity)
How can I suppress the calls to android/view/ViewRoot.handleMessage or how can I make them faster (there are just 2 elements in my LinearLayout)
the calls to unused layouts first got me think of the status bar or some hidden activity (e.g. home screen), which may use such layouts. But how come those calls are part of the trace of my activity? As far as I understand the trace should only trace the active process. e.g. the calls of my service which produces the real time data is not part of the trace.
Is there any possibility to trace individual calls to some system components? When I zoom in in traceview I see this call sequence: toplevel -> android/os/Message.clearForRecycle() -> android/os/MessageQueue.nativePollOnce() -> android/os/SystemClock.uptimeMillis() -> com/htc/profileflag/ProfileConfig.getProfilePerformance() -> android/os/Handler.dispatchMessage() -> android/view/ViewRoot.performTraversals()
Off topic: Is there a possibility to export the data which is shown inside traceview (parents-children-CPU time etc.) other than a screenshot?
Ok, I found the reason for the long call to android/view/ViewRoot.handleMessage.
This was indeed caused by my application.
My App has 2 screens (Activities) one with a complicated Layout for status information and the other one the real time display of incoming data.
The data, which comes in over bluetooth contains mixed real time data and status data. When I switch to the real time Activity, I was stopping the status Activity with finish(); after starting the new real time Activity. Unfortunately this is not enough to stop also the message handler, which receives the new status information in the UI thread, and continued to update status data in an invisible and finished Activity. The relayout of this activity caused the stutter of the real time data.
This is now solved. The display scrolling is now reasonable smooth.
Thanks for your patience. May it be useful to anyone who stumbles on this Thread on stackoverflow.
jepo