I’ve got a TRex coming. I can hardly wait.
There is one little thing that I don’t care for. It’s that it seems like the interface switchover to serial can only be done from the RC interface. This is fine for the senario in the manual:
But I’m concerned with a different senario. This is the common case where the rover is under RC control and loses its signal. At which time you want the MCU to take over for maybe RTH (return to home).
The only solution I can think of is to have the rover under serial control all the time and just read the RC input values and pass them on over the serial interface.
I was thinking it would be nice to have a serial command that says “go to serial motor control now”.
On the other hand, the MCU has to monitor something to know that the RC connection is lost, so maybe serial is normal is the better approach.
Any insight would be much appreciated. If I’m missing something blindingly obvious, don’t be shy of telling me
Thanks a lot,
The solution you mentioned is the one I would recommend. While in serial mode, the TReX still reads its RC/analog inputs and performs all of the internal mixing and scaling it would if it were in RC/Analog Mode. You can make a primarily RC-controlled robot by having your serial controller sit in a loop that first requests the scaled channel 1 and channel 2 values from the TReX and then sends a command to set the motor speeds to those exact values. Your serial controller can also ask the TReX if the channel inputs are valid. If so, it can respond to them; otherwise, it can start acting autonomously.
Thanks Ben. Thinking about this, there’s just got to be a better way to do this. That MCU’s got other things to do, y’know.
What happens if there’s an invalid signal on the RC override channel? It should go to serial right? It doesn’t make any sense for it to go to RC. But maybe it just leaves it in the current mode.
One way I can see, is to drive the RC override channel from the MPU. I know when that channel is switched, RC takes over, but when it switches back, does RC give up control?
Thanks a lot,
The serial override channel is not required to use the TReX, so if no valid signal is detected on that channel, then it is the same as having serial override turned off. The one exception to this is if you configure channel 5 to be a required channel, in which case an invalid signal causes the controller to shut down and go into safe-start mode. In RC mode, RC is always the master interface, and serial is only allowed control while the appropriate signal is present on the serial override channel.
My proposed solution (use it in serial mode with the master MCU reading the RC inputs and then writing them to the TReX) shouldn’t be overly burdensome to your MCU. At most, you only need to be doing this once every 20 ms, since the RC channels probably aren’t updating more frequently than this, and you can likely scale back your update rate even further without much of a down side. (By the way, if you’re clever about it and use interrupts, your MCU can go off and do other things while it is sending the serial packets, so the performance hit can be minimal.) Additionally, having RC in control should free up your MCU some; during the time when you would normally be computing what new motor speed to use, you can instead query it from the TReX and then send that.
That said, your proposed solution should also work, as long as you configure the TReX to have only one required channel: 5. Note that you would need to monitor the health of the RC signals from your receiver (the TReX can help you do this) and decide when to switch to serial control. I haven’t actually used the TReX this way or heard of anyone else using it this way, but I see no reason why it wouldn’t work.
Thanks for that. Something strange happened while I was playing with this.
I hooked up TReX channel 5 to the RC reciever and assigned that channel to a toggle switch on the transmiter. Throttle and steering channels on the transmiter were centred.
When I started flipping the switch the truck just took off and would not stop. I still don’t understand it. Thing is the MCU is always sending serial data to a video overlay board on the same serial line, but that data is plain ASCII; the high bit is never set, so that should always be ignored by the TReX, right? Or am i missing something?
I should add that I haven’t configured anything on the TReX. Everything is default.
You are correct, the TReX should never respond if all the bytes you send are less than 128 (i.e. have their MSBs cleared). What baud rate are you using when communicating with your video overlay board? Did it take off when serial override was active, and did it stop when serial override was deactivated?
Thanks for following up Ben.
I’m using 19.2K baud rate for everything. Sending to the video board and requesting current values from the TRex.
I really don’t know which state caused it to take off, but I’m pretty sure nothing would stop it.
I’m going to do some more testing. Get Thumper up on a stand, and try it with/without serial data out to the video board.
It sounds like maybe there is a noise issue, perhaps interfering with the serial or RC signals, but I need more details about what is happening in which mode in order to say anything more concrete. Do you have access to an oscilloscope?