Skip to main content

Frustrating Week

It has been one of those weeks where you take three steps forward and two steps back.

I got the computer for the prototype. I is targeted at installation in a car. The case is a heavy (!) aluminum with fins for cooling when installed under a car seat. The overall weight is 7-8 lbs. I wanted to order a COTS computer so save time and effort. I need to be working on software, not messing with hardware, either robotic or computers. But I didn't check out the weight when I ordered this beast. The Wild Thumper is supposed to handle an 11 pound payload.

I have the Pololu Simple motor controllers working and can control the motors either using RC or a computer. I ran the Thumper around the front yard and in the street using the RC control. I am on a cul-de-sac and there is an island in the middle of it. The Thumper  limbs the curb nicely. Shouldn't need that with competition but nice to know it has that power.

I put the controllers on the Thumper platform along with some euro-type terminal strips for power distribution. Then reaaranged all of that to mount the computer. And reaaranged it all again for another reason. That was at least 0.5 step back.

I tried running the robot under RC control with the computer mounted. That blew the motor controllers. I know they were marginal but I had them on hand. They are rated for 7 amp continuous and higher for stall current. The three motors on the side of the Thumper are rated 7 amp stall for a total 21 amp stall. I thought the controller configuration for acceleration ramping would limit that current. It didn't. Ordered some new higher power controllers to see how they work.

Also worked with the Pololu IMU. That was another step backwards. The IMU generates output faster than can be read using the USB-I2C adapter on the computer. The slowest the IMU generates output is 100 readings per second. The system would need to read 6 data points (3 gyro and 3 accelerometer) at that speed to keep up. There is a FIFO capability so up to 32 readings could be buffered and read in bursts. Basically, I did not want to mess with it. In part because I though my time would be better spent on some other problem.

I found that Phidgets has a series of USB devices that includes spatial sensors. They are configured specifically for connecting to PCs. Their software capability looked interesting and they supported C/C++ on Windows. I ordered their 1042 basic motion sensor. In a few hours on Friday night I wrote the code to set the configuration and acquire data.

The 1042 has a gyro, accelerometer, and compass. I cannot use the compass in the competition. The sampling rate is set through software. The 1042 internally accumulates readings for the specified sampling period. That simplifies using it. That is one of the steps forward after a step backward.

If I had not just ordered the new Pololu motor controllers I would be tempted to order a Phidgets motor controller. The Phidgets' software stack is all integrated so using one type of device shows how to use any of the other devices. (In fairness, the Pololu controllers do the same. Getting the Simple controllers working was easy after using a Maestro controller.)

Back to the computer and its weight. I have another ITX case from an earlier project. The mother board and hard drive are easily moved to it. But the power supply from the car computer won't fit in the case. I need to decide if I should get a power supply that would work and make a lighter computer. Of course that is exactly what I was trying to avoid - building up the computer hardware.

Another piece of electronics I got working was a key fob RF transmitter and its companion receiver board. It operates on 422 mHz. A robot for the competition must stop all motion within 1 second of the press of a remote control button by the judge monitoring the robot. (In a swarm, all the robots must stop!) I have a concern whether these will work acceptably in the competition. Apparently one team last year had problems with their RF pause button and had to switch at the last minute to RC control. That would be nearly impossible to do for a swarm of robots. To many last minute changes. Regardless, I need something for the prototype so this should work for now.

The receiver connects to the Simpler controller's analog input. The controller can be configured to automatically stop the motors when the signal is received. Both the analog input value and an status bit can be read by the PC so the robot knows of the pause request. The robot can then shut down any other moving parts, such as a picker or panning camera.

Speaking of camera, I took a number of pictures in local parks. One park had a construction area with orange mesh fencing so I got a number of pictures of it. That type of fencing is used to mark the perimeter of the competition area. The robot has to avoid getting to near the fence of the judge will stop it. Also got picture of some lamp posts and pavilions with columns. The competition area has similar features that can be used for localization.

Now to see what happens with the computer on the robot with the new motor controllers. Fingers crossed!


Popular posts from this blog

Sensor - Accelerometer & Magnetics

Just as I was finishing my first look at the accelerometer and magnetic field sensors a couple of threads cropped up on the Android Developer's group:

I had the basic code working so dug a little deeper into the rotation routines and the timing. I posted responses on the threads but want here to dig into the details more.

First some observations applicable to my G1:

The sensors report approximetly every 20, 40 and 220 msec for FAST, GAME, and NORMAL.
A sample may be missed for a specific sensor but usually one of them will be generated - but sometimes all can be missed.
The magnetic field sensor is most reliable with only a few drops. The other sensors are dropped considerably more often.

A caveat in all this is the way I setup the sensor handling may make a difference. I have a singl…

Programming Languages Used for SRR

I asked at the SRR Challenge about the languages and vision processing used by each team. Here is what I found:

Team Language                       Vision Processing
Intrepid                         C++ / Matlab                                           Kuukulgur                     C++                                          OpenCV Mystic                           C++                                          RobotRealm SpacePride                    RoboRealm state machine          RoboRealm Survey                           C++, Python                             OpenCV Middleman                     LabView                                   LabView UCSC                           C/C++                                      OpenCV Waterloo                       C++, Python                                             WPI                              C++                                                              Wunderkammer             Python                                      ROS …

Shifting Gears - iRobot Create

I'm shifting gears to robotics. Awhile ago I got an iRobot Create. Its basically a Roomba vacuum cleaner with the guts removed to make a cargo area. In this area is a 25-pin connector that provides power, TTL serial port, digital and analog I/O.

I also got a Command Module (CM) which fits onto the connector. The CM is an Atmega 168 processor that adds some additional I/O. It can be programmed to control the Create. I did so and basically reproduced the wandering behavior of the Create. It move around, bumps into things and turns away from what it hit. I added some additional behaviors such as if it got trapped, i.e. caught in the same place for a period of 10 secs, it would move to extract itself.

I want to do more with robots, such as entering in a RoboMagellan contest. That requires an outdoor capable robot that does a lot more than bump into things. A key component to me is vision. Maybe I could do that with the CM and another processor (like the CMUCam) but I really didn't …