#Robotc multitasking Bluetooth

I sure wish it was as easy to get messages from a brick to a PC. Run the programs as per the instructions for the samples above, and observe the results on the NXT screen. These are essentially the same programs as above, except these will allow you to send through 3 values where the above programs would send only one value at the time. If you do that, you can nicely repeat the procedure and wait for a message to come in. The only issue here is that this mailbox will hold only one email, so old messages are overwritten when new ones come in.ДЄfter storing this value in a variable for further usage, use ClearMessage to set the values back to 0 erase your email inbox. But like email, messages are stored for your review until you open them. Think of it as emails you get from a friend. Got that right? The key is that you have to keep looking for messages on the receiver part. When you do this, the number 23 shows up on the receiving NXT. In some occasions you want to send some basic numbers from one NXT to the other.

#Robotc multitasking Bluetooth

If I start by putting data item вЂњfвЂќ into the first array вЂњboxвЂќ, then f will overwrite e before I have a chance to move e over into box 1.This page will show you two sets of programs that demonstrate the most basic Bluetooth example programs for two NXT with RobotC. With data in it, weвЂ™ve got something like this:Д®ach time we go through the loop, we need to shift each value one box to the right so that our new piece of data can slot into position 0: In picture format, weвЂ™ve just created the following (recalling that when programming, the first item in the array has an index of 0): Start by defining an array to hold 5 values: int ultrasonicArray ThereвЂ™s nothing built into easењњ or RobotC to do this, so you have to write this yourself.

Store that median in the array instead of the junky data actually returned from the sensor.

Use that median in the current PID loop.

Calculate the median of the 5 stored values.

When the sensor value of the current iteration is sufficiently far off from your chosen target (or the previous value), you say, вЂњHey, thatвЂ™s junk.вЂќ.

Keep a running array of the most recent 5 sensor values.The programming steps for filtering the data are like so: Since these PID iterations are taking place over a VERY small period of time, using replacement values for 1 or 2 numbers every now and then does not cause undue problems (or any, in our usage of it thus far).

From other research I did on the VEX Forum, people have indicated that these noisy sensors rarely produce more than 2 junky pieces of data in a row. So what is a median filter? ItвЂ™s simply using the median of the previous x-number-of-values as a replacement for junky data. (For background, a Kalman filter is useful when youвЂ™ve got a complex, dynamical system with multiple sensors providing input.) A search of the VEX Forum will return many threads mentioning things like Kalman filters, and (a) from what IвЂ™ve read and (b) my experience using it with the ultrasonic sensor, IвЂ™ll confirm that a median filter worked perfectly. IвЂ™ll cut to the chase here, since youвЂ™re probably reading this article in order to save yourself some time and background reading: For simple filtering of data like this instance, a median filter is just fine. ThatвЂ™s when I started researching techniques for filtering sensor data. I mean, how can you adjust left- and right-side power to maintain a fixed distance from the wall, if you randomly get complete junk? You just canвЂ™t. What to DoД«ased on what we saw in the table above, without the ability to filter data, the concept of using the ultrasonic sensor to drive straight would be pretty much a non-starter. This fact makes the sensor distinctly less useful. UhhhhhвЂ¦ problem? And thatвЂ™s when I learned that certain VEX sensors-including the ultrasonic, gyro, accelerometer, and potentiometer-have a tendency to return вЂњnoisyвЂќ data.

We were using the RobotC datalog (as I recommend everyone use when writing a PID loop) and looking at the error value each time through the loop. We were making use of a PID algorithm, increasing or decreasing power to one side of the drive train depending on whether the robot was further away from or closer to the perimeter than our chosen target. It started when we were trying to use an ultrasonic sensor to drive the robot straight down the field, keeping a constant distance from the field perimeter (ultrasonic sensor attached to the side of the robot). My team has been learning more-sophisticated programming of late, and I thought IвЂ™d share one topic we recently dove into: filtering noise out of sensor data.