Swarm of Rover 5's + Ardunio Mega2560 + Dagu 4-Motor Controller + Romeo + Fans

Let's Make Robots Robots
1

Here is my new post to document the details of my plans.  I'll update my progress in implementing them here as noteworthy milestones are reached.  My goals with this project are:

1. Switchable between autonomous and remote control from my laptop, via XBee.
2. App#1 is to map out the room (including furniture), and display the map in a Java program running in my laptop, that I've already partially written.
3. Autonomous exploration is via a steerable front-looking Sonar mounted on a servo, and IR transceivers on the sides to detect imminent tangential side-collisions. The sonar is accurate to 1" in 10'.
4. Navigation is via a 3-Axis Magnetometer (which I already have working to +/- 2 degrees), combined with "following walls" by turning the Sonar (via its servo) towards the nearest wall, to maintain a constant distance running parallel to the wall, and periodically checking the distance to the upcoming perpendicular wall. I'll thus proceed to pick a coordinate system for the room, to determine its dimensions, and to maintain a desired path across it.
5. App#2 is to pick a point on the map, and then the robot (ultimately more than one) will hunt down balloons laying about on the floor in the room, and herd them to that spot, using 2 "Ducted Fans" from R/C electric Jet Planes. My battery at present is 2S 2.5Ah 7.4V 20C Li-Po, with the likelihood that later on I'll replace with a pair of batteries wired up in parallel.  I have to match the Fans' current/voltage with the battery (so I could upgrade the Fans and battery together), while ensuring that I don't draw too much current through the Romeo or whatever other Motor Controller I use to drive the Fans (at present a Dagu 4-Motor Controller).
6. App#3 is for multiple similar robots to collaborate in sharing new map-data discoveries (i.e., the sofa), and locating and herding the balloons, sharing data via XBee Mesh networking between themselves and to the laptop.

More on all this here as I progress.

=Cliff

Creates Room Maps & sends them to laptop w/XBee, receives room location from laptop, locates balloons w/PING, & herds them w/fans to that spot

  • Actuators / output devices: Rover 5 w/4 encoders, steerable PING
  • Control method: XBee
  • CPU: ROMEO, Arduino Mega2560
  • Operating system: Arduino
  • Power source: 8.4V LiPo 2-cell
  • Programming language: Arduino
  • Sensors / input devices: PING, 3D Magnetometer/Compass, IR wall detectors
  • Target environment: indoor
This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/swarm-of-rover-5s-ardunio-mega2560-dagu-4-motor-controller-romeo-fans
2

EncoderCount Analysis videos posted

Videos of my recent EncoderCount analysis findings are here:

     http://www.cliffolling.com/ArukuGo/EncoderInvestigations1/encoderCountOutputChecks.html

They show my current efforts at using my Java program to do “device characterization” on the Wheel Encoders to understand the relationship between PWMcountOut and EncoderCountIn.

As Duane Degn predicted, the Arduino Mega2560 has grave difficulties with my current program when all 4 wheels are turning, and thus all trying to run their respective ISR’s simultaneously.  To wit, with 3 wheels turning, the program will run ok for 5-10 min. then stop responding to user input (= overflows its stack space w/too many pending ISR calls?).  With 4 wheels turning, the program stops responding within 1-2 sec.

I’m in the midst of replacing the polling that I’ve been doing using “while (prev - millis() < someCount) …”, that loops to determine when to do “sample-and-then-clear the current Encoder counts”, with the code that’s executed by a Hardware Timer, as described here:

    http://www.engblaze.com/microcontroller-tutorial-avr-and-arduino-timer-interrupts/

Hopefully this will let me run all 4 ISR’s full-time.

On the other hand, as you can see in the videos, the EncoderCountsIn aren’t the most stable, or all that consistent.

Thus, it seems some “disregarding of rogue values”, “waiting for it to settle”, and “the value is within 10 of what I want, so I’m happy”, needs to occur in any code that wants to make effective use of the Encoders.

I’ll add my initial construction details next (i.e., tips for getting the wheels mounted), then write up my next Java program addition, which will be scatterplot’ing the PWMcount vs. EncoderCount for each wheel, and take note of where the clumps and gaps are.

I.e., as you can see in the videos (the Encoder counts there update once every 5 sec.), changing the PWMcount by 2:

(a) does not necessarily give a repeatable EncoderCount change, as the latter seems to sometimes “stick” until a PWMcount of ~10 has occured, and…

(b) gives a pretty big change in EncoderCount/sec., i.e., a change of 7-10 EncoderCounts/sec., and the change is different for each wheel, and different for varying parts of the PWM range for a given wheel as well.

All this will be clear from the scatterplots that I’ll post next.

So from my scatterplots, I may just make a desiredEncoderCount->OutputThisPWMcount translation table for each wheel, and use that and just disconnect the Encoders once I have my plots.

Let me know if you see some situation where having the “live” EncoderCounts would be better than having only a translation table of their values per PWMcount.

In the meantime, Happy Thanksgiving,

=Cliff

3

New Rover 5 Home Page posted

I made a home page for my robot that gathers up all my assembly and investigation photos and videos here:

http://www.cliffolling.com/ArukuGo

Over time I’ll be adding additional web pages under that one. 

I.e., at the moment I’m implementing a “ScatterPlot” screen in my Java program, to gain a clearer understanding on the relationship between PWMoutToMotors->EncoderCountPerSecInFromMotors. 

To wit, I’ve already found that decreasing the PWM slightly seems to have no effect, while increasing it slightly does (at least sometimes) cause an immediate change in EncoderCountPerSec.

I’ll post here again when I’ve added the ScatterPlot web page under the page above,

=Cliff

4

Checking EncoderCount in Timer-driven ISR makes a big difference

As I wrote above, I move my EncoderCounts-checking code from inside loop() to inside “ISR(TIMER1_COMPA_vect)”, and set up TIMER1 to call that ISR once per sec.

This (somewhat) fixed my program’s behavior from hanging after ~1 sec. of 4-wheels-running operation. 

I.e., now I can fiddle with my PWM settings and monitor EncoderCountsPerSec for 10-15 min. before the program hangs.

Note that when it hangs, all PWM outputs continue (read: the robot keeps moving), rather than being shut off (= crash at full power into the nearest wall, etc.)

So if no one suggests how to tighten my code up further to completely resolve this, I’ll look into implementing auto-Reset’ing the program every 10 min. or so to avoid this.

=Cliff

5

Added a few Encoder Investigations#1 photos

I added two new photos to my Encoder Investigations# 1 page:

http://www.cliffolling.com/ArukuGo/E…putChecks.html

Hopefully by next weekend I’ll have made some (visible) progress with my Encoder data plotting, so stay tuned.

=Cliff

6

Robot Control Java Program Update


At long last, I finally have an update on my Robot to share with you.

After some mighty effort, I’ve completed the “Wheel PWM vs. EncoderCounts” Data Collection that I’ve been envisioning for 'lo these many years. 

To see a writeup of my current progress and next steps, please go to:

    http://www.cliffolling.com/ArukuGo/

and click on the Graphs screen shot under:

    Encoder Investigations #2

Please post here if you think that the Wheel data that I’ve now collected and generated will be useful to post here.

Thanks,

=Cliff