The ZED is a passive stereo camera that reproduces the way human vision works. Up until now, 3D sensors have been limited up to perceiving depth at short range and indoors. The ZED captures two synchronized left and right videos of a scene and outputs a full resolution side-by-side color video on USB 3.
This color video is used by the ZED software on the host machine to create a depth map of the scene, track the camera position and build a 3D map of the area. This feature is supported on both Windows and Linux. We also have a GitHub page that we update on a regular basis. Start building exciting new applications that recognize and understand your environment.
The camera that senses space and motion ZED empowers objects with the ability to see and understand the world around us. Meet ZED. Long-Range 3D Sensing. Dual 4MP Camera. I had this little gem at the bottom of my code that I'm embarrassed to have not caught. It was where the backgroundProcess function was. Since the servos handle their own intep I removed it a while ago. Yep, that's the place :P Not an issue on other processors that are not doing anything else, but Also I should rework some of the XBee stuff as well.
That is I have it off as it's own thread, but then I also make the input from the XBee non-blocking. I do a query to see if I have data and use it, else I sleep, but probably not enough. This is a great thread on your journey so far with the crawler and Rpi. Im not quite clear on power and controller setup, grateful if you can clarify.
Lipo to Bec to Smps2dynamixel. AX actuators daisy chained into smps2dynamixel. Single chain or through any sort of power hub? USB2AX to smps2dynamixel. May be wrong but there is no need for any other controller, so the std arbotix can come out, as the smps2dynamixel will provide the power and the usb2ax the control logic?
I saw somewhere in the thread an ssc32 is slotted in, for what purpose, perhaps comms with the Xbee? Is the above correct so far? Thanks again for wealth of info in the thread, tis a good read :veryhappy:. Kurt and I are working on this endevor together. Kurt is running his Rpi Phoenix software which is still fixed point and I'm running a version which is float point. Last to note is I'm using the smps2dynamixel as a bridge between the two hubs.
Kevin and Kurt thanks so much for your efforts. Kevin - that schematic helps. Same for BEC to raspberry and hub, just solder and run two sets of wires or any kind of terminal block?
Just bought my first soldering iron and multimeter tonight, about to get my hands dirty. Wallet quivering from the sight of these hexapods! This works fine on my cheap USB powered hubs, it does not work on some others as they detect a signal coming from the Host before coming out of power savings, so the PI does not get powered, so it does not supply the signal I have my batteries which has some form of connector. I then have a wiring harness that has the matching connector, where I then often split the power side into two wires, which often go to two different switches.
One switch goes to power the servos. Kurt P. Generally the "tidiest" way is going to be to make your own power distribution setup. Keep in mind "tidy" doesn't always mean compact and small, which may be more of a concern. You can solder and splice wires, or you could use a terminal block. Fan the wires out into two groups and you can slip a larger piece of heat shrink over it. You could also use liquid electrical tape. If you are new to soldering and wiring, practice with scrap wires.
Getting stuff to look neat is a matter of knowing what you want to do before you do it, which is always made better with practice. Take your time, plan things out and make sure you do things like allow enough slack to disassemble components without taking everything else apart never happened to me I swear ;.
Heat shrink covers a lot too, and is much better looking and longer lasting than electrical tape. Check your currents as well, I would avoid using a JST connector for anything that requires significant power. Hi Kevin and others, I did update my git project with some of the simple performance improvements. Will play some more with it soon Kurt. I get to spend part of my weekend trying to tidy up the pair of 2S LiFePO4 batteries into a single stick of butter what it looks like instead of using the gigantic and horrific looking series connection Y-cable I made.
At least they were cheap and should not explode if I mess up. It is inevitable that one will mess up. If you are lucky you will only get a couple small solderflux splatter burns or ugly looking parts, instead of burning the house down. Heat shrink really does look and work much better than electrical tape, but it can be annoying if you make the wires too short and it shrinks onto the wire while soldering.
Even more annoying is forgetting to put it on the wire before you soldered connectors to both ends. For high power connectors, I'm a really big fan of XT connectors as they are easy to dis connect, easy to solder, and have nice little recesses in the plastic around the solder cups for heatshrink to slide into and completely envelope the solder joint. Even really cheap bullet or spade quick-connectors usually work well enough for several amps without problems usually more than JST or small Molex can handle.
Thanks Kurt I'll take a look. I'll try and find time this weekend to at least line up our commander code so at least that matches. I hear a LOT of folks who don't like the Deans ultras, I've used them for years with almost no trouble whatsoever. I think a lot of people try to solder them with way too small a tip. I tin the wire and connector end, then getting the joint heated enough to let the solder flow is quicker. I also try to keep a mating connector at least partially connected to hold everything stable.
As with any soldering clean clean clean your iron! Before every joint! As for the heat shrink on a short wire, a wet paper towel can work wonders to keep that end cool.
It's not that I have difficulty getting the connector or the wire hot enough, it is that the wire has to be soldered to a flat spot. XT have nice solder cups milled into them, so I just heat the connector up and fill the cup about flush with solder. After that, use the soldering iron to push the wire into the nearly-molten solder and top that off with more solder. I'll probably give that a try on the next harness not connected to a power source.
Just make sure you actually make a good solder connection in the middle of all that. Not enough to switch at this point, though To get this thread back on topic What was your CPU load with your changes? Both of these values can be made lower. A long long time ago, I remember some compilers allowed you to compile the code as to do code path timings and the like.
I wonder if this compiler has any of that? May have to look Things I changed: 1 The simple loop you also noticed where we were simply hard looping until the right time. So this is odd So when walking I'm at So the standing there number is really shocking! I must have something odd running when it's still. So even better! I can set a usleep without any noticeable difference to the walk. I tried and it became a bit jerky I assume from finishing the pose earlier than the usleep time.
Though I still need to figure out why it's high 90s when it's just standing there. My brain is crap and I'm a little lost, but should there be a delay in the ReadFromXBee function in diyxbee. My limited understanding makes it seem like the "check for timeout" while loop just continuously calls micro without delaying until it times out, or am I just not looking in the right place for the actual contents of the "DoBackgroundProcess " function.
I see a blank define of "DoBackgroundProcess " in Phoenix. Hi Tician, Yep you are right there should be some form of delay in that function. I need to make another pass through that. It has not shown up yet as I am spending most of my time working the the Arbotox commander input code as that is what others there have. Yes - Background Process is a NOP for most setups except Bioloid , But for Bioloid except for Kevin's new stuff all needed to have their method called to do the servo interpolation Hi Kevin, Looks like you made some great progress on performance.
May have to see where mine is taking up the time. Which is what the code used to be before adapted to PhantomX. Note: this may help yours as well 2 Try compiling out my Terminal monitor. If that helps perf, then maybe try switching monitor to another thread, that blocks on input from stdin, so no need for polling it. Note: I was trying to make the XBee block on the read getc , may need to see about using a read or the like instead?
Or need to check and maybe set the stream block. I ifdefed out the code that was to make it unblock Also for your idle going real high when you turn off the commander. So you should make sure you have some form of delay there. I was each time outputting the stuff to the SSC to free the servos, when I only need to do it once So in the Servo Driver and in the Servo Driver definition , I added a flag to say the servos are active. This cut down on the idle CPU usage. If you want to reduce the idle load, then you probably want to re-structure the program along modern Linux software styles.
Then again, the CPU consumption at idle doesn't really matter -- it's how much work you can do when there's work to do that really matters :- getc uses file buffers, so it will typically read a big chunk of data at a time. This may end up introducing lag to the communications. You may be able to make the buffering smaller down to 1 byte? If you also need to do periodic tasks, a timeout on the blocking call lets you wake up for those tasks.
So, a correctly structured Linux program looks more like a state machine or event-driven automaton. This really did help knock down the idle stuff. Yep idle usage on most of my robots is a non issue as the robot is only doing one thing. But I may also want the pi to do other things like video streaming, so it is good to cleanup some of this.
Kevin, I put a copy up on github with the select if you wish to play ; Kurt. I'll give it a go tonight. Yeah my idle is still low 90's. I checked walking and power off again today and they are still the same numbers as before.
I wanted to check again just to make sure I wasn't seeing things last night. I took a couple of shots of "Charlotte" since I'm toying with the idea of a web page to log my work. Not sure yet. Take a look Kurt! Looks nice. Like the camera there. Have you tried using the webcam server software I have been playing with? Is it supported, Can you then pan and tilt from their web page? Also FYI, I checked in another simple change that if you don't have a background loop, the code simply does one delay of the End Time minus the current time min This also knocked the usage down reasonably well!
I haven't tried that yet. I did download your webcam stuff but haven't looked into it. Though that is the plan. It is the one reason I purchased the one with both the color cam and the depth sensors.
I merged your changes and the xbee thread change helped. I tried your lTimeWaitEnd-Timer sleep modification and it won't walk with that change. The whole bot just shakes when any transformation is applied so I rolled back on that change. Never mind I just noticed our timer functions are different. Multiplying by fixed the issue. Found it! We have what appears to be a hard loop in the step interpolation. Check your travelRequest if statement. In your code it's in GaitSeq function.
But I don't see the difference in the looping The interesting thing is, that I added some debug outputs, that currently show how much time I should delay where we had the loop before. Actually the first pass debug was showing what the PrevServoMoveTime was, when idle it was about what I expected When I had it in a full speed walk it went to the gait speed, which lets say is So in this pass, when idle it says it should sleep ms so the loop used up 8ms.
When in a full walk it said it should sleep maybe about 45, so processing took up more time maybe 25ms , so I would think the CPU usage would have gone down? EDIT: forgot the commander does not give me a full , so the actuall full speed walk PrevServoMoveTime is 54 ad the actual time to sleep is in the range so again not far from the 8ms of idle Still looking?
Sorry my post wasn't that clear. It was late and grammar goes out the window when I'm tired. I will elaborate later after the coffee kicks in. No Problem. Have not had as much time to play, but was still trying to figure out why more CPU used when idle versus full walk. Also side question. Back in my working days I liked to keep my code cleaner. Things like variable naming conventions, indention rules, Back then we had some form of CB program that helped to clean up code when multiple people or editors touched it.
I thought the code was due for some of this. Yesterday I downloaded bcpp and built it on one RPI. Do you have preferences for things like this? Also would still like to get some form of Analog readings in to know my battery voltages. I keep thinking I could build my own version that gives me some inputs like this. As we discussed in pm's I'm still a fan of Hungarian Notation for variables. I also have a couple of programs that will parse through code and do proper indents for classes, functions, loops, if, do, etc.
It will also double check all parentheses and brackets and indent them accordingly. Some people hate those types of formatters due to them having their own personal style. On personal projects using open source I always use them. There are several cases of "formats" people use that I can't read quickly. This just puts it in a style I can read easily and unifies the code a bit.
I'll see if I can find the link of one of them I use regularly. If not I'll email you the binaries so you can check it out. The solution to formatting wars is to set up astyle to format to your liking on checkout, and format to project conventions on check-in and diff. Or just suck it up and use the project style while working on the project -- any professional programmer should be able to do that as a matter of course Yep - Exactly Also back in my previous life, you would have to have your code reviewed before you checked it in and the like.
But the questions always is whoes standard. Most of this code came from my project for Arduinos So it was formatted to Arduino Standards When in Rome do as Some toolsets are or can be configured to expand tabs on reads and compress to tabs on writes Then there is the whole concept of variable naming conventions.
But most of this code base was converted from code written in Basic originally by Jeroen Janssen Xan for the Lynxmotion robots and in my first conversion to Arduinos, I preserved his variable names as to make it easier to integrate later changes from that code base. As I am no longer worried about any new enhancements in the Basic code base, I may also continue the conversion of the variable names, to make it easier for myself to read the code and know what each variable is No one mentioned anything about formatting wars.
Kurt was just asking. Give it a look Kurt. We have a ten person committee that reviews all code done in my department here at DreamWorks. Now back on topic For instance member variables I just prefix with "m" just to keep the separate. We go the reverse. Once you check in your code, a battery of 60 machines build and run tests for about 10 minutes, and then we roll it into production. Without good unit tests, we couldn't do it, though. And if what you do is rendering, then it's hard to unit test "looks good" -- just like games have a hard time unit testing "is fun to play.
Well we build test maps that can be tested studio wide. So it does get out there quickly for testing. Though structure and profiling takes time to get approved. I'm not sure what you guys use but we use a proprietary thread analyzer and Zoom Yep - I am glad I don't have to deal with any of that stuff any more.
Did those code snipets I sent you format ok? How far off are we from each other in terms of formatting? I don't think the code formatting is too far different.
As in the terms of the other formatter The formatting also aligned all of the inline comments to a specific column and the like. The nice thing is it does not have to be exact. Right now I am looking at some perf issues Like do you notice something in these two functions? Note These were reformatted. They are from stream. This is some of the Arduino 1. This is used internally to the input processing for the streams. So far the simple calls off to usleep 10 ; Did not make any noticeable difference in the performance.
May increase to Just trying to find any places that are hard looping waiting for amount of time to happen. I'm still using the XBee code you sent me via email back in early February when I first started. Though I should note at the end of the XBee thread proc I did bump up the usleep time to if we are not receiving anything which helped out a bunch when I did a pass at performance while idle.
Yep, maybe not. As I mentioned, I may not even be calling these functions yet, but as I wanted a reasonably complete Serial object, that is based on the Print and Stream classes, I brought over most of it. Question: I was reading through the website you sent me a link for and I am wondering if I should be changing how I am calculating millis and micros.
The current stuff is based on some other stuff I pilfered ;. Will probably try that one out today. I was reminded about that function in another post over in the mech warfare section. It was just a thought. Sounds good! Finally figured out why the perf at idle on mine was high.
My first change I made intensived the issue. I changed my SSC driver to only output those servos whoes servo position changed. If nothing changed, then the commit does nothing. Finally figured in the main loop that when no leg is up in the air, it does not do any sleep, so before the only sleep happened when the serial writes might yield So I added in a delay in that case and now perf much better : Kurt P. Will check in this intermediate fix, but sill want to probably rework some of this.
Maybe things like, all legs are on the ground, and there is no new Travel request to move, then probably don't need to run through gait and balance and I added a return after the check for travel request in order to bypass the gait this weekend.
Although it worked and got me back into the main loop it was freezing in mid step once I let go of the joystick. Your P. I have to admit it was kind of cool to see it frozen in mid walk.
With the commander off I'm at 0. I also ordered the speaker you posted. I figured having a long stereo cable connected to a speaker on my desk isn't a long term solution.
It appears simple enough to pick a single pixel and query it's depth. There is a nice example already provided to start from. It would also be nice to use the camera streaming stuff you mentioned and interface with the color camera it has as well. We will see. So many options. Note: the speaker that I am actually using on the T-Hex is the one I purchased when I walked into radio shack It has much better control over volume.
It also has a built in battery with a USB charger The one from Amazon. Yep my perf is something like. Still working on idle but in same ball park. One last note. In preparation of adding the prime sense to the hex it was constantly suggested to overclock the processors to full turbo. Which is Mhz and Mhz for the two.
A few months ago Apple bought Primesense. Your guess is as good as any when it comes to figuring exactly what they will do with the tech in the future. But one thing is certain; It will be eventually be mobile, it will be at huge scale, and it will be awesome.
This listing for the Primesense Carmine 1. These 3D Webcams are no longer on the market. And we would love to pass them on to you at the best price on the market. But keep in mind that we are selling the hardware. We don't deal with the apps. What we can do is point you to the drivers and middleware. Anything beyond is left up to users to explore.
Run the script: ". Run the script: "sudo. Important: Please note that even though the directory is called Linux, you can also use it to compile it for bit targets and pretty much any other linux based environment. Run: ". Releases 17 tags. Packages 0 No packages published.
0コメント