Another update on Lobsang! I've been doing lots of work on the code so a lot of the progress is not visible. However, the Lobsang.py library and the RasPiO Duino's core.ino have bee heavily modified. New functionalities have been written and the whole boot-up process is a lot smoother.
Let me expand on the boot process as to hackers and roboteers (ie. not normal people!) it is quite interesting.
1: Power switch set to 'ON'. Pi, Duino, and everything else on Lobsang is powered on.
2: Duino begins running core.ino immediately. Duino does nothing because (a) it has not been told to do anything and (b) the Duino pin 2 has not been set LOW by the Pi so the Duino is software-disabled. My code tells the Duino to do nothing and not flash the pin 13 LED until pin 2 goes LOW.
3: Pi boots Raspbian and /etc/rc.local runs a python script ~/lobsang/autorun.py
4: autorun.py runs ~/lobsang/boot.py which checks if the Duino, RasPiCam and OLED screen are all connected.
5: boot.py checks if the Duino, RasPiCam and OLED screen are all connected. For the Duino it write "OK?" to the serial port. If "DUINO-OK" is received then the Duino is functioning fine. Otherwise boot.py uses avrdude to collect more data then prints either Duino is not connected or Duino is present but core.ino is not uploaded. boot.py uses output from raspistill to check if the camera is connected, and a try: except statement to see if the OLED is connected (IOError == no OLED).
6: If boot.py exited with 0 then autorun.py prints that the system is stable. Otherwise it will print any errors / unconnected systems. If the Duino is connected and functioning then ~/lobsang/core.py is run. core.py has almost no code in it, but later this will be the master program that decides which PiWars challenge code to run.
7: autorun.py has run core.py in the background, so it is free to immediately give a login prompt. However as my Pi skips standard Raspbian login (it makes more sense as it is a robot brain instead of a typical computer) I have created a program called Padlock.py which stops autorun.py from exiting (and therefore giving the user a standard bash prompt) by checking the USB port for a certain flash drive (like a digital key) or if the drive is not found then demanding a passkey.
8: If autorun.py exits, then you can use the Pi like normal. core.py will keep running in the background, unless it has already finished (right now it does almost nothing so it exits immediately, but in the future it will contain a loop to get input and run programs so it will run indefinitely).
I've also made quite a few successful trials with the manual control. I'm experimenting with keyboard control and I think it will be perfectly adequate. I'm using W, A, S, D for robot movement and I'll be adding head movement soon too (not exactly necessary but it makes Lobsang look more alive!). Othercompetitors have been using fancy bluetooth PS3 or XBox controllers, or even full RC controllers, and although those sort of options would be nice I don't really want to spend £20 - £40 on a controller just for this one competition (I wouldn't have any other use for it!). I notice with approval that AverageMan is following the same control method as I am... great minds think alike!
I have two manual control scripts- one for general use moving around, and one for the straight line speed test (why didn't they call it a drag race??). I use pygame to collect keyboard events. The drag race control only allows a very small amount of left / right adjustment, and forwards at full throttle (pwm +16) whereas the general purpose code is below maximum speed as Lobsang gets harder to control. I'm still thinking about tweaks that I could implement though- perhaps a key for changing the maximum speed?
The magic smoke fairy has been visiting again- after around a month of very normal use, my amplifier board started smoking and - wait for it - two wires BOTH CONNECTED TO GROUND appeared to start melting their plastic when their plastic touched! I must be wrong or else the laws of the universe have just undergone a massive change... Not sure what's going on there. With the amplifier disconnected the other systems are still fine.
I have also changed the control options the Pi has. It can tell the Duino to ramp the motors to the specified value, offloading the ramp processing to the Duino, or set the motor speeds straight away. Ramping gives a smoother acceleration and there is no chance of a board-resetting voltage drop when the motors are switched on. If the Pi knows what the previous value was though, it can control the motors instantly for higher movement accuracy with little voltage drop risk. This is particularly useful for line following where the robot is trying to stay centred on a thin line- my previous code using motor ramping followed the line reasonably accurately but with little precision. Hopefully removing the ramp delay will increase performance and therefore speed.
And lastly, I had a problem with SPI communication with the Duino that you can read here which is now resolved. The Duino was not responding properly, which looked very complex but turned out to be a case of two wires connected to MOSI and MISO acting like antennas, broadcasting my binary! "On FM, on digital and LMR, this is Lobsang! 0010 1001 0111 1010 1001 1001 0101 1011 1001 1011 0111..." *eye roll* Looks like I unintentionally created a pirate radio station!