I'm trying to use whole body balancer made by Aldebaran to make my nao dance more steadily and to be less dependent on the surface horizont level, to neglect some small tilt.
I've succeeded in requesting nao to go to balance, but enabling balance constraint gives me nothing. For testing, I designed an ill-balanced timeline which leads robot to fall down when the body balancer is disabled and should keep the robot stable as log as it's enabled, that's what Aldebaran declares as a use-case. However, the robot still falls down (I keep him vertical with my hand) and then goes to balance due to ALMotionProxy::wbGoToBalance. It is strange, however, that he reaches balance in a rapid move, rather than in 3.0 seconds that I requested.
My suggestion now is: whole body balancer needs some resources (joints) that are actually used by my timeline (it uses all the joints). Is it correct? Can anyone confirm or deny this?
The source I use is generally this one:
self.proxy = ALProxy("ALMotion")
self.proxy.wbEnable(True)
self.proxy.wbFootState("Fixed", "LLeg")
self.proxy.wbFootState("Free", "RLeg")
self.proxy.wbEnableBalanceConstraint(True, "LLeg")
I use this source inside a box in Choregraphe 1.14 and it is definitely called (it leaves logs I stripped out). And it definitely gives me no exceptions, I check and log them.
Yes, I think that you must remove some joints from your timeline.
The test is easy: disable for instance ankles from your timeline and see the results.
Disabling some joint is easy:
open the timeline
click the small pen beside the "Motion" caption on
the left
then uncheck some circles (for instance the LAnkleRoll
circle): so those joint animation will be disabled.
retest
Related
I have a react-native application that populates pins on a map that have been submitted by users. The front end gets the corners of the window and then the back end goes through each pin to check if it falls within the boundary, and returns the ones that do.
This is taking too long on the backend and I want to ask the community for ideas, because I doubt I have the best one.
My idea is to store tables of pins grouped by quadrants, effectively a cache, and then I can in almost constant time return the pins from the quadrants involved.
Is there a simpler way to do this?
Maybe using NoSQL?
🙏🏻
A month later it seems geohashing is probably the best way, plus AWS has a library for automatically handling this with dynamodb. Apparently it takes the corners of the screen, lat/lon, and automatically returns the items from the DB in the view, in, I assume, constant time, since that's the whole point of geohashing, getting performance that works at scale..
https://www.npmjs.com/package/dynamodb-geo
https://aws.amazon.com/blogs/compute/implementing-geohashing-at-scale-in-serverless-web-applications/
Otherwise, using a geohashing library that is built for serving mobile apps likely exists.
I want to add an image carousel to a profile page, and allow the user to view the images in fullscreen mode thanks to a modal. It means - if I'm not mistaken - that the carousel will be imported twice: once in the profile component, and another one on top of it when the modal opens.
It is a heavy process, and I'm afraid of performance issues. I thought about creating my own carousel, but there are already many packages that perfectly deal with hand gestures on mobile, etc. However, their weight is sometimes dreadful.
For instance, the library react-awesome-slider - which seems perfect - weights 666kb! However, on Bundlephobia, it is supposed to only weight 36.2kb or 8.2kb gzipped. Who is right?
Will react-awesome-slider weight 2*666kb, 2*36.2kb or 2*8.2kb in my final bundle? What is the maximum weight recommended to keep a high level of fluidity/performance?
This looks like premature optimization. Don't care about your bundle size in this manner - if 3kb gzip is a lot or not. Simply, if you need that library use it. You will understand that having library for summarizing of two numbers might not be necessary before any bundle size issue will appear.
Bundle size that you always care about is the gzipped value, that's what client receives and has to "download" - that takes time. But as you can imagine, downloading 30kb on your computer at home is not an issue. On old device in middle of Blairwitch forest it might be.
Also, it gets send to client once per page/application so if your modal has it and your page has it it won't be included twice. Imagine having some library like Lodash, which is big and used (if I exaggerate) in every function, do you think it be included 100 times?
Try to optimize the user experience in terms of ui/ux, that will be the first one user will quit your page for, not that he had to download 30kb of carousel, he will not even notice!
We are trying to move Pepper around on a floor using ALNavigation SLAM APIs. We have created a map using ALNavigation:explore() method. The application works most of the time but sometimes Pepper stops and the application crashes in between due to some safeguard feature.
We are using ALNavigation:navigateToInMap to move Pepper around the map.
Here are some logs:
[W] 15:01:26 ALMotion.OmniWheelFollowPath: Stitch failed. Stopping path:
["Circle", [0.436987877, 11.431554794], [2.869375944, 11.368105888],
-0.046996359]
[W] 15:01:26 ALTouch.TouchManager: My Base is touched. Reasons: Wheel.
[W] 15:01:26 AutonomousLife: Robot was moved!
[W] 15:01:26 AutonomousLife: Robot moved, must enter safeguard state. Will
immediately re-enter solitary state.
Is there any way to fix this issue or is this a hardware issue with Pepper's wheels or something wrong in the code? I am simply calling navigateToInMap after localizing the robot and this works most of the times but this issue is getting more and more frequent.
Thanks
Pepper has a system to detect if she's been pushed, and (with current versions) there are sometimes false positives - especially on a floor with irregularities, or when pepper is moving quickly or accelerating brutaly.
Some solutions:
Make Pepper move / accelerate a bit more slowly
Have a system to launch the application again as soon as it exits safeguard (for example with a ShouldBeExploring or shouldBeNavigating trigger condition) - in my experience when this false positive happens the robot is in safeguard for a very short time, maybe less then a second.
I recommend the second solution because that's usually what you want to do when a safeguard that's not a false positive is triggered - when someone bumps into pepper, or shakes her, etc.
It seems that sometimes timeline items (just text) arrive instantly and other times they take forever... Is there a way to send one at precisely the right time?
You can send the notification at a precise time.
timelineItem.getNotification()
.setDeliveryTime(new DateTime(oneMinuteInFuture.getTime()));
That's a java example, where oneMinuteInFuture is a Calendar object set to one minute after now.
What happens when you do this is the card is inserted in the timeline immediately, but the notification is delayed until the specified time. So the card goes in right away and one minute later I get a chime.
There is an unaccepted issue related to this at the issue tracker you might want to star and follow, it appears that this functionality might change in the future.
I've got a WinForms client-server app that displays various offers in a list. Every user (client) has a "rating". An offer consists of various data including a minimum and maximum rating. If a user's rating does not fall in that interval, he should not be able to take the offer.
Of course I could just perform some server filtering and send a list of offers prefiltered for each user to the client application. But that would surely, and rightfully, lead to confused requests "Why isn't this offer showing up? I know it exists, it shows up on [other user]'s screen."
How should I handle this? My favorite solution so far is to grey out the offer and add a tooltip "You can't take this offer because your rating is too high/low" while displaying greyed-out offers at the bottom of the list to leave the actually valid offers easily visible on top of the list.
A disabled option tells the user:
The action is possible.
Just not right now.
But the user can make it possible.
Unless there is some simple action the user can do to change his or her rating (e.g., by selecting some other controls in the same window), do not use disabling and do not show the offers. Disabling may confuse some users who will then hunt around the window for something to do to enable those offers. It’s a great idea to use a tooltip to explain disabled objects, but that’s not a standard and not all users will think to hover the mouse over a disabled option (Why should they? It’s disabled).
Including offers users can’t have, even when disabled, clutters your display, forces more scrolling, and distracts the users from the offers you actually want them to consider. Furthermore, showing unavailable offers can come across as taunting (“ha, ha, your rating isn’t high enough”) and may diminished the perceived value of the available offers by comparison, resulting in lower user satisfaction.
It seems unlikely to me that users are going to go around comparing the offers on their windows, but maybe you have user research saying they do. In any case, you should label the list of offers to make the criteria clear (e.g., “Offers available at your rating” may be sufficient).
If you want to encourage users to increase their ratings, then maybe include something advertising the benefits of an improved rating. For example you could have a link "-Improve your rating- by four points and get -five additional offers-." The first -link- tells users how to improve their rating, while the second lists the offers as a motivator. The latter link should only be there if the offers will still be available if the user actually succeeds in getting four more points.
That sounds like a good way to do it.
As a slight improvement, if it makes sense for your application, you might consider including the actual numbers in the tooltip, e.g.:
This offer requires a rating between 5 and 8. Your rating is 4.