I apologize for the long 3 week delay since the last update. We've been knee-deep in work  to work out the last few bugs in our hardware and software to get both tilt units working the way we expect them to. There was also a week of spring break where no work got done so I apologize for the delay. Now for some updates!

Prior to spring break last week, we missed our milestone to get a first test of waypoint navigation in place. So, we pushed that deadline to next week. Unfortunately, based on the way things are progressing right now, that is likely to get delayed for another week in order to allow us to develop a full navigation stack for the Gator. We'll see how that goes. 

In the meantime, a major victory for the team: we now have both working tilt units! Here's a video of both tilt units moving in unison to prove it (audio has been removed because the building was noisy):

That's it! I hope to be back with more good news regarding waypoint navigation soon!

This past week, on the hardware side, the team finally received the shipment of parts we needed to perform the emergency stop system upgrade to bring more actuators on the vehicle under emergency stop control. We also added a relay that was controllable by the software in order to allow LabVIEW to trip the emergency stop when necessary and also to ensure that any glitches or freezes in the software would trip the emergency stop even if the human operator failed to notice the software glitch. 

To do this, we essentially upgraded several essential parts:

1. We converted the only double-pole double-throw (DPDT) relay on the vehicle into a 3PDT relay to give us an additional channel controlled by the relay
2. We added an additional 3PDT relay to give us an additional 3 channels controlled by the relay
3. We added a DPDT relay with a 5V coil voltage to allow LabVIEW to control the relay. 

However, we made the mistake of failing to account for the fact that the NI9401 DIO module that we're using can't source enough current to run the relay. So, instead, we're attempting to use a transistor to allow us to source 1mA to drive a transistor in order to generate the 0.25A we need to drive the 5V DPDT relay. So, most of the system is now in place except for the LabVIEW control of the relay because we have yet to finish installing the transistor into the relay system. 

On the ROS front, we've made steady progress bringing in sensor data from LabVIEW to ROS and should soon begin installing ROS navigation stack packages. We originally set an initial test deadline for this coming week. However, with spring break occurring the week after this comign one and the fact that we have had a couple of delays in the project, we may push that test deadline back to the week after spring break or so.

​That's it for now!

Sorry for the late update. But last week we had our 2nd teleop test and it was definitely a success! The networking bugs have been ironed out and the system now seems to run reliably. Because of our tight timeline, we were unable to stress test the system to be absolutely sure that it was bug-free but I think as a team, we've tested the system enough to move on to the ultimate goal of waypoint navigation. So, milestone achieved! Time to move on. 

For the record, here's a video of the test. I apologize for the poor labeling but when the video shows you the video of the linux environment, there are 4 windows: top left, top right, bottom left and bottom right:

• Top Left: Steering wheel angle
• Bottom Left: Vehicle Speed
• Top RIght: Drive Command Issued To Vehicle
• Bottom Right: Keyboard Teleop Settings

Hope you enjoy the video!

So turns out the achievement's getting less and less glorious every time we test it. 

It seems the gloriously working teleop system has a few painful bugs to work out. Most notably, the network reliability is very much on a downhill trend. More and more frequently, our drive controls are resetting themselves which is upsetting and suggests that there might be other potential problems with the UDP transmission we're relying on. That'll be a major thing to fix. 

Also, after turning up our steering motor voltage and tuning our PID constants as best as possible, we're still getting a little oscillation in the steering wheel. So we might try turning up the I gain and/or turning down the motor voltage just a bit. I say that because, while testing with the vehicle on jacks, we had to max out our D gain just to keep the steering system stable. So, it seems like a safer course of action is to turn the motor voltage down a little to keep it stable. Similarly, the jerky gas pedal control is getting more and more annoying and we realized it was because the control loop for the gas pedal runs once per second, which seems way too slow. So, we'll try to turn up the speed of that loop and see if we get smoother gas pedal function.

Lots of problems so lots to do. We've set a second teleop deadline 2 weeks from now to have a second, more reliable version of teleop running. We'll see what happens by then....

Yesterday was a major milestone achievement for us! We have working ROS-LabVIEW teleop on the vehicle! We managed to do 2 rounds of Lot D at Olin and then teleop-ed the vehicle back to the large project building, all without needing to do much manual driving, which was fantastic.

We essentially used a stock keyboard teleop ROS package in ROS and then added while loops in labview to take those commands and use them in a way that made sense for the vehicle. As a result, using the standard keyboard teleop package, forward and backward controls increase or decrease the speed and left and right turns increase or decrease the turning radius as appropriate. 

Several things we learned from that test:

1. Keyboard teleop using our current control scheme works pretty well. Setting desired speeds and headings and using the keyboard to increment or decrement them is pretty intuitive to use.
2. The steering wheel isn't turning fast enough to make the teleop process effortless. The motor voltage is also being limited in software far below it's maximum rating so we have some room to turn up the motor voltage to get it to turn faster. However, we will have to also adjust the PID constants accordingly.
3. The gas pedal PID control was inconvenient before but it is awful in teleop because the pedal motion is so jerky. So, our first pass will be to try to turn up the integral gain to eliminate the jerkiness and see what that gets us.
4. There's a strange networking bug between LabVIEW and ROS that's causing LabVIEW to reset its drive commands to zero. Not sure why that's happening.

So, there's some work for us to do but at least we've got something mostly working! Here's a video to prove it:

Sadly, the steering controller problem was also the result of careless mistakes. Like the velocity calculation, the steering controller problem was the result of dividing by zero. When we were editing the subVIs that converted steering wheel angle to number of ticks of the encoder to make the type definitions all consistent, we had been careless and had not reset the constant that converted degrees to ticks to the correct default value. As such, the default value was left as zero instead of the correct value. Conseuquently, when we used that subVI to calculate desired steering wheel position in ticks (divide desired position in degrees by the constant), the resulting desired steering wheel position in ticks was always extremely large. As such, the steering wheel was always trying to turn to reach that very large number. 

The fix ended up being resetting that constant to the correct value and the steering controller seemed to behave normally again.

Turns out we were just careless. I found the reason for the strange velocity reading almost right away. 

But first a digression. I discovered today that LabVIEW offers functionality to run your FPGA code in simulation! I never realized it but if you right-click on the FPGA target, you can select whether to execute the FPGA VI on the FPGA target or to execute it in simulation. If you select to run the VI in simulation, it's SUPER convenient for debugging! You can probe your data lines anywhere you want and see the value of the data passing through those wires (something you can't do if you're just running your FPGA code on the target) and that really helps with debugging.

Alright. Back to the reason for the strange velocity reading. Pretty quickly, using the debugging technique discussed above, I discovered that we had made a stupid mistake in our type definitions during the velocity calculations. To calculate velocity, we first calculate the elapsed time since the last velocity calculation. We then divide distance traveled since last velocity calculation by this elapsed time to obtain the current velocity. 

While looking through the code, I realized we had stupidly defined the output of the division operation calculating elapsed time in seconds as a signed 32-bit word length, 32-bit integer length fixed point number.  Unfortunately, in calculating the elapsed time, the division operation was dividing 1000 microseconds by 1000000 to calculate the elapsed time as 0.001 seconds. Since the output of the division operation was essentially defined as an integer number, the division operation was returning 0 as its output. As such, when the distance traveled is divided by this zero (elapsed time), the resulting output was a large number. When we later change the type definition for that number to a signed 24 bit word length, 5 bit intgeger length number, the output was then 128. Silly us. Fixing that code immediately fixed the speed output problem.

​Now to fix the steering controller problem... 

So it's been a whle since I published an update on how our ROS integration has been going. Last semester, we tried to get LabVIEW communicating with ROS via the ROS package supplied by National Instruments for LabVIEW. For some reason, we were getting very unreliable communication between LabVIEW and ROS. This semester, we have decided to replace the ROS package supplied by National Instruments with simple UDP. So, all our ROS messages are being transmitted in a string via UDP from LabVIEW to ROS and then being decoded in ROS back to a standard ROS message. So far it seems to be working well so we're going to go ahead and begin implementing teleop and click-to-waypoint functionality and see how it turns out.

On the FPGA side, unfortunately but unsurprisingly, we clearly made some mistakes. For some reason, the steering wheel always turns right, with or without a command and our computed vehicle velocity is always 128MPH. So clearly, we've made some data type definition mistakes somewhere. Time to find them! 

Disappointingly, after modifying the throttle and LiDAR code, we were not able to save nearly as much of the FPGA resources. Collectively, with all the changes we made to the LiDAR and throttle code, we were able to save about 10% of slice LUTs. Based on these numbers, we thought we had saved enough resources to add a second copy of the tilt unit motor control code to control the second tilt unit motor. 

As it turned out, we were right! After adding the required tilt unit motor control code and recompiling the FPGA, the FPGA compiled perfectly! 

Now all we have to do is check it to see if our data type definitions changed the functionality of the code in any way....

So we started with the steer motor code. It looked like this when we started:

I realize those pictures are a little hard to read so I apologize for that. But if you look a little closely, there are places in the code where Int32 numbers are being multiplied by fixed-point numbers and many places where data types are being automatically coerced by labview to be compatible. We found this code to be poorly written and so began to try to rewrite this code to make it cleaner and less messy. The result is as follows:

As you might be able to see, what we have done is to clear up all the Int data types to ensure that all of the code uses fixed-point data types which is more FPGA-friendly. 

As a result of these changes, we were able to save 4% of FPGA slice registers and 5% of slice LUTs. The newly modified VI now consumes just 8% of slice registers (down from 11.0%) and 10.1% of slice LUTs (down from 15.1%).