At last year's AVC we were lucky in that it did not really rain during the competition.
I think that we had some minor showers at the awards ceremony, but that was the extent of the rain.
Since the weather has been so screwy this year I decided to provide some waterproof protection for my rover chassis navigation platform.
It turns out that a GLAD Potluck Size plastic container with an interlocking lid fit the navigation platform just fine.
After making the necessary cutouts to clear a couple of items located on the edge of the platform I was good to go.
The wife recommended that I cut the front section out of the lid and snap it onto the front of the container to help minimize water coming inside the cover when thrown-up from the track by the front wheels.
The only item I cannot waterproof are the two Maxbotix MB1240 sonars mounted ahead of the navigation chassis.
I have had the sonars get wet and they do not work well in that condition. They can be restored to functionality by cleaning with 91% rubbing alcohol.
Also, they tend to false trigger on the rain drops coming down in front of them so I plan to take them off if it rains during the heats.
I have included pictures of the rover with and without the cover below.
Regards,
TCIII ArduRover2 Developer
Without cover
With cover
Replies
Yea, water makes me super nervous. I think I'm going to be able to arrange everything so that I can keep the body on, but my wheels are not outside of the body, so they'll be spraying up and into the electronics. Hoping for a clear day...
@Kyle,
Me too:-)
Regards,
TCIII ArduRover2 Developer
False triggering from rain drops... Thanks for the nice discovery....(my rover is to be used outdoors mostly during the rainy season). Perhaps the code developers could add an adjustable false trigger parameter to eliminate false hits. The parameter would evaluate several ultrasonic hits as a group and if the average distance was within the set parameter, then its not rain. I'm also wondering if anyone has used the "non protected environment" sonars from Maxbotix and would you please share your experiences.
@RoboBill,
There is no easy way to spot a false trigger due to the fact that all detected returns are considered valid.
However there is a Sonar_Debounce parameter in the Sonar parameter section of the Full Parameter List that you can use to help mitigate false triggers by requiring one or more valid returns to consider an object detection to be valid.
I have used the Maxbotix MB1240 sonar on my rovers in a dual sonar configuration since before last year's AVC.
They have been found to be useful at avoiding objects at very low speeds such as barrels in a chicane course.
I do not recommend them for high speed use because the reaction time necessary to make a quick course change upon a detection compared to the speed the rover is closing with the detected object is really too great at speeds at or over 6m/s.
Regards,
TCIII ArduRover2 Developer
While there's no way to spot a false trigger with only one trigger, I think the point RoboBill was making was that one could use multiple samples to eliminate false positives. Various filtering approaches could do it. Maybe a median filter. Or something Bayesian.
The downside is that with filtering, it'd take much longer to detect an object. Delay between samples is already pretty big. That means you already have very little time to react to detected objects. Adding more lag means less time.
Hi BT,
The processing time required after one or more detections to make a steering correction is very critical especially at high speeds like around 6m/s and up.
That is why I recommend using sonar only at low speeds were the approach velocity is low compared to the processing time involved to make a steering correction.
The MB1240 has a maximum range of around 6m (~20 feet) against an ideal target and when you are travelling around 6m/s (~13 mph) the vehicle has around 1 sec (6m/6m/s) to make a course correction before impact assuming the first detection is at 6m. All of this is assumed to be under ideal conditions which in most cases do not existing in the real world.
In the future we are hoping to move to using LIDAR-Lite to gain increased reaction time due to the device's increased range over the sonar.
However, since this module has a very narrow beam, it will have to be swept across the front of the vehicle to see all possible obstacles in its oncoming path which eats up valuable processing time. Maybe the answer is to use multiple modules or have a mirror that scans the module beam rapidly across the vehicle's oncoming path and the module stays stationary?
Regards,
TCIII ArduRover2 Developer
Good advice. Data Bus has survived the rain, quite a bit of it. My electronics are mounted above the battery / frame on a sheet of Lexan. I use an RC body as well. That turned out to be adequate to keep things reasonably dry. It's a stadium truck so the wheels are well outside the body. My gyro is mounted up front, but under the bus body. The GPS is mounted to the underside of the bus body's roof. Previously I enclosed the GPS in a plastic floss container (http://www.bot-thoughts.com/2011/03/cheap-gps-enclosure.html). It might be worth finding a waterproof/water resistant ESC. Mine is probably water resistant; rubber gasket, reasonable seal, no sign of dust intrusion into the interior.