My name is Dominic Jakubowski and I am the team Captain of the Robosapiens, team 4779. We are working with the KOP High Resolution Ultrasonic Range Finder (MB1013). We are attempting to create an auton program where the ultrasonic sensor would determine if we have pegged a gear at the gear elevator, so that we can release the gear, move backwards a set distance, and shoot. We have never worked with sensors before so this is a new adventure for us. I have found some examples in the NI Example Finder, but I still do not understand what portion of the code goes where and if any of it really applies in auton. Thank you so much for your help.
This is an old Post, but if anyone needs help with the ultrasonic, we did figure it out. Let me know if you need help.
Sent from my SM-T810 using Tapatalk
Hi Mr. R^2, my name is Maximus coach of the newly formed team 8067 The Alpha Lab.
We are new to this whole FRC adventure with not a lot of programming experiences under our belts. We were inquiring about how to use the ultrasonic sensor MB1013 and found your post; our goal is to use the sensor in the autonomous mode so we can determine when we have approached an object close enough to trigger a 90 degrees turn. So, we would like to know if you could help us out figuring out how to use this sensor using Labview. A few examples would be very handy. I know this post is a bit old, but in case you read it, can you please give us a hand?
Have you looked up the examples, maybe this mb1010 example would also work for the mb1013. There are analog and digital examples, I thought I had better results with the digital version. Examples run easiest by connecting to the RIO via USB, and then using the Run arrow button to start the example.
Ultrasonic sensors / range finders can be very difficult to use in FRC. Keep in mind the velocity you are traveling, the latency of the sensor reading, and the general instability of ultrasonic readings that usually require a filter that increases latency even more. Combine the three and you may find that you have to be traveling far slower than you’d like to get a decent reading in time.
For instance, at 5 feet per second, and a sensor latency of 100 ms latency, plus processing ~10 ms, you’ll be acting on that reading approximately 6.6 inches after you received it. Many times a more accurate way to do it is to allow your robot to stop, take the reading, then adjust your next move based on your location.
Hi ngreen and TomLine! Wow, thanks for a prompt answer! Your answers are valuable and we will definitely keep those in mind. We did, in fact, looked up the Labview examples and we weren’t sure how to use the examples seen in this picture
in an actual autonomous routine. We understand this example is meant to be a standalone program for testing via the USB, but I just don’t know how to break down the code provided in the example in my main program. Do I simply copy-paste it somewhere, or should I compartmentalize it in the different VI’s namely, Begin.VI, TEleop(or autonomous), and Finish.VI. Also, we understand that this forum is not meant for begging for hands-on solutions, but a little help to a starting team would be much appreciated. We’ll make sure to present a program next time (at least what we tried to program) so the learning process becomes more valuable to us and others who may be in the same situation.
Merci beaucoup pour votre aide!
There is a LV Tutorial on integrating the examples into user code:
If you have trouble with it we can provide a more explicit example.
You don’t use it as-is because the stand-alone program aspects are already being done by the default user code.
This will give you a good idea of how to structure your code:
The leftmost block of code goes in begin. This example is a Digital input / output and not sonar, but the idea is the same. Make sure you use your sonar specific VI’s and not the DIO VIs shown here. The middle block of code goes in Teleop. The last goes in the Finish.
This is where you open hardware to use later. You’ll need an open VI and a setref VI. The Open VI sets the hardware info, and the setref gives it a device reference so you can call it elsewhere in your code.
This is where you actually read the data. Here you’ll use a getref VI, using whatever you named your sensor. Then you a Get VI to actually get the data.
There is a second option - the teleop vi runs at the same rate that it receives packets from the driver station - around 20 ms. If you have something that needs to run faster, or runs slower, you can instead put a while loop in the Periodic Tasks VI and do the same there. The difference is that teleop is always constrained to about 20 ms a loop. Never put a loop inside the teleop VI, because it will delay the VI and cause your robot to be temporarily disabled when it doesn’t communicate consistently.
Do what they did here. Just use the particular ultrasonic sensor.