Autonomous Rover

[GrumpyOldPizza 15]

After a half way successful entry in the AVC 2014 competition I finally have the time to write a few words.

 

The rover is build upon a rather cheap RC car, that however is a very reasonable platform for the project, the Turnigy 1/16 Monster Beetle.

 

 

The core computing platform is a Stellaris Launchpad with RobG's excellent LCD booster pack, which doubles for me as LCD and microSD unit.

 

There is a GY-87 IMU, which consists of a MPU6050 Accel/Gyro and a HMC5883L Magnetometer, plus a BMP180 Bario (which I did not use, regrettably). The SW on the LM4F120 is able to read the MPU6050 at 1Khz and the HMC5883L at 75Hz (which is more than 50% of the I2C bus bandwidth). 

 

There is also a uBlox6 based GPS uint, the VK16U6 (in case you are wondering). It' operates at 4Hz update rate. Why 4Hz ? The ublox6 has an advertised max update rate of 5Hz. However at 5Hz SBAS/WAAS is not working, at least for me, and not with 12 satellites in perfect view, plus either PRN133 or PRN137 (if I recall correctly). Going back to 4Hz solved that ;-)

 

 

There is a 13 state EKF on board that is run at 250Hz (in the pre-race configuation). The path follower is a simple "Pure Pursuit", with position input, and using the magnetometer for heading estimation. The steering is done via rather simple poportional control derived from the steering error, rather than a PID ... mainly because I ran out of time programming/tuning the PID, and because it turned out to be good enough. 

 

 

The vehicle was tested at 20Mph speed and finetuned for that upper boundary. The contollering mechanism did not try to adjust the speed other than an initial gradual ramp up to top speed, and the breaking at the end. Experiments showed that flipping the vehicle in gradual turns was not an issue, and that the slippage compensated for the high speed good enough.

 

In the AVC 2014 race config we dialed the speed back to 12Mph and 15Mph respectively. We did one run using the EKF, and the subsequent runs using GPS only (with forward predicition). 

 

The downside was a mechanical failure which causes us to fail on one of the 3 rounds. He an image as to what the underlying issue was:

 

 

The vehicle jumps, but still tries to navigate in mid-air. In one of those jumps the front left C-Bracket got nuked, as the front wheels were pointing all the way left ...

 

Perhaps next year, at AVC 2015 there are more entrants using a TI Tiva ;-)

 

- Thomas

 

 

[bluehash 1,581]

@@BizzaBoy Thanks for documenting your progress. This will only give you experience for the next round.

[GrumpyOldPizza 15]

@@BizzaBoy Thanks for documenting your progress. This will only give you experience for the next round.

 

I already got a long laundry list of things to do different, where I either ran out of time, or simple didn't see what was missing.

 

Anyway, part of the software stack was to get a better FAT file system going (so that I could log raw sensor data at full speed). I'd like to put that out there, but would need a few individuals to perhaps look over the code and help massaging it so that it's useful outside my own little sandbox.

[bluehash 1,581]

For the Fat system, look into Elm Chan FatFs. 

 

I already got a long laundry list of things to do different, where I either ran out of time, or simple didn't see what was missing.

 

Anyway, part of the software stack was to get a better FAT file system going (so that I could log raw sensor data at full speed). I'd like to put that out there, but would need a few individuals to perhaps look over the code and help massaging it so that it's useful outside my own little sandbox.

[Mr.Cruz 0]

Tivaware also includes a fatfs implementation in third_party/fatfs

[GrumpyOldPizza 15]

For the Fat system, look into Elm Chan FatFs. 

 

Bluebash, sorry if I was not clear enough. I was not looking for FS recommendations. I have a FAT filesystem whereby I was asking for other folks whether they could review/help making it more portable/usable. I am programming bare metal, so my internal interface might not be suited to perhaps integrate this into Energia, or other projects. 

 

Regarding Chan's FatFs. It's deeply rooted in the "as small as possible" philosophy. A friend of mine benched it at 80kb/sec throughput on a 10MHz SPI bus using small block (512 bytes). My requirement was in the order of 200kb/sec. The implementation I came up with got me around 800kb/sec (still on a 10MHz SPI bus). My rover uses a 20MHz SPI bus (thanx to RobG's great boosterpack !!!).  Anyway, just thought other folks might be interested.

 

- Thomas

[GrumpyOldPizza 15]

Haven't posted in a while ...

 

So there was AVC 2015. Less successfull for us (with 2 rovers this year). I was relegated to be the SW guy, while my kids actually build and run the rovers. 

 

Anyway, I thought it might be interesting to post a link to the source code that was used (which of course is utterly outdated, probably ;-)).

 

https://github.com/BizzaBoy/AVC2015-KK

 

There are a couple of interesting pieces that might be of use outside the autonomous rover domain.

 

First off the concept (besides being as cheap as possible) was to take an R/C car, a TI Launchpad, RobG's TFT/SD boosterpack, hook up a GPS, a MPU-9150, a RPM sensor, a 3 channel R/C reveiver, and 2 buttons. The TFT is displaying all status information, which is pretty handy before starting the rover, so one can see whether the GPS is actually working ;-)

 

Here some of the pieces that might be of interest:

 

- the MPU-9150 is samples at 1kHz triggered by the INT output and properly timestamped relative to a wallclock; the builtin AK8975 is sampled at 100Hz; i2c is interrupt driven

 

- the GPS code supports NMEA as well as UBLOX binary; support for GPS+GLNONASS is there; MTK3333, MTK3339, UBLOX6/7/8 are supported; full initializitation at runtime so that this can be used without backup battery or external flash that would store the configuration; ah, and there is proper timestamping via the PPS input

 

- of course there is full speed logging to a microSDHC card ... this time DMA driven to free up more processor cycles

 

- stack checking via the MPU; handy to detect stack overflows (yes, saved my backon ;-))

 

- there is a profiling system in place that buckets cycles spend on various logical tasks (like display, record, navigation ....); very handy to find out how much processor power is still left

 

- lots of interesting code; stared to play with atomics and bitband accesses

 

- the whole system is bare metal, CMSIS based; so if one looks for a CMSIS setup for TM4C123, that might be a good starting point

 

- no RTOS in use; things are either interrupt driven, or timer driver (systick callbacks), or via the PendSV exception as kind of a deferred interrupt; did this, so I could half way explain the system to my son who was running one of the rovers ;-))

 

Here a few pictures, and a link to my son's entry

 

 

 

 

 

- Thomas

 

 

 

[bluehash 1,581]

The LCD ui looks really cool. Good on the CMSIS too.

[GrumpyOldPizza 15]

The LCD ui looks really cool. Good on the CMSIS too.

 

Yes, the LCD UI was tricky for more than one reason, but also the most rewarding. Last year we had a screwup because the display did not convey enough information. So this year I asked the two race engineers what *should* be displayed, why, how ... So we went throu a whole list of scenarios of how you could diagnose hardware malfunctioning, or software issues (like how do I know the RPM sensor is working ?) It came down to the level of "I cannot see yellow in bright sunlight". 

 

Given that the HW setup was as simple as I could get it, there were a lot of ideas my kiddos could contribute (like placement of components, wireing, io port assignment). While that sounds perhaps simple for us adults (and perhaps us engineers), it's something else for a 10 year old and a 12 year old. 

 

- Thomas