FlexProp FlexBASIC need help

Rsadeika

Not sure where the problem is. The below sub is on my Activity Board which is connected to the Create 2 robot. When I run this program I keep getting different results on each run.

Normally it should put out a consistent 16, but on one run it will be 65, then 35, and then 16. Not sure if it is something with the sub code, or is the problem somewhere else.

Thanks

Ray
`
sub crVolts()
dim highbyte as uinteger
dim lowbyte as uinteger
dim tempbyte as uinteger

cr2.tx(142)
cr2.tx(22)
highbyte = cr2.rx()
pausems 20
lowbyte = cr2.rx()
pausems 20
tempbyte = ((highbyte << 8) + lowbyte)
tempbyte = (tempbyte / 1000)
print #2, tempbyte

end sub
'

ersmith

I don't think there's enough context here to debug your problem, Ray. The crVolts function on its own seems OK, although I wonder what the purpose of those "pausems 20" statements are. What terminal object are you using for cr2? Most of them (e.g. FullDuplexSerial) have buffers, so you shouldn't need to delay before or after trying to receive a character.

What makes you think the result should always be 16?

Rsadeika

In the previous post I only listed the sub, below is the full program.

I have an Activity Board and a Raspberry Pi combination that is operating the Create 2 robot. Since the robot battery power is an essential component to operate the robot, there is a Create 2 command that provides battery voltage. When the battery is fully charged it is 16 Volts.

A Create 2 command provides the voltage in a 2 unsigned data bytes format. Because the robot is a 5 volt system, and the Activity Board is a 3.3 volt system, I have a voltage divider setup to reduce the voltage to the Activity Board IO pin.

In the program, rpi= Raspberry Pi, and cr2= Create 2 robot. As for the 20 ms delay in the sub, I wanted to make sure that the cr2, which is probably slower processor, will keep up with the P1, or vice-versa.

Since I am getting data that is not what is expected, I am trying to narrow down the problem. So I am starting with the FlexBASIC code. Since I am sending the data to the RPi, I am using a Python program that captures the data and displays it. That will be the next component to investigate.

I did have a setup where I was just grabbing the voltage and having FlexBASIC display it locally, I was getting the same unexpected results. That is why I am checking out the FlexBASIC program first.

Since the battery voltage is a key factor, I do have another solution for getting the real time battery voltage. First I want to find out if there is a problem in the current setup.

Ray

`
'' cr2.bas
''
'' Mar 13, 2021
''
dim rpi as class using "spin/FullDuplexSerial.spin"
rpi.start(2, 3, 0, 115200)
open SendRecvDevice(@rpi.tx,@rpi.rx,@rpi.stop) as #2
dim cr2 as class using "spin/FullDuplexSerial.spin"
cr2.start(0, 1, 0, 115200)
open SendRecvDevice(@cr2.tx,@cr2.rx,@cr2.stop) as #3

print #2, "Create 2 Robot System"
print #2, "Type help for System Menu."

'' Global Variables
dim inBuff as string

dim highbyte as uinteger
dim lowbyte as uinteger

dim speed_right%
dim speed_left%
dim turn_right%
dim turn_left%
speed_right% = 75
speed_left% = 75
turn_right% = 35
turn_left% = 35

'' Stack

'' Main
cr2.tx(128)
pausems 300
cr2.tx(131)

do
'print #2, "> ";
input #2, inBuff
if inBuff = "crsafe" then
cr2.tx(131)
pausems 150
print #2, "crSafe Test Code"

else if inBuff = "crstart" then
    cr2.tx(128)
    pausems 150
    print #2, "crStart Test Code"
else if inBuff = "crreset" then
    cr2.tx(7)
else if inBuff = "quit" then
    exit
else if inBuff = "crstop" then
    crStop()
else if inBuff = "crforward" then
    crForward()
else if inBuff = "crbackward" then
    crBackward()
else if inBuff = "crright" then
    crRight()
else if inBuff = "crleft" then
    crLeft()
else if inBuff = "crvolts" then
    crVolts()
else
    print #2, "Invalid Command!"
end if

loop

print #2,"Program Stopped!"
pausems 20
close #2
close #3
end
''''''''''''''''''''''''''''''

'' Subroutines and Functions

sub crStop()
print #2, "Robot Stop"
cr2.tx(145)
cr2.tx(0)
cr2.tx(0)
cr2.tx(0)
cr2.tx(0)
end sub

sub crForward()
print #2, "Robot Forward"
cr2.tx(145)
cr2.tx((speed_right% >> 8) and 0xFF)
cr2.tx(speed_right% and 0xFF)
cr2.tx((speed_left% >> 8) and 0xFF)
cr2.tx(speed_left% and 0xFF)
end sub

sub crBackward()
print #2, "Robot Backward"
cr2.tx(145)
cr2.tx((-speed_right% >> 8) and 0xFF)
cr2.tx(-speed_right% and 0xFF)
cr2.tx((-speed_left% >> 8) and 0xFF)
cr2.tx(-speed_left% and 0xFF)
end sub

sub crRight()
print #2, "Robot Right"
cr2.tx(145)
cr2.tx((-speed_right% >> 8) and 0xFF)
cr2.tx(-speed_right% and 0xFF)
cr2.tx((speed_left% >> 8) and 0xFF)
cr2.tx(speed_left% and 0xFF)
end sub

sub crLeft()
print #2, "Robot Left"
cr2.tx(145)
cr2.tx((speed_right% >> 8) and 0xFF)
cr2.tx(speed_right% and 0xFF)
cr2.tx((-speed_left% >> 8) and 0xFF)
cr2.tx(-speed_left% and 0xFF)
end sub

sub crVolts()
dim highbyte as uinteger
dim lowbyte as uinteger
dim tempbyte as uinteger

cr2.tx(142)
cr2.tx(22)
highbyte = cr2.rx()
pausems 20
lowbyte = cr2.rx()
pausems 20
tempbyte = ((highbyte << 8) + lowbyte)
tempbyte = (tempbyte / 1000)
print #2, tempbyte

end sub
`

JRoark

That sub crVolts() looks fine to me. I’m a bit suspicious of the hardcoded delays at those line speeds, but I’ve done far worse things myself. Lol.

My bet is you are getting an unplanned response over the serial line. Print HIGHBTYE and LOWBYTE right after you receive them and I bet you find your culprit. Any chance you have a serial analyzer available?

Edited to add: I’m curious why you set up CR2 as a SendRecvDevice but then access it directly via its methods instead of by its handle (#3).

Rsadeika

I will probably get rid of the SendRecvDevice for cr2. At first I was trying to use print #3, for all things, but Eric mentioned that it is less fuss to just do 'cr2.tx((-speed_right% >> 8) and 0xFF)' instead of 'print #3, using...' format.

I do not have a serial analyzer, if it is "...an unplanned response over the serial line...", what would your suggestion be to get around that?

In some cases the Create 2 takes about 20ms when it deals with a command request, not sure if that is applicable in the crVolts request, but I put it in anyway. It seems that that did not do any good, but I may have to increase that to, maybe 40ms, and see if that makes a difference.

The other solution that I was thinking about is a direct ADC attachment to the available Create 2 battery power source, but FlexBasic does not have an ADC command. But ,it so much more convenient to use the existing Create 2 commands.

Ray

JRoark

Adjusting the timing might be informative. As to debugging the serial line, maybe patch-in a serial-to-USB converter and run a terminal program on your dev system to see what is going on. Or use a scope and trigger on the start bit and you can manually decode the packet since it is short.

Any interest in migrating your design to a P2? It seems like all those smart pin modes could really help you out (ie, ADC becomes almost trivial).

Rsadeika

Yes, I am looking into upgrading to the P2 for the robot, but...

• Flexprop does not support WiFi for the P2, yet.
• No accessory board that would handle up to 20V voltage divider.
• The P2 Edge card sticks up, need to keep things as low as possible.
• The WiFi module sticks up, need to keep things as low as possible.
  just a few things to consider.

As for the timing aspect, I have an original Create robot where the start up BAUD is 57600 and it was having the same problem with the crVolts function. It is a real PIA to adjust the BAUD rates on the Create robots, so I am staying away from that.

I do not have a tech background, so hooking up a scope and deciphering the results is way above my capabilities. Not sure if I want to get that deep into the robot project.

Ray

JRoark

Gotcha. Size constraints are pesky things.

FWIW, as long as the P2 and the battery shared a common ground, the voltage divider you need is just a couple of resistors. Maybe throw a 3.3 volt zener across the sense line as cheap insurance against purple smoke. I’m doing exactly this on a solar project where the input gets up to 60 volts and it works without any issues.

Rsadeika

On my other project, a Solar thing, I have to deal with about 20V, so I tried out an "off the shelf" voltage divider break out board, for my P2 mini setup. That knocked the voltage down to about 3.5V, but I decided to add a resistor voltage divider concoction, that I made up. I was not sure if the P2 pins would be able to handle ~3.5 Volts.

With this type of setup I had to provide a breadboard, which takes up more room. If the P2 accepts accessory boards, then I would need something that gets rid of the breadboard usage.

Ray

JRoark

The P2 ADC inputs will handle 3.5 volts, but there isnt a lot of wiggle room left. I try to keep them between the rails and pick the protection to start clamping just above this. You do lose a little bit of range by doing it this way, but I feel safer knowing there is some margin left.

Rsadeika

Since the people that have looked at the crVolts sub, are saying, they see no problem, I am checking out some other things.

I increased the pausems command to 300ms, that seemed to help a little, but after a while it started to falter. Since I have a "level shifter", well sort of, I am wondering if that might be the problem, although all that it does is lower the voltage from 5V to 3,3V. What I concocted was basically a voltage divider, does anybody have any other quick fit designs for what I am trying to do.

Ray

Rsadeika

After double checking my "level shifter" concoction, I do not see any glaring failure points. So, is it the robot itself, not sure as to how I would be able to check that out. iRobot does not have a firmware update setup, that I know of. Maybe it is not a firmware problem but a fault with the robot board itself. Not sure what the next step will be.

Ray