Dawn Robotics Forum

Hi there,

Nice to hear from you.

Interested to see how you get on with your Android development. I've played with a few samples, but never done anything in anger.

Regards

Alan

And here we are, again.
I fitted additional battery external to the 'normal' 4x AAA pack, so now, I supply 7.5V (idle) to the mini-driver.

Still, if we command PF or TF for full speed ahead or backwards, and we hit something, the motor either sparks interference or drags so much current that the Bluetooth module resets (goes from still to flashing again), and the sketch/program loop goes somewhere...

(it has even potential of screwing up the bootloader, lucky i have my miniature USB ISP programmer...)

I tried going to C:\Program Files (x86)\Arduino\hardware\arduino\bootloaders\atmega8\Makefile and modifying fuse values as in http://forum.arduino.cc/index.php?topic=127394.0 , http://forum.arduino.cc/index.php/topic,49044.0.html , http://www.engbedded.com/fusecalc ; i (THOUGHT I) set the fuses to BOR at 4V, which should be enough to catch this...

Except it's not doing it. BT module resets, but the MD board gets stuck away from the setup() and main().
Next up is, I am going to try to enable the watchdog. But that is going to happen when I get a nick of time next time round.
Will also fit some ferrites for more spark protection.
Also as I said somewhere else, any pointers how to get the Dagu Bluetooth Addon to talk to an Android Bluetooth RFCOMM - like application, are welcome (an Android Studio Bluetooth Chat example, doesn't work with it OOB, and I've no idea what do I change to get it to work... and the mobot.es app is no use for me since I have different command stream and can't find sources to it [yet])

Hi there,

At one point I experimented with setting the Brownout detection value 4.0V, but then found that the mini driver was fairly unstable running off 4 rechargeable AA batteries.

I'm not 100% sure that the problem we're seeing with the bootloader corruption on the Mini Driver isn't somehow down to the bootloader, as if you look at its source code (hardware/arduino/bootloaders/atmega8/ATmegaBOOT.c) then it doesn't look as if it would be that hard for random serial communication on bootup to rewrite bits of memory. An alternative is to perhaps try the optiboot bootloader (the same one which runs on the Uno) which looks to be more robust to me. If you've got time to test this at some point then I can send over details of compiling the optiboot bootloader if you need one or provide a compile one. It sounds like you have a fairly vigorous testing environment set up.

I'll keep an eye out for a decent Android open source bluetooth project. I'd like to have a go at Arndroid bluetooth communication myself at some point.

Regards

Alan

At one point I experimented with setting the Brownout detection value 4.0V, but then found that the mini driver was fairly unstable running off 4 rechargeable AA batteries.

I recently added one AAA battery holder (note to self : more photos needed).So I feed the MD 7.5V idle. Now it only browns out when I suddenly stop the rear wheels...
I also added some resistors in series with the front direction-drive engine to lower the stall current.

I think it's sparks / interference I need to fight now...

I'm not 100% sure that the problem we're seeing with the bootloader corruption on the Mini Driver isn't somehow down to the bootloader, as if you look at its source code (hardware/arduino/bootloaders/atmega8/ATmegaBOOT.c) then it doesn't look as if it would be that hard for random serial communication on bootup to rewrite bits of memory.

I thought about enabling the watchdog actually... and making use of it somehow.

If you've got time to test this at some point then I can send over details of compiling the optiboot bootloader if you need one or provide a compile one. It sounds like you have a fairly vigorous testing environment set up.

I made a bit of incision into the chassis/bonnet so I can connect SPI externally, I probably could do totally without bootloader... since the access to the usb port is now entirely off, buried inside the car.

But yeah willing to read about the optiboot.

I'll keep an eye out for a decent Android open source bluetooth project. I'd like to have a go at Arndroid bluetooth communication myself at some point.

The link you provided on the blog seems to lead eventually to the correct value of bluetooth UUID to use for serial port... I missed that. I am yet to try this (probably not today) but I WILL: I will mod the AS Bluetooth Chat Sample code first.
Thanks especially for that link, it all starts to fall into place
[Famous last words]

OK so...

In Android Studio 1.1.0 (i think it updates itself to this version anyway)

I went

File -> Import Sample

then search for Bluetooth Chat
(com.example.android.bluetoothchat)

It prompted me to install some SDK things that I did not have on before.

Then I went to
(in the project tree)
BluetoothChat -> Application -> src -> main -> java -> com.example.android -> bluetoothChat -> BluetoothChatService.java

At the top of that file there are UUIDs declared:

Code: Select all

// Unique UUID for this application
    private static final UUID MY_UUID_SECURE =
            UUID.fromString("fa87c0d0-afac-11de-8a39-0800200c9a66");
    private static final UUID MY_UUID_INSECURE =
            UUID.fromString("8ce255c0-200a-11e0-ac64-0800200c9a66");

I added below :

Code: Select all

    private static final UUID MY_UUID_SERIAL_PORT =
            UUID.fromString("00001101-0000-1000-8000-00805f9b34fb");           //

Then went on to substitute where original code wanted MY_UUID_SECURE or INSECURE, I pasted MY_UUID_SERIAL_PORT instead.

Compile, run, turn car on.

On phone go to Bluetooth menu, pair the phone with device HC-06 (pin 1234).

On the now running Bluetooth Chat app, touch the Bluetooth symbol, then tell it to connect to HC-06.

It connects ! At least says it's connected.

Into the chat window below, type rf, done
wow but... i touch done repeatedly and nothing happens???

WTF?

I go to the chat app again, connect in insecure mode. Same thing.

Type what you want, ON THE on screen keyboard, press DONE, nothing.

Then i hide the keyboard and hey presto there is the SEND button instead of DONE.

I press SEND.

HC-06 replies!

HC-06: r
HC-06: f

The car turns front wheels to the right lock (RF)

WOW.

pf, hide keyboard, send, unhide keyboard, rf, send,... All works

Cool,

I enjoy those moments when things start working. Makes the times when I'm swearing and tearing my hair out much easier to take.

Your idea of programming the Mini Driver with SPI is a great one, as then it would be possible to rule the bootloader out as a possible suspect.

On page 211 of the Atmega8 Datasheet it says

Flash corruption can easily be avoided by following these design recommendations (one is
sufficient):
1. If there is no need for a Boot Loader update in the system, program the Boot Loader Lock
Bits to prevent any Boot Loader software updates
2. Keep the AVR RESET active (low) during periods of insufficient power supply voltage.
This can be done by enabling the internal Brown-out Detector (BOD) if the operating volt-
age matches the detection level. If not, an external low VCC Reset Protection circuit can
be used. If a reset occurs while a write operation is in progress, the write operation will be
completed provided that the power supply voltage is sufficient
3. Keep the AVR core in Power-down sleep mode during periods of low VCC. This will pre-
vent the CPU from attempting to decode and execute instructions, effectively protecting
the SPMCR Register and thus the Flash from unintentional writes

Now, from what I can see of the lock bits set for the Arduino IDE in hardware/arduino/boards.txt, the Boot Loader Lock Bits are set to preven Bootloader software updates, so in theory this one thing should be sufficient to prevent flash corruption, i.e. as I understand it setting up Brown-out Detection shouldn't be needed. The fact that we're still seeing corruption is what makes me think that somehow the bootloader is the culprit.

Regards

Alan

Is it possible at all to program the Arduino-ish board without one and still use Arduino IDE for it...? (will google )

I'm getting more and more convinced I need a) some serous spike filters on motors and b) additional electrolytic cap somewhere in region of at least 4700uF (I do not wish to change /add cap on the board directly... though maybe I should actually)

Reason is, if I give my program a full-throttle forwards (pf) or backwards (tf) command, the bor condition happens not just to the ATMega but also to the Bluetooth module. If I change the current gradually (p8, p9, etc. pf) then the spike is not happening.

Atmel's susceptibility to BOR and spikes isn't exactly news to me (been round mailing lists and designed a board for AT89c2051 (prog'd in asm) and a board for at90c4051 (in c) and ended up using their recommeded way of external por/bor detector... but then I used flash data rom to keep strings in

el_es wrote:Is it possible at all to program the Arduino-ish board without ^^^

^^^ without bootloader, I was to say

Yes, there's an 'upload using programmer' option in the IDE which does that I think, althouh I've never tried using that myself.

Capacitors on the motors are probably a must for stability. I've left them off the Pi robotkit we sell just because the motors are so small, but your motors sound larger.

Even without capacitors though, I would have hoped that a brown out wouldn't corrupt the onboard flash memory.

Oh, upload using programmer, I am doing...

But I upload a 'sketch' from the IDE, which is unlike any uC program I ever wrote

So the fault must also be somewhere in the sketch stub code, the one that actually calls setup() and loop() off my sketch... there must be some (more) code there, right? That links with the compiled output of the .ino.

And there I could not again find any suppressors/ferrites/filters in my junk... deadlines etc. Will be back next week, for now I need to concentrate on getting the bluetooth control app going