|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#46
|
|||
|
|||
|
Re: Which sensors should be used throughout the robot?
Quote:
Tom from 254 reports that he was able to get it down to ~2 ms in Java. I have never used Java on a FRC robot, so I can't confirm or deny. When 254 was doing thread.sleep, to time a loop in a separate thread, he reported up to 0.25 seconds of latency. Latency can be modeled as another source of noise. We used the fast response time to zero our claws in 2014, and other systems this year. Our control loops could hit somewhere in the order of +- 0.002 radians, and measure another order of magnitude more precise than that. If you are zeroing at 2 rad/sec, that means that you are going to add 0.002 rad of noise per millisecond of error. To hit 0.0002 rad/sec (below your positioning accuracy by an order of magnitude), you need to move at either 0.2 rad/sec or have less latency. I'm not sure where you heard the rumor that we over-clocked CAN, but we chose to not use CAN after benchmarking the latency of it and looking at the other options (and it being new). We couldn't figure out how to synchronize our control loops with the CAN send cycle, and after hooking up some external CAN monitoring equipment from my work, saw high peak latency on the bus. PWM is a known quantity, so we moved on. Reading sensors over CAN has the same issues you described, so we kept them connected to the FPGA so we could read them faster. (The FPGA is memory-mapped into the process's address space, which makes accesses fast.) Quote:
|
|
#47
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
I see now why such accuracy would be necessary, we never aimed for anywhere close to that level of detail.
So if I understand this DMA thing, the FGPA reads off the sensor values on an event happening, and the relatively slow accessing of the memory can be done later? Wouldn't that still give you inaccurate data unless you added on the expected change since it was read? Also, by upstreamed, do you mean it will be part of default WPILIB? Also, I read about CAN a while ago and iirc it isn't designed to have a specific frequency of changing the message frame, it just does it whenever it has time within a certain range. You can mess with the frequencies, but then you run the risk of maxing out the buffer. I would guess that it's intended for more complex data communication, and PWM is definitely better for a sensor that outputs a single value. As for the JNI bindings, wpilibJ loads up a library called "libwpilibJavaJNI.so", which I would assume is either the NI library or a bridge to it. |
|
#48
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
Quote:
Code:
void interruptHandler(uint32_t mask, void *data) {
INTERRUPTJNI_LOG(logDEBUG) << "Calling INTERRUPTJNI interruptHandler";
InterruptHandlerParam *param = static_cast<InterruptHandlerParam *>(data);
INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam Ptr = " << param;
INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam->obj = " << param->handler_obj;
INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam->param = " << param->param;
//Because this is a callback in a new thread we must attach it to the JVM
JNIEnv *env;
jint rs = jvm->AttachCurrentThread((void**)&env, NULL);
assert (rs == JNI_OK);
INTERRUPTJNI_LOG(logDEBUG) << "Attached to thread";
env->CallVoidMethod(param->handler_obj, param->mid, mask, param->param);
if (env->ExceptionCheck()) {
env->ExceptionDescribe();
}
rs = jvm->DetachCurrentThread();
assert (rs == JNI_OK);
INTERRUPTJNI_LOG(logDEBUG) << "Leaving INTERRUPTJNI interruptHandler";
|
|
#49
|
|||
|
|||
|
Re: Which sensors should be used throughout the robot?
For a gyro-IMU-AHRS solution we used the NavX MXP in 2015. It has worked for us, but we have had problems. We bought 2 boards. One has failed, will not initialize. We have had problems with the IO ports. Some are unusable and others are not reliable. We mounted our Roborio vertical. This forced us to use a cable between the Rio and the Navx. We use the NavX for 2 tasks. The NavX tells us which way our robot is pointing. (not which way our robot is moving). Second, it tells us if the robot is tilting. We fell over 3 times in competitions this year. We use the navx to stop us from tipping. If the the angle of tilt goes beyond x degrees, reverse the drive motors. It works.
For 2016 we are looking for a better IMU. We recently purchased a Arduino Shield with a Bosch BMO055 orientation sensor. It has a 3 axis accelerometer, gyro and magnetometer. Plus a Arm cortex M0 core running fusion code. Easy set up. Initialize the I2C port, write to a few registers and its running. We bought the Arduino shield for testing. Will use the Adafruit board on the robot if we go with it. Only have 1 hour of testing. Gyro, accelerometer fusion looks rock solid. Add in the mag and it is not good. Interesting is the linear acceleration output. It's a little noisy but with a little clean up could give direction of motion. Not suitable for distance. Better than the Invensense outputs. Looks good but you never know until it's on the robot. |
|
#50
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
Quote:
I wasn't aware of the Bosch sensor but it looks cool. Hopefully we'll see some additional MXP boards based around more sensors for this coming year. |
|
#51
|
|||
|
|||
|
Re: Which sensors should be used throughout the robot?
Quote:
Kauai Labs 2371E Nimualu Road Lihue, HI 96766 The updated firmware (it'll be loaded on your replacement board) includes the new Omnimount feature which enables vertical, horizontal and upside-down mounting, and has some reliability improvements. The addressing of the Digital IO pins has given folks some trouble, it has gaps in the address space, documented on this page. If you have details on a port that isn't working, please send that information along, too. We're getting ready also to release new Java/C++ Libaries w/SPI support at 2Mhz, with that enhancement the measurement latencies and RoboRIO CPU usage are very low. Which board are you are using w/the Bosch sensor? I'd like to compare the linear acceleration values it generates with those from the navX MXP. I'd agree Invensense has some work to do on accelerometer noise levels on the MPU-9250, but wasn't aware the Bosch sensor specs were that much better, am very interested to hear your findings. Thanks, - scott |
|
#52
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
Quote:
|
|
#53
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
Quote:
|
|
#54
|
|||
|
|||
|
Re: Which sensors should be used throughout the robot?
Quote:
However in testing it's been discovered that the various communication peripherals on the navX MXP are experiencing bus errors sometimes when the RoboRio is starting up (e.g., upon initial power up, and when "Reboot RobRIO" is selected in the driver station, but not when restarting the robot code). In these cases, a few seconds after the reboot occurs (about one in every ten times) I2C circuits on the navX (including - notably - the internal I2C bus which communicates with the MPU-9250) experience bus errors. My suspicion is that problems occur when the robot app opens a MXP port before the RoboRIO FPGA code that manages the MXP port has completed initialization, and the result is the navX MXP experiences random noise during that time. And the fact that an internal (non-MXP) I2C bus is experiencing error implies the noise is on the power/ground which are used to pull up the internal I2C bus lines. I haven't got it captured on a scope yet, but my hunch is there's a noisy MXP ground sometimes during RoboRIO startup. [These errors can cause navX MXP comm to the MPU-9250 to lockup. The visible symptom of the internal I2C bus lockup is that only one of the two Green LEDs on the navX MXP will be lit up (in normal operation, both LEDs should be on).] So the reasonable conclusion is that when using MXP-based SPI/I2C, the navX was being exposed to more of these glitches than when using non-MXP communication, and every now and then could no longer talk to the MPU-9250. The recent navX MXP firmware has added code to detect these bus errors and reset the affected communication peripherals. In testing, we were able to reproduce the error, and demonstrate successful recovery by the navX MXP firmware. Based on that, I believe the latest navX MXP firmware is resilient to these transients. However these transients could impact other MXP devices too, so the plan is to document this and send the findings to NI and to the ChiefDelphi community. I'll send out a general update to ChiefDelphi once the latest navX MXP firmware has passed all our tests and is ready for release; I'd recommend retesting at that time, believing the above was the root cause for the sporadic startup failures you saw. |
|
#55
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
I didn't carry it out but it was an easy upgrade for ours. I'll let Scott elaborate on the process.
|
|
#56
|
|||
|
|||
|
Re: Which sensors should be used throughout the robot?
Quote:
An announcement will be posted on ChiefDelphi once the released version of this new firmware and the firmware update is ready for public consumption. |
|
#57
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
Quote:
|
|
#58
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
Quote:
Anyway, this thread has been outstanding so far. I've always had trouble finding inexpensive sensors that work well for our system and have relied on what I've seen on other robots. For instance, one of our favorites was always the sick ZL1 series that we ordered from automationpartsexpress.com for under $40 (credit to 33 and Jim for finding them), but they seem to be out of business. It'd be fantastic if people kept suggesting sensors they use. So far, I have this list: Sensor Type Part # Website Encoder, multiple shaft, multiple counts per rev AMT10-V http://www.cui.com/product/component...ar/amt10-v-kit Magnetic reed switch / position switch 59140-010-ND http://www.digikey.com/product-detai...0-010-ND/43977 IR reflective 42EF Rightsight http://ab.rockwellautomation.com/Sen...tSight-Sensors IR Reflective / cheap 30 CM E18-B03P1 http://www.amazon.com/6-36V-Photoele...lectric+sensor Hall effect switch / position switch WCP-0971 http://www.wcproducts.net/sensors Hall effect switch / position switch MC1104 http://www.amazon.com/Effect-Sensor-...y+Switc h+NPN SICK photoelectric Z series IR sensors ZL1-E2415 Not available So we've got IR reflective and hall effect reed/limit switches. What about cheap through beams (that aren't garage door sensors)? One of the nice features on the Allen Bradley RightSight was the manual adjustability so that it would work with reflectors, or even colored tape. It was also capable of 10000+ samples / second. What else is out there with those capabilities? Last edited by Tom Line : 29-07-2015 at 16:21. |
|
#59
|
|||||
|
|||||
|
Re: Which sensors should be used throughout the robot?
I'd go back through this thread as well.
http://www.chiefdelphi.com/forums/sh...d.php?t=117219 Some very good suggestions by a lot teams. |
|
#60
|
||||
|
||||
|
Re: Which sensors should be used throughout the robot?
I'm not a programmer, but I would say a gyro would be very useful if you want to drive field-oriented.
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|