Voltage control (re)calibration

Odd...
I cannot explain why but the voltage control routine is no longer calibrate. And replacing the ADC has not resolved anything. I need to go through the whole process. Maybe, I will just look for the "low battery" therehold, that could keep it simple...

Code conversion

Since the BS2px is faster than a simple BS2, all the time sensitive commands need to be converted.

I modified each program that achieve a basic task :

• Servo control
• Ping))) distance measure
• Serial communication
• Voltage control

The last one was actually the tricky one. Maybe I should say that it IS the tricky one because the calibration is wrong now, and I don't understand why... The data collection is done with a SHIFTIN command, which is not time sensitive (synchronous). I tried to slow down the execution with PAUSE 10 instrutions, with no success. I even touched the potentiometer that is at the input of the ADC0831 with no effect on the result in the Debug Terminal.

What if the ADC had been damaged by the old BS2 ? Well, thanks to ebay, a new ADC should be in the mail soon...

Besides that, all the bricks are available to program complex behaviors with the new microcontroller.

Maintenance needed...

I started to work on the wheel encoders again. I tryed to record simpler motions, like straight lines for example... Graphic representations on Excel seemed consistent but I had to stop due to a Basic Stamp failure !
Serial communications issues, weird servos acting... If i leave the robot off for a little while, it seems to run ok, but it's getting worse and worse as I use it...

The BS2 is 6 years old now... EEPROM end of service ? This issue was the occasion to install the BS2PX I got months ago. I just wanted to make sure there is no external problem on the robot that could harm the new microcontroller...

Et voilà !

I just ran a couple of simple programs which didn't rely on serial port commands. What can I say ? That thing is obviously way faster than a regular BS2 !
What's next : PX tests, existing programs conversion, and go back on the wheel encoders !

La reprise !

Après un nouveau déménagement, il est plus que temps de se remettre à bricoler... Les wheel encoders ne sont toujours pas au point, et ces capteurs apporteront beaucoup au robot. Au boulot !

Reprise en douceur avec une base de routine d'initialisation. Une base seulement, car je projette d'étoffer ce programme pour contrôler l'état initial du robot, toutes missions confondues : énergie, capteurs, actionneurs, constantes... Un programme standard qui trouvera facilement sa place dans un des slots du BS2PX qui patiente toujours dans son emballage.
Fonctions de la fameuse routine : contrôle de la tension, puis alignement des roues sur les codeurs (détection d'un front descendant). Simple, mais cela devrait permettre de démarrer les programmes de wheel odometry dans des bonnes conditions de mesure.

Après cette pause estivale, j'ai à nouveau remarqué que le neutre des 2 servos de roues a bougé. A cause des batteries, leur potar de réglage n'est pas accessible sur mon Boe-Bot. Pas sans démontage partiel en tout cas... Et pourquoi pas un neutre logiciel ? ça coûte seulement 2 constantes...

Wheel odometry : hundreds of tests

I started this robot session by "re-centering" the servos : no rotation for pulses duration = 750. A very basic and mandatory tuning. I ran the calibration routine "calibrate_all.bs2", and this time, I could take advantage of the sun light that is supposed to give better results because of the photoresistor. Let's assume that the term "sun light" is appropriate for this cloudy sunday afternoon in Paris...
Today's value of SDIRINC = $719C
This is similar to the previous calibrations : $70F9, $7211, $71AC...

Okay... Then I spent a good amount of time running test programs, slightly adjusting the calibration values and tuning the "wheel_odometry.bs2" program.
Each run is recorded using the wheel encoders, and these coordinates are imported into Excel to compare the record to the real path :

I managed to find some acceptable SDIRINC values, but they seem to be "dedicated" to a type of motion :
- $6A40 for continuous motion (rotation using the 2 servos at a different speed)
- $7000 for "discrete" motion (rotation using one servo stopped and one servo at full speed)...

Obviously, the wheel encoders require some extra work before this endless project can move to the next step !

Wheel odometry for beginners

This is the third and last step of the wheel encoders training provided by Parallax. We are going to learn how to record the robot path : it's called Wheel Odometry.

After the usual program modifications to fit my robot specs, the "wheel_odometry.bs2" is loaded into the BS2.

I tried to run the program with the default calibration values. The Boe-Bot follows a clover shape while each encoder pulse is recorded and stored to EEPROM. Then I used Excel to plot the path because the coordinates were not properly centered when using the Parallax "botplot.exe". At first, the result seems to be good, just like the manufacturer example !

Actually, the robot was not following this path... Need calibration data ?

The program accuracy relies on 2 constants that are specific to each robot :
- SDIRINC : this value is given by the "calibrate_all.bs2" program that I used after mounting the sensors.
- SPOSINC : this constant depends partly of the distance between the wheels. This distance is normally about 10 cm, but on my robot, the wheel servos are mounted outside of the chassis and there is a camber angle due to the bot weight. The constant had to be recalculated :

After a couple of tests, I came to the conclusion that my calibration constant SDIRINC is false. I kept setting this value lower and lower to get a plotting that looked like the actual robot path. The initial value was $7211 (dec 29201)...

What I want now is to improve accuracy. To do so, I'll try another calibration with day light (because this part of the calibration process uses a photoresistor...).
If I can't have better results with the "math" method, I will have to work with dichotomy in order to approximate this value. I must admit that I did not get exactly what constant produces what effect on the measure... Maybe understanding this could be a good start.

Well, I am closing this post with more questions than answers...

Wheel encoders, part 2

Bonne Année !

Last post was about wheel encoders calibration. Following the Parallax instructions, I got 64 bytes of data and 3 constants which are specific to my robot.

Today, I tried the provided "proactive" navigation. The "Wheel_Motion.bs2" demo program has been modified to meet the configuration of my Boe-Bot :

- Calibration data bytes and constants

- Pin assignment

This routine works quite well ! The program starts with a 1 meter square motion, each side being achieved with speed ramping, a angular correction. The robot finishes its path with a constant error : a 3 cm gap and always in the same direction. This value could probably be improved with a better calibration. I could change the rubber bands on the wheels or execute the calibration procedure on the floor (instead of the desk) to get the same friction...

Please note that to get this constant level of accuracy, the start position has to be constant either, and the wheels have to be at the same angle relatively to their sensor.

Then I ran the complete demo sequence : square, octagon, 2 spins. The final position and azimuth are still constant. Of course, errors keep adding at each path, like always on a robot.

By reusing this program I will be able to have the robot to come back to its mission starting location. Example of behavior : leave the base to find a labeled obstacle, push it down, come back to base". To do that, it will have to monitor/record its path during the beginning of the mission.

This should the next step in this encoders training...