Uploaded new version. What is locking up? The communication to AOG or the connection to modules?
Got it (sorta) figured out. Itās the serial port that hangs, not AgIO. Unplugging USB makes AgIO run again, happens after trying to write settings to the board. Will try with another board, USB cable etc. later this week, but pretty certain no bug in the software but a HW issue.
https://drive.google.com/drive/folders/18iTEkupiEHjJDOgekbM8gzzzLw7GP8C5?usp=sharing
Boundary Contours
Hopefully this will work
I have a compilation error with the IMU_UDP_20. Maybe I do something wrong
C:\Users\Hp\Downloads\AOG_5\AOG_5\Modules\Arduino\IMU_UDP_20\IMU_UDP_20.ino: In function āvoid loop()ā:
C:\Users\Hp\Downloads\AOG_5\AOG_5\Modules\Arduino\IMU_UDP_20\IMU_UDP_20.ino:240:79: warning: invalid conversion from ābyte* {aka unsigned char*}ā to āconst char*ā [-fpermissive]
ether.sendUdp(data, sizeof(data), portMy, ipDestination, portDestination);
^
In file included from C:\Users\Hp\Downloads\AOG_5\AOG_5\Modules\Arduino\IMU_UDP_20\IMU_UDP_20.ino:23:0:
sketch\EtherCard_AOG.h:445:17: note: initializing argument 1 of āstatic void EtherCard::sendUdp(const char*, uint8_t, uint16_t, const uint8_t*, uint16_t)ā
static void sendUdp (const char data, uint8_t len, uint16_t sport,
^~~~~~~
sketch\udpserver.cpp: In static member function āstatic bool EtherCard::udpServerHasProcessedPacket(uint16_t)ā:
sketch\udpserver.cpp:68:22: warning: invalid conversion from 'uint8_t {aka unsigned char*}ā to āconst char*ā [-fpermissive]
(gPB + UDP_DATA_P),
Love the new graphics, wheels on tractor turning. Looks a lot cleaner and easier to follow. AGIO is unstable for me.
Can we use it on MMA8452 51 V5? I like the great version very much. good for your labor
Where did the uturn settings go. Missing some of the settings in uturn tab. Tractor steers well with v 5.
And now found what the problem is - itās me 
(and the few other Teensy renegades lurking here on the forum, you know who you are 
)
As Iām running the ino on Teensy 4.0 hardware, the resetfunc() call after saving the module settings basically kills the communication on the USB on Teensy. Commented that one out and now it works, could replace that with a soft reset call for the Arm CPU. BNO08x works flawless also on Teensy. PWM frequency control needs a few edits. Now onto the CAN version for valve control and WAS.
PS. Man that AgDiag tool is sweet and the whole interface is so much more intuitive. Great stuff!
3 Likes
Ah, you didnāt own up to the teensy thing! 
I could have told you that!! There is a way to CPU reset the teensy but it dumps it off the usb completely (at least it does in 4.3.10).
3 Likes
I worked with this AOG beta all afternoon, no particular concerns. My config is pcbv2 usb + bno085 i2c.
it still lacks a few settings to change the axis for the roll, and reverse roll ā¦ I have tinkered with the ino. I would have liked to have the choice to activate the roll or not.
But overall itās a good beta. Iāve been driving stanley for months, and the PP only seems pretty good. Congratulations to you !
5 Likes
Processing power of 1MHz / Hp of tractor I think is a good rule of thumb for micro controllers. Hate to be going up a steep hill, and be worried that you might not have enough embedded computing power for all of the extra toys you can dream up.
But really the new version is looking much more polished with the updated graphics, and how comms were split into their own sub program. That in conjunction with all the new boards coming out its very exciting.
1 Like
Adding some comments from telegram here, questions/answers:
Why does my āZeroā change in steer settings when i adjust my Counts Per Degree? It never used to?
Well the center doesnāt actually change because it is in raw counts. What changes when you change the CPD is the degrees shown in the zero. When you increase the ācounts per degreeā you are increasing the denominator of raw counts/cpd to give you actual degrees. Formerly the āzeroā was in counts, whereas now it just makes more sense to read as ādegrees of zero offsetā.
The slider of the zero is + - 4000 counts. that, divided by counts per degree, shows up on the end of the zero slide.
Why is the imu standalone sending every 90 msec? Why 90?
In terms of the 90 msec for the imu, the imu never knows when AOG actually needs the information so if the gps is at 10 hz, there is 100 ms between frames. The imu will continue to update the variables in aog so the timing is off as it is a bit faster. So like 2 red lights flashing at slightly different frequencies, they blink together then move towards on off and back to in sync again. If the imu ran at 100 msec you could be in a situation where it was perfectly in step, or perfectly out of step for quite some time. The 90 helps with that.
You could send every 25 msec, but then what a pile of data to reject 3 out of 4 times. The best solution would be AOG sending a āHey i need imu dataā pgn and the imu sending that back right then.
Why is the I2C set to 50 khz instead of 400Khz using the TWBR 144??
TWBR, setting it to 50khz is a blessing and curse. The slower speed really helps with noise and longer lines - especially for the guys with remote imuās. Running at 400khz isnāt required. BTW, the arduino autosteer loop can run at 125 hz and still has plenty of time. It takes the ADS 8 msec to convert a value, so that is the limit of the loop time. The nano can do the entire steer loop while āwaitingā for the ads to finish its conversion. The arduino is notorious for locking up if the i2c bus locks up. So just trying to prevent that given the very noisy environment with the motor driver and tractor power.
4 Likes
Iām surprised it worked at all!!! Remember every time you make a pass, you have created another contour guidance line. There are so many lines to choose from when there are lines everywhere and it is impossible to know which one AOG should use, it just picks the closest one.
So if your field is done, and you now want to do the outside, just delete the contours - NOT THE APPLIED ONE!!! - and make a new boundary contour and giver again unaffected by all your previous passes which now are deleted.
Contour isnāt very nice on sharp corners as one of the criteria is to only accept paths for guidance that are roughly the same heading as the vehicle. in a sharp corner, it sees the line going 90 degrees to travel direction, so it freaks out and drops the line.
We use contour a lot. Make the first pass around the field seeding with sections on and also making a boundary. The next 3 rounds just follow our last pass, works really well. Corners we lift up and make a big loop anyway with an air seeder tank and then seed tool behind that - its like turning a choo choo train.
Why does the Autosteer dot keep spinning and pink even though i think its working?
If the pinky is spinning, there is nothing coming back to AOG from your steer module. Red, talking but steer switch off. Orange steer switch on but AOG isnāt in guidance, green is everyone is happy. What it does is it reads the steer_switch value the steer module is supposed to send back. if its not changing, AOG will tell you the steer module went to sleep.
1 Like
The other thing i want to mention is settings. Great lengths were gone to to eliminate most of the settings. You can see that in heading/roll source settings and configuring the ino for steer module. You can have no imu, a cmps14 imu, a bno08x imu either on board or off board with an i2c extender and there isnāt a single setting to adjust. How is this done??
When probing the i2c device at the specified address, the Wire.endTransmission returns a value based on what it finds. Any non zero value means it is not connected and saying hello back again. This way we send out the addresses for the CMPS, the BNO080, BNO085 either sparkfun or Adafruit boards and set the flag appropriately either sending back 9999 for no connection telling aog nothing is connected so donāt do anything or sending back the actual values which then turns on all the right stuff in AOG using the imu values. Whether dual antenna, PAOGI, heading roll, if the value is available - it is used. Voila, no settings.
//test if CMPS working
byte error;
Wire.beginTransmission(CMPS14_ADDRESS);
error = Wire.endTransmission();
if (error == 0)
{
Serial.println("Error = 0");
Serial.print("CMPS14 ADDRESs: 0x");
Serial.println(CMPS14_ADDRESS, HEX);
Serial.println("CMPS14 Ok.");
useCMPS = true;
}
else
{
Serial.println("Error = 4");
Serial.println("CMPS not Connected or Found");
useCMPS = false;
}
// Check for BNO08x
if(!useCMPS)
{
for(int i = 0; i < nrBNO08xAdresses; i++)
{
bno08xAddress = bno08xAddresses[i];
Serial.print("\r\nChecking for BNO08X on ");
Serial.println(bno08xAddress, HEX);
Wire.beginTransmission(bno08xAddress);
error = Wire.endTransmission();
if (error == 0)
{
Serial.println("Error = 0");
Serial.print("BNO08X ADDRESs: 0x");
Serial.println(bno08xAddress, HEX);
Serial.println("BNO08X Ok.");
3 Likes
I read that I cannot open a field created in v5 in v4.3.10, but can I open my 4.3.10 fields in v5?
Correct. V5 has a different, and very much faster method to convert to an xy grid that does not use UTM and convergence angle. V5 just ignores those upon opening.
But now that i think about it, if it was made in 4.3 and opened in v5, you should be able to open again in 4.3. Want to try that?
Updated version on github.
Just loaded the newest version. Turn sensor seems not working if set higher than 1 counts.
Ah, now this (i2c frequency) could be why I thought Iād got something slightly wrong when I implemented my own BNO085 code a while ago. Steer did at times seem jumpy. I tried mathās code a week or so ago and it actually made no difference.
So the wire.clockSpeed(400000) instruction is being overridden by the old school TWBR setting and could be omitted entirely.