I just bought the Trex Jr and I am using it with what used to be a rc car.
the car has two motors which I am triyng to control with the trex jr.
I am using ATmega168 to communicate with the trex jr. the system is powered by a 5 x 1.5v energyzer batteries.
I connected the battteries straight to the trex jr and the 168 is powered with 5v using a voltage regulator.
so I connected the tx from the 168 to SI at the controller and ground ofcourse, removed all jumpers to get to serial mode. I am sending commands 0xC1 , 0x64 (with 19200 baudrate as the default should be).
now, the red led blinks 5 times at startup the keeps to stay on. ( I put the progrem to the 168) sometimes the green led is turning on and sometimes not. sometimes the motor start turning for a while the stops and sometimes it does nothing.
I think I have communication problem ( I checked with the terminal that I am sending the commands at the right baud and in the terminal they are recieved as expected, so I guess it is something in the trex side) ,
please help
thank you
Nir
There are a few things you can do to try to troubleshoot your system:
Try sending motor commands with no motors connected and see if you get the appropriate responses out of the motor indicator LEDs. Send commands that ask the TReX for information (e.g. get device signature, get mode, get parameter, etc) and see if it reliably responds to these.
Try using the TReX configurator utility, which can be found here, to talk to and control your TReX. Do things work as expected with the utility?
What is the stall current of your motors at the voltage you are using?
hello Ben,
the stall current is 3.6A for each motor.
when I am sending the command the green led that indicates data transfer is on but no led is on from the motor indicator leds. the same is true when no motor is connected.
I guess the command doesn’t go to the motors…
This could be an indication of a problem transmitting your commands. What happens if you try other commands, such as ones that request data? Do you get the expected responses from the TReX? Do you have the ability to try the configurator utility?
Hello Ben
I connected the trex jr to the computer and I am using the configurator.
It says serial mode with rc channel inputs - is that the mode I should be using even when not using rc signals ?
I am giving commands with UART.
next, when I am setting the speed in the motor control page the current at full speed is 15 - I am not sure which units it is… but the motors cannot roll together at the same time, only 1 can roll each time.
anyway, the commands from ATmega168 still dont effect the motors…
You don’t have to make any connections at all to the channel inputs if you are running in serial mode, so for your purposes it does not matter if you are in serial mode with RC channel inputs or serial mode with analog channel inputs (those are your only two options).
The units are 40 mA (you can find this information in the user’s guide), so your motor is drawing approximately 600 mA at full speed (with light/no load, I’m assuming).
I don’t quite understand what you’re saying here. Does something bad happen if you try to use both motors at once? If so, can you describe exactly what happens?
The reason I had you try the TReX configurator program was to see if the problem was with the TReX or with your ATmega168 code. If serial commands from the configurator cause the TReX to drive the motors, the problem must be with your ATmega168 code. I suggest you try writing the simplest program you can that should send a “set motor” command. If this still doesn’t work, please post your code here and I’ll see if I can spot anything wrong with it (I can also test it on an ATmega168 connected to a TReX here).
What I mean is that when using the configurator to drive the motors only one motor can spin at a time,
if I command motor 1 to spin at some speed it is spinning, then when I command motor 2 (while motor 1 is spinning) , it does nothing.
also to make each of the motors spin at full speed (127) I have to bring up the speed at levels from 0 to 127, when I say levels I mean not at one time.
both these problems make me think that maybe some of the batteries are not fully loaded or not giving enough current, what do you say ?
as for the program for the ATmega 168, I wrote the most simple program, here it is (I changed the baudrate to 9600 with the configurator):
#define F_CPU 8000000 #include <avr/io.h> #include <stdio.h> #include <util/delay.h>
void Pin_Init()
{
DDRD |= (1<<DDD1); // PORT D1 is out (tx)
}
void Uart_Init(void)
{
unsigned char baud = 51; // BaudRate = 9600 (51)
UBRR0H = (unsigned char) (baud>>8);
UBRR0L = (unsigned char) baud;
UCSR0B = (1<<RXEN0)|(1<<TXEN0); // Enable Recieve and Transmit
UCSR0C = (1<<UCSZ00)|(1<<UCSZ01); // 8 Bit Data, 1 Stop Bit
}
void Uart_Transmit(unsigned char data)
{
while (!(UCSR0A & (1<<UDRE0))){}
UDR0 = data;
}
int main(void)
{
_delay_ms(1000); // wait for trex to finish start-up
Pin_Init();
Uart_Init();
_delay_ms(20);
Uart_Transmit(0xC9);
Uart_Transmit(120);
while (1)
{
}
}
[quote=“Nir”]also to make each of the motors spin at full speed (127) I have to bring up the speed at levels from 0 to 127, when I say levels I mean not at one time.
both these problems make me think that maybe some of the batteries are not fully loaded or not giving enough current, what do you say ?[/quote]
You didn’t mention this in your last post. Your problem could certainly be a power issue rather than a code issue if things only work when you gradually ramp up the speed. Does your code work if you put in a loop to ramp up the speed from zero over time?
I switched the batteries to new ones (5xAA Duracell batteries) and now both motors work with the configurator !!! that’s a good start.
as for the code from the the 168, when I give the commands 0xC9, 120 out side of the while (1) loop nothing happens, if I put them inside the loop the motor spin but not steady. the speed changes between what seems to be to speeds. am I doing something wrong ? (you can see my code in the previous post).
Your code generally looks good to me, though your _delay_ms(1000) call isn’t doing what you think it is. If you look at the comments in util/delay.h, you will see:
Which means that you can’t use it to delay for more than 32.8 ms if your AVR is running at 8 MHz. You should write your own long-delay function that repeatedly calls _delay_ms() with smaller arguments. Also, make sure you have compiler optimizations enabled, or else the delay routine won’t function properly. By the way, what is the clock source for your AVR?
There are a number of possible sources for your problems:
Your AVR connections to the TReX are bad
Your AVR code is faulty
Your power setup is inadequate for your motors
Your motors are electrically noisy
Your TReX is defective
When you connect everything, you have no way of identifying which of the above possibilities is at fault. Instead, you need to devise tests that can selectively test each option in turn (think of it as conducting a scientific experiment that holds all variables but one fixed so you can isolate the effect of that single variable).
As I suggested earlier, I’d like to know what happens if you conduct your tests with no motors connected. In that case, if you just send the set-motor command outside of the while loop, does the appropriate motor indicator LED turn on and stay on? What kind of motors are you using? Have you taken any steps to decrease motor noise?
as an answer to your question I disconnected the motors and with the command outside if the loop the motor led stays off…
one more thing, when I use accelaration instead of set command (after setting the accelaration parameter to 10) the motors are steady and both motors spin. I guess the current needed to go to the motor using set command is too high. which I guess can mean battery or wire problem.
you say that one command is enough to take the motor to the requested speed ? the command doesn’t have to be sended all the time…? that’s wired…
I am not sure what motors they are exactly because they are installed on what used to be a tyco “rebound” rc car. all I know is that the original battery was 6v. and from the tests I made they draw 600mA continueous and 3.6A when stalled. I did not added capacitors for noise impruvement yet…
You should only have to send a motor command whenever you want to change the motor speed. Once you send a motor command, the TReX will continue driving the motor at that speed until you command it differently or until a problem occurs:
Noisy motors could cause the TReX to reset if they cause too much of a disturbance on the logic voltage. You will have to issue another motor command if the TReX resets.
The TReX is configured by default to shut down motors in the event of an error. Parameter 0x08 (UART-error shutdown) determines whether the TReX shuts off the motors in response to a serial error. I suggest you connect your AVR’s RX line to the TReX’s serial out line and check to see if any serial errors are occurring. You can do this by sending command 0x85 (get UART error byte). The bits of this byte reflect any serial errors that have happened since you last issued this command. Please see the TReX Jr command documentation PDF for more information. Did you by any chance enable the TReX Jr’s serial timeout feature? If so, this could explain why it only works if you continuously issue motor speed commands.
Hi,
I did not enable the serial timeout feature.
I think reason 1) from you last post is not the problem because when I disconnect the motors there is still no indicator led turning on.
I will try to rewire the serial line between them, though I doubt this is the problem…
But I think it is a communication problem now…
Is it possible that the 5 Duracell batteries are not giving enough current ?
I see that even with the configurator, if I set the motors from 0 straight to 127 the motors don’t spin unless I use the acceleration feature.
If you jump straight to 127, what exactly does the TReX do? Does it reset (i.e. do you see the red LED flash five times as it does when you first apply power)?
In general, I wouldn’t recommend using AA alkalines for applications that require much more than an amp or two. I suggest you use AA NiMH cells, which have the benefit of being rechargeable, or higher capacity alkalines, such as C or D cells. You could also try using six or seven AA alkalines in series, which would give you a greater margin for the voltage to drop if you try to draw more current than the batteries can put out.
If you’re locked into your present power system, you could take precautions to limit your motor’s current draw, such as by using acceleration and the TReX’s built-in current-limiting feature.
the red led doesn’t blink.
I used an acceleration parameter 7 and the current doesnt go over 25 which is 1A and also the motor respond well to rapid changes in direction, but that’s all with the configurator from the computer.
I still don’t understand why there is not a response for one command outside of the main program loop.
what can it be ?
I tried playing a little with the (168) clock startup/reset parameter and brown-out detection.
I don’t know if it has anything to do with my problem. I didn’t come to any conclusion from it but I know noticed that sometimes when I turn on the system after turning it off after programing, the trex respond to the one command before the main loop and sometimes it doesn’t (with everything staying the same).I see at the green led that a messege was recieved at both times.
I thing it must be power problems , you have any other thought maybe ?
How are you powering everything in your system, including your mega168? What is the clock source for your mega168? Do you have brown-out reset enabled, and if so, at what level?
Have you tried reading the TReX UART error byte? If not, please run some tests that haven’t been working for you as expected and see if the TReX is reporting any errors.
Program your mega168 to do something distinctive when it first comes out of reset, such as blink an LED. Use this as an indicator to see if your mega168 is being reset when you try to drive the motors. One possible explanation for the behavior you’re seeing is that when the mega168 commands the TReX to drive the motors too hard, the power line is negatively affected in some way (electrical noise or a voltage drop from trying to pull too much current), which resets the mega168, which puts junk on the serial line, which produces a serial error that causes the TReX to shut down the motors. Is your motor power bus sufficiently decoupled from your mega168 logic bus? Is your power bus being overtaxed by the motors?
Can you try using an alternate power source, such as 6 AA alkalines or NiMH cells in series?
Can you try taking steps to limit motor noise?
I think it is quite likely that your problems are caused by insufficient power. Do you have access to an oscilloscope? The most helpful thing would be to actually look at your power lines while all of this is going on.
Ok, I’ll try runnung all these tests, especially adding one more battery and also checking the voltage with an osciloscope (I have one at home fortunately), and I’ll get back with answers…
