I made an order for some Rovers (7), and I am having some trouble by loading the sample code that comes with the guide. I have assembled the rover according to your guide (I use AA batteries).
When I turn it on, the 6 LEDs turn on, so I guess the board might be working fine.
The weird stuff comes when I connect the USB cable. If I connect the USB (with the robot turned off), the 6 blue LEDs turn on. Then, when I turn on the rover, it start a cycle of “forward 1 sec, wait 1 sec, backward 1 sec, wait 1 sec”, but only with the USB connected.
This behavior happened even before I tried to load any code. When I tried to load a code, there was an error (I am investigating this at arduino forums).
So, please please, before sending me to the arduino forums, could you tell me why this rover might be acting like that, and is there is a way to sort of reset or clean the microcontroller in order to try to load a sample code.
I tried to load the Blink Led program, and I got the following error:
Binary sketch size: 1018 bytes (of a 30720 byte maximum)
avrdude: stk500_getsync(): not in sync: resp=0x30
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
Please advise. I have tried with the 3 USB Ports of my laptop, and the cable is not retractable. I hope I am not the first one with this problem.
UPDATE: I just connected the USB cable. This time it successfully installed the COM port drivers (after some minutes), and now it works. The Blink LED program is working!!!
I will try with other sketches now, and if any doubt, will let you know!
I just bought a rover for a project with my son, web order # 227208. We have never been able to upload programs to it, but can read serial.
OS: Windows 7
With the batteries disconnected, we plugged in the rover.
The PWR light shows red. No others, but TX flashes periodically.
The driver loaded correctly.
Loaded and started the IDE.
Loaded program into IDE (tried this with simple program and others, all the same result)
Uploaded – error that COM3 was in use. Windows 7 thought the rover was a mouse. We disabled that device and cleared the error.
Ran monitor. Displays:
LIGHT: 168
LM35: 26
(repeats)
Tried upload, result:
Binary sketch size: 2180 bytes (of a 30720 byte maximum)
C:\Users\rushmanw\Desktop\arduino-0023\hardware/tools/avr/bin/avrdude -CC:\Users\rushmanw\Desktop\arduino-0023\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\.\COM3 -b57600 -D -Uflash:w:C:\Users\rushmanw\AppData\Local\Temp\build7025736723668915670.tmp\fullforward_txt.cpp.hex:i
System wide configuration file is "C:\Users\rushmanw\Desktop\arduino-0023\hardware/tools/avr/etc/avrdude.conf"
Using Port : \\.\COM3
Using Programmer : stk500v1
Overriding Baud Rate : 57600
We did try a simple setup() and loop() program, same result. Multiple usb cables, too. When batteries in and turned on, the rover goes back and forth.
We tried forcing the baud rate to 9600 and invoking from the command line, but no improvement.
We downloaded the latest FTDI (thanks for link), but Windows says the installed drivers are up-to-date. Not sure where the baudrate is set (Windows CP shows COM3 usb/serial as 9600), but we tried setting via the command line and it still failed. How do we determine the version? We see H20988A0 on the board, is that it? This was newly purchased, so it should be current.
Note that the rover is currently transmitting light and temp data, so the serial/usb driver would appear to be correct. Do we need to stop it before we can upload? We tried using the reset button, and also took the batteries out.
No we have never got it to work, although the rover can send data to Windows. There is nothing else on the COM port or we would get an error indicating the COM port is in use. We have reinstalled, used different cables, but the board still indicates an error. Please help. Is there a way to tell the board to stop sending the temp and light values? By the way, the light values are the same no matter what, even if we shine a flashlight on it.
Hi,
I have selected the right board and com Port but I am still getting the error. I have doubled check with device manager, my com port is 7 and my board selected is Arduino Duemilanove ATMega328. I uploaded sketches before, but now I keep getting that error
Welcome to the RobotShop Forum. We have heard that happen before. Can you remove the AA batteries from the holder and only connect the USB cable? Once this is done, try uploading a very simple program (blink LED for example which can be found under examples in the arduino software). If you do not get any errors and see the LED flashing, then the firmware is correct. If you see an error in red at the bottom, please copy / paste it here. It may be that you did not select the right COM port or board (it is not an Arduino Uno - it is a Duemilanove chip). If the isse is with the proper operation of the rover using the sample code, RobotShop is here to help. We only send customers to other resources when they wish to modify the platform or incorporate third party products. One issue which seems to have an impact (although we have yet to discover why) is the USB cable itself. Try using a fairly thick cable (not rectractable) and if possible, try a few.
Welcome to the RobotShop Forum. We have seen this error before. Did you try updating the FTDI drivers? A baud rate of 57600 is not used often; usually you need 9600 or 115200. Which version of the DFRobotShop Rover do you have?
To summarize, you were able to download code once, and it is working properly until now, then the computer “decided” to indicate the COM port was permanently used. This can sometimes happen if you pull the USB cable out before seeing the program was fully uploaded to the board. Try another Windows computer and ensure you wait a few seconds after the program has uploaded before removing the USB cable. See in your sys. config if there is anything connected to the COM port, and you can also uninstall / re-install the Arduino software. Tell us your results. It does not sound like a board issue.
Understood. In order to get it to stop transmitting data you would need to connect to it somehow, which is exactly what you have been trying to do. Please contact us via the exchanges/returns department (Support Center) and we will look into exchanging the board. We apologize for any inconvenience.
Welcome to the RobotShop Forum. That’s a COM port issue - you need to plug the board into the computer, run the Arduino software, select the right board and also the right COM port. If you don’t select a COM port, you get that error.
Disconnect everything from the board (motors, frame, battery pack etc.) and plug the bare board into the computer. We assume the PWR LED is lit? Does your computer recognize the FTDI chip? If yes, you can likely choose the COM port and the Duemilanove w/328 board. Ideally you would have no other devices connected. Try a very simple program:
void setup(){}
void loop(){}
Does this work? If not, try connecting it to another USB port on the same computer. If that does not work, try a different computer (ideally Windows based) and different USB cable. If all this does not work, we’ll issue an RMA to have the board exchanged.
It seems it was simply a drivers problem. Make sure your FTDI drivers are properly installed and that Windows likes them and creates a COM port when you connect the rover.
There is also an interesting behaviour that happens when you use Arduino to continually transmit serial data.
If the microcontroller transmits data continually the serial port can get “jammed” when you try to reprogram it (I know this is not a technical term but it is the best way I can describe it) . What can be done in those cases and works pretty well is the following:
]Connect the Arduino microcontroller to the USB port/:m] ]Hold down the reset button on the microcontroller/:m] ]Click on the"upload" button on the Arduino software/:m] ]When you see a message like this “Binary sketch size: 152541…”, release the reset button/:m] ]The Arduino should be programmed properly after a few seconds./:m]
This works very well also with Arduinos that don’t have an auto-reset feature but it can be tricky to get the timing of step # 4 right and you might have to try many times until you get it (it depends on many things including the speed of your computer). What this does is only activate Arduino at the last possible second so it does not have time to load its program before it gets programmed (but is activated early enough so not to miss the first data packets).
