(41 intermediate revisions by 4 users not shown)
Line 1: Line 1:
= Project Brainstorming =
+
= Project Brainstorming =
  
 
So, what do you all think about a processor choice? There are several options for [http://www.arm.com/products/processors/index.php ARM Processors]. The [http://www.arm.com/products/processors/cortex-m/index.php Cortex-M series] seems to be at the level at which we need our processor to be at, though I will need to read more on it and the other processors.  
 
So, what do you all think about a processor choice? There are several options for [http://www.arm.com/products/processors/index.php ARM Processors]. The [http://www.arm.com/products/processors/cortex-m/index.php Cortex-M series] seems to be at the level at which we need our processor to be at, though I will need to read more on it and the other processors.  
Line 7: Line 7:
 
<br>  
 
<br>  
  
We will use RTL 8181 SOC chip with&nbsp;two integrated Ethernet MACs and a WLAN 802.11b controller embedded onto a single chip.&nbsp;
+
We will use RTL 8181 SOC chip with&nbsp;two integrated Ethernet MACs and a WLAN 802.11b controller embedded onto a single chip.&nbsp;  
  
 
This is Linux for This chip&nbsp;[http://rtl8181.sourceforge.net/ rtl8181.sourceforge.net/]<br>  
 
This is Linux for This chip&nbsp;[http://rtl8181.sourceforge.net/ rtl8181.sourceforge.net/]<br>  
  
RTL8181 Datasheet&nbsp;[http://www.wireless.org.au/~jhecker/rtl8181/RTL8181_DataSheet_1.01.pdf www.wireless.org.au/~jhecker/rtl8181/RTL8181_DataSheet_1.01.pdf]
+
RTL8181 Datasheet&nbsp;[http://www.wireless.org.au/~jhecker/rtl8181/RTL8181_DataSheet_1.01.pdf www.wireless.org.au/~jhecker/rtl8181/RTL8181_DataSheet_1.01.pdf]  
  
NXP&nbsp;SA2400ABE Transceiver datasheet&nbsp;[http://pdf1.alldatasheet.com/datasheet-pdf/view/119823/PHILIPS/SA2400ABE.html pdf1.alldatasheet.com/datasheet-pdf/view/119823/PHILIPS/SA2400ABE.html]
+
NXP&nbsp;SA2400ABE Transceiver datasheet&nbsp;[http://pdf1.alldatasheet.com/datasheet-pdf/view/119823/PHILIPS/SA2400ABE.html pdf1.alldatasheet.com/datasheet-pdf/view/119823/PHILIPS/SA2400ABE.html]  
  
 
<br>  
 
<br>  
Line 19: Line 19:
 
---Tan Pin Siang (HKUST)  
 
---Tan Pin Siang (HKUST)  
  
 +
<br> I think we are leaning more toward connecting an ARM processor to a separate wifi module. We will be meeting on 9/23 to discuss this further. As we talked about in the teleconference, our teams don't have to have the same processors as long as we agree on the protocols. We will being doing some more research on the RTL8181, however.
  
I think we are leaning more toward connecting an ARM processor to a separate wifi module. We will be meeting on 9/23 to discuss this further. As we talked about in the teleconference, our teams don't have to have the same processors as long as we agree on the protocols. We will being doing some more research on the RTL8181, however.
+
--Jason  
 
+
--Jason
+
  
 
<br>  
 
<br>  
Line 28: Line 27:
 
<br>  
 
<br>  
  
Hi everyone,<br>
+
Hi everyone,<br> This could be one additional option for a processor http://www.ti.com/lsds/ti/microcontroller/arm_stellaris/overview.page?DCMP=Luminary&amp;HQS=Other+OT+stellaris It's a TI microcontroller with an ARM Cortex M3 processor. I think that we may have looked at this during our meeting on Friday. It has embedded ethernet which would be nice. This is a development board for it as well - http://www.ti.com/tool/ek-lm3s6965 <br> <br> Also, we should probably agree on what the car should be able to do: <br> - Are we going to have both of the cars each host different web pages or will there be one central web page? <br> - video camera on board? <br> - other things such as sensors to check for imminent collisions? <br> -anything else that I didn't think of... <br> <br> --Scott <br> <br> Scott, that's what pretty much what I was thinking - the 9000 series has 8 PWM outputs, plenty for our needs <br><br> Many of the other processors in the M series have similar characteristics. What about a wireless module? There are a ton of options for that. That may be less important than the processor choice, as most wireless modules use a UART or something similar to communicate with the processor.
This could be one additional option for a processor http://www.ti.com/lsds/ti/microcontroller/arm_stellaris/overview.page?DCMP=Luminary&HQS=Other+OT+stellaris  
+
 
It's a TI microcontroller with an ARM Cortex M3 processor. I think that we may have looked at this during our meeting on Friday. It has embedded ethernet which would be nice. This is a development board for it as well - http://www.ti.com/tool/ek-lm3s6965  
+
Something similar to http://www.ti.com/product/wl1271-tiwi, which has pre-integration with some ARM processor families may be of interst.
 +
 
 +
The processor family that you suggested has plenty of inputs for sensors, which I think would be a very appropriate add-on for the latency that will be involved.
 +
 
 +
The video camera on board is a very good question. That would take a lot of processing if went through our system. I'm not sure what I think about that at this point.<br> --Jason
 +
 
 +
<br> Tan Pin Siang, Are you all set on your processor choice (RTL8181)? We are concerned about the support and availability, as in it is not available in the US. Our teams don't have to have the same processor, but it would be nice if we encounter problems.<br> --Jason
 +
 
 +
Hey guys, I haven't had a chance to look at the specs of all the different 9000 series processors, but from looking at them briefly i agree with you all that this looks like a good choice. Scott like you said, the embedded ethernet is really nice and i think the USB connection will be very handy too. As far as the questions that you brought up, i think for convenience sake that one central website would be ideal, but i don't think that it's necessary. I think it would be easier on us to just set up our own site. So i think a central website is desired, but not really a must have for us, at least for now. Maybe we can work on that once we get the majority of our goals reached. For the video camera on board, i'm not entirely sure how the processor works, but would we be able to just hook the webcam up to the on board USB? I can understand how if possible, that would take a lot of processing though. Maybe if that would take too much processing, we could just hook the webcam up to a computer and point it at an area that our vehicle can move and broadcast that on the website. That way we could see it moving, but the processor on the vehicle won't have to handle that load. And like you said Jason, since it has plenty of inputs, i don't see why we couldn't hook up some sensors on the vehicle. I'll keep looking into the processors and all that, but this is all i have for now.
 +
 
 +
--Chris
 +
 
 +
<br> Everyone, please see the updated system diagram--&gt; [https://www.projectrhea.org/rhea/images/a/a0/LRVC_System_Diagram.pdf System Diagram] This is obviously a simplification of the interconnections, but it at least presents our general ideas at this point. Please respond with your feedback.
 +
 
 +
--Jason
 +
 
 +
<br> One topic brought up is the possibility of having a wireless camera on-board rather than integrating a camera through the wireless transceiver that will be receiving control information for the vehicle. If this is something that can be integrated into the website (as in we can feed that video to the site) I think this would be a nice alternative.
 +
 
 +
--Jason
 +
 
 +
<br> <br> <br> This camera looks like it could be an option: http://foscam.us/foscam-fi8918w-wireless-ip-camera-11.html . I'm not sure how easy it would be to interface with our website though. <br> <br> -Scott <br> <br>
 +
 
 +
I think we should use the MCBSTM32EXL develoment board. It has some things we don't need but it has the most online support and a ton of example programs. That camera may work if we can configure it to work with the site - also this one looks pretty good http://www.axis.com/products/cam_m1011w/index.htm
 +
 
 +
--Jason
 +
 
 +
<br> Here are possible wireless transceivers:
 +
 
 +
http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-wi-fi#models
 +
 
 +
http://www.sparkfun.com/categories/112
 +
 
 +
We just need to pick one or two to get and start prototyping.
 +
 
 +
http://www.raidentech.com/sptwo2aircta.html <br> ^Vehicle Platform? haha
 +
 
 +
--Jason
 +
 
 +
<br> The RN-XV WiFly Module on sparkfun looks like it might be a good option. It's really cheap and seems very easy to use. Love the vehicle platform haha. Did we pretty much decide that we're going to buy an existing car and take it apart? Also, that camera looks good. It looks as though it might be a bit easier to integrate into the website than the foscam one but I'm not really sure. I'm still working on getting the softaware for the development board on a VIP computer so we can start doing something. <br> <br>
 +
 
 +
--Scott <br>
 +
 
 +
<br> I agree about the WiFly. I don't remember who brought it up in one of our meetings, but i know that the WiFly module was mentioned and it looked pretty good then. And after checking it out on the link it still looks good to me. For the camera, i think the one that Jason linked to looks pretty good. Not to say the other one was bad, but like Scott said, it looks easier to integrate into the website. And i can't be sure just from looking at the pictures of it, but it kind of seems like, based on its shape and size, that that one would be easier to physically integrate onto the car as well. I'll check out some vehicle platforms before the meeting tomorrow, but that tank one is just too good haha, i mean, the gun actually works, i think we'd be wrong to not get it.
 +
 
 +
--Chris
 +
 
 +
<br> I was checking out some RC cars this afternoon. This first site has a ton of different ones we could pick. http://www.hobbytron.com/RCCars.html A lot of the ones on there are pretty cheap so that's good and there's a good amount of them that are fairly big. But you guys can check that out too if you want because there are like 23 pages of cars so i know that i didn't get to them all.
 +
 
 +
Also, I think an RC truck might be a good idea so we can put what we need in the back and i found a good website for those too. http://www.nitrorcx.com/brrctr.html This site had more than just the trucks, but i linked it to the trucks. These are more expensive, $100-200, but they are also pretty big, ~16 inches with a ~11 inch wheelbase. The body is smaller than the wheelbase, but it's still pretty big. Plus they have super sweet paint jobs haha. However, it looks like a lot of these are four wheel drive, i know we were talking about a two wheel drive system, so i don't know we could mess with these to get them to work, or if that totally eliminates them as a possibility.
 +
 
 +
http://www.amainhobbies.com/index.php/cPath/1_44_1171/n/RC-Cars-Trucks-Kits-Electric-2wd-Short-Course-Kits This last site has a few trucks that look good. They are a little bit larger than the ones in the previous link, that makes them more expensive, but they are two wheel drive.
 +
 
 +
A lot of these sites have some pretty intense looking stuff on them though, i don't know what you guys were thinking, but would we need to go all out on something like one of these, or would something, as long as it's big enough, from radioshack or a store like that work just as well?
 +
 
 +
--Chris
 +
 
 +
PLEASE LOOK HERE FOR OUR CURRENT PERIPHERAL CHOICES: [[LRVC Oct18|Vehicle platform, sensors, camera]] <br> --Jason
 +
 
 +
We really face some problems while trying to use the RTL8181 SOC. Therefore, we reconsider the choice of our MCU and Wifi Transceiver Module. We are using a router with Atheros SoC as our web server and wifi module. A web server program will run in this router, it will work like this: press the button on the web page &gt;&gt; server will run a cgi script &gt;&gt; output the serial data &gt;&gt; MCU. We are planning to add a webcam for video streaming on the website.
 +
 
 +
More information about the router and Openwrt OS. [http://wiki.openwrt.org/toh/fon/fonera Fonera Router] It cost about 14USD in China. Our MCU choice is 16-bit Freescale Microcontroller S12XS128. Thanks --Tan Pin Siang
 +
 
 +
Tan Pin,<br> Is the camera going to be mounted on the vehicle or near the vehicle connected to your router?
 +
 
 +
--Jason
 +
 
 +
The camera and the router will be on the vehicle. The router act as a client and receive Wifi signal from a wireless access point(another router). <br> --Tan Pin Siang
 +
 
 +
<br> We have decided on a tank vehicle platform. It has a lot of space to mount boards without being visible. Our plan is to use our PCB to communicate with a wireless transceiver to connect to the site. The camera will be connected to another development board that converts raw data to compressed data to transmit. This means we will have two connections, two IP numbers, one for the control data and one for the video feed. The video feed will be in a web-friendly format to easily stream (mpeg,mjpeg,etc.). What we need to do is come up with a protocol for vehicle control. We have a tank, so forward is two motors going forward, turning is one going forward and one going backward, backward is both going backward. If we do not have a PWM controlling the motors this means that forward is all forward (but it really isn't fast), turning is only turning - meaning when you are going forward and hit right you will stop going forward and start spinning to the right, etc. We can change this if your vehicle choice is a rear wheel drive with servo steering. Either way, we need to come up with a system of control data, whether it be hex values sent to the vehicle or whatever. I would love to hear your opinions on this before the next video conference.
 +
 
 +
--Jason
 +
 
 +
We have 16-bit to sent, I will split it into BYTE1 and BYTE2
 +
 
 +
For BYTE1
 +
 
 +
1st - 4th bit is camera mount angle.
 +
 
 +
left &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mid &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;right
 +
 
 +
0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 127 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;255
 +
 
 +
5th - 8th bit is I/O control
 +
 
 +
For BYTE2
 +
 
 +
1st - 4th bit is vehicle speed.
 +
 
 +
reverse &nbsp; &nbsp; &nbsp;stop &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;straight<br>0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;127 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;255
 +
 
 +
5th bit is turn Left &nbsp; &nbsp; &nbsp; 0=don't turn; 1=turn
 +
 
 +
6th bit is turn Right &nbsp; &nbsp; 0=don't turn; &nbsp;1=turn
 +
 
 +
7th-8th bit is turning speed (difference in speed of left and right wheel)
 +
 
 +
0 turn slowly -4 turn fast
 +
 
 +
 
 +
 
 +
any suggestion?
 +
 
 +
--Tan
 
<br>
 
<br>
 
<br>
 
<br>
Also, we should probably agree on what the car should be able to do:
 
<br>
 
- Are we going to have both of the cars each host different web pages or will there be one central web page?
 
<br> 
 
- video camera on board?
 
 
<br>
 
<br>
- other things such as sensors to check for imminent collisions?
 
 
<br>
 
<br>
-anything else that I didn't think of...
+
 
 +
Hey everyone,
 +
 
 +
We liked your protocol but we would like to revise the first byte so that we may incorporate more detailed commands to peripherals.
 +
 
 +
Here is what we came up with:
 +
<br>
 +
[[Image:Protocol_proposal.jpg]]
 +
 
 +
[[Image:Opcodes.jpg]]
 +
 
 
<br>
 
<br>
 +
We think that this way we can leave more room for future peripheral additions that may require more that just turning them on and turning them off. Any comments or suggestions?
 
<br>
 
<br>
--Scott
 
 
<br>
 
<br>
 +
In terms of peripheral data being sent to the host site, a simple protocol that utilizes the two bytes could be one byte which identifies the sensor and the other byte sending the value of the sensor in an 8 bit resolution. For instance, a proximity sensor could be given the identity 00000001 and the micro could continue sending its value captured by the ADC to the controller to be displayed to the user. <br>
 +
Thanks
 
<br>
 
<br>
Scott, that's what pretty much what I was thinking - the 9000 series has 8 PWM outputs, plenty for our needs http://focus.ti.com/graphics/mcu/stellaris/Stellaris9000_400.jpg
+
 
<br>
+
--Scott and Jason
Many of the other processors in the M series have similar characteristics. What about a wireless module? There are a ton of options for that.
+
  
 
<br>
 
<br>
 
<br>
 
<br>
<br>
+
 
<br> [[LRVC Discussions|Back to LRVC Discussions]]
+
 
 +
[[LRVC Discussions|Back to LRVC Discussions]]

Latest revision as of 17:44, 16 November 2011

Project Brainstorming

So, what do you all think about a processor choice? There are several options for ARM Processors. The Cortex-M series seems to be at the level at which we need our processor to be at, though I will need to read more on it and the other processors.

--Jason


We will use RTL 8181 SOC chip with two integrated Ethernet MACs and a WLAN 802.11b controller embedded onto a single chip. 

This is Linux for This chip rtl8181.sourceforge.net/

RTL8181 Datasheet www.wireless.org.au/~jhecker/rtl8181/RTL8181_DataSheet_1.01.pdf

NXP SA2400ABE Transceiver datasheet pdf1.alldatasheet.com/datasheet-pdf/view/119823/PHILIPS/SA2400ABE.html


---Tan Pin Siang (HKUST)


I think we are leaning more toward connecting an ARM processor to a separate wifi module. We will be meeting on 9/23 to discuss this further. As we talked about in the teleconference, our teams don't have to have the same processors as long as we agree on the protocols. We will being doing some more research on the RTL8181, however.

--Jason



Hi everyone,
This could be one additional option for a processor http://www.ti.com/lsds/ti/microcontroller/arm_stellaris/overview.page?DCMP=Luminary&HQS=Other+OT+stellaris It's a TI microcontroller with an ARM Cortex M3 processor. I think that we may have looked at this during our meeting on Friday. It has embedded ethernet which would be nice. This is a development board for it as well - http://www.ti.com/tool/ek-lm3s6965

Also, we should probably agree on what the car should be able to do:
- Are we going to have both of the cars each host different web pages or will there be one central web page?
- video camera on board?
- other things such as sensors to check for imminent collisions?
-anything else that I didn't think of...

--Scott

Scott, that's what pretty much what I was thinking - the 9000 series has 8 PWM outputs, plenty for our needs

Many of the other processors in the M series have similar characteristics. What about a wireless module? There are a ton of options for that. That may be less important than the processor choice, as most wireless modules use a UART or something similar to communicate with the processor.

Something similar to http://www.ti.com/product/wl1271-tiwi, which has pre-integration with some ARM processor families may be of interst.

The processor family that you suggested has plenty of inputs for sensors, which I think would be a very appropriate add-on for the latency that will be involved.

The video camera on board is a very good question. That would take a lot of processing if went through our system. I'm not sure what I think about that at this point.
--Jason


Tan Pin Siang, Are you all set on your processor choice (RTL8181)? We are concerned about the support and availability, as in it is not available in the US. Our teams don't have to have the same processor, but it would be nice if we encounter problems.
--Jason

Hey guys, I haven't had a chance to look at the specs of all the different 9000 series processors, but from looking at them briefly i agree with you all that this looks like a good choice. Scott like you said, the embedded ethernet is really nice and i think the USB connection will be very handy too. As far as the questions that you brought up, i think for convenience sake that one central website would be ideal, but i don't think that it's necessary. I think it would be easier on us to just set up our own site. So i think a central website is desired, but not really a must have for us, at least for now. Maybe we can work on that once we get the majority of our goals reached. For the video camera on board, i'm not entirely sure how the processor works, but would we be able to just hook the webcam up to the on board USB? I can understand how if possible, that would take a lot of processing though. Maybe if that would take too much processing, we could just hook the webcam up to a computer and point it at an area that our vehicle can move and broadcast that on the website. That way we could see it moving, but the processor on the vehicle won't have to handle that load. And like you said Jason, since it has plenty of inputs, i don't see why we couldn't hook up some sensors on the vehicle. I'll keep looking into the processors and all that, but this is all i have for now.

--Chris


Everyone, please see the updated system diagram--> System Diagram This is obviously a simplification of the interconnections, but it at least presents our general ideas at this point. Please respond with your feedback.

--Jason


One topic brought up is the possibility of having a wireless camera on-board rather than integrating a camera through the wireless transceiver that will be receiving control information for the vehicle. If this is something that can be integrated into the website (as in we can feed that video to the site) I think this would be a nice alternative.

--Jason




This camera looks like it could be an option: http://foscam.us/foscam-fi8918w-wireless-ip-camera-11.html . I'm not sure how easy it would be to interface with our website though.

-Scott

I think we should use the MCBSTM32EXL develoment board. It has some things we don't need but it has the most online support and a ton of example programs. That camera may work if we can configure it to work with the site - also this one looks pretty good http://www.axis.com/products/cam_m1011w/index.htm

--Jason


Here are possible wireless transceivers:

http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-wi-fi#models

http://www.sparkfun.com/categories/112

We just need to pick one or two to get and start prototyping.

http://www.raidentech.com/sptwo2aircta.html
^Vehicle Platform? haha

--Jason


The RN-XV WiFly Module on sparkfun looks like it might be a good option. It's really cheap and seems very easy to use. Love the vehicle platform haha. Did we pretty much decide that we're going to buy an existing car and take it apart? Also, that camera looks good. It looks as though it might be a bit easier to integrate into the website than the foscam one but I'm not really sure. I'm still working on getting the softaware for the development board on a VIP computer so we can start doing something.

--Scott


I agree about the WiFly. I don't remember who brought it up in one of our meetings, but i know that the WiFly module was mentioned and it looked pretty good then. And after checking it out on the link it still looks good to me. For the camera, i think the one that Jason linked to looks pretty good. Not to say the other one was bad, but like Scott said, it looks easier to integrate into the website. And i can't be sure just from looking at the pictures of it, but it kind of seems like, based on its shape and size, that that one would be easier to physically integrate onto the car as well. I'll check out some vehicle platforms before the meeting tomorrow, but that tank one is just too good haha, i mean, the gun actually works, i think we'd be wrong to not get it.

--Chris


I was checking out some RC cars this afternoon. This first site has a ton of different ones we could pick. http://www.hobbytron.com/RCCars.html A lot of the ones on there are pretty cheap so that's good and there's a good amount of them that are fairly big. But you guys can check that out too if you want because there are like 23 pages of cars so i know that i didn't get to them all.

Also, I think an RC truck might be a good idea so we can put what we need in the back and i found a good website for those too. http://www.nitrorcx.com/brrctr.html This site had more than just the trucks, but i linked it to the trucks. These are more expensive, $100-200, but they are also pretty big, ~16 inches with a ~11 inch wheelbase. The body is smaller than the wheelbase, but it's still pretty big. Plus they have super sweet paint jobs haha. However, it looks like a lot of these are four wheel drive, i know we were talking about a two wheel drive system, so i don't know we could mess with these to get them to work, or if that totally eliminates them as a possibility.

http://www.amainhobbies.com/index.php/cPath/1_44_1171/n/RC-Cars-Trucks-Kits-Electric-2wd-Short-Course-Kits This last site has a few trucks that look good. They are a little bit larger than the ones in the previous link, that makes them more expensive, but they are two wheel drive.

A lot of these sites have some pretty intense looking stuff on them though, i don't know what you guys were thinking, but would we need to go all out on something like one of these, or would something, as long as it's big enough, from radioshack or a store like that work just as well?

--Chris

PLEASE LOOK HERE FOR OUR CURRENT PERIPHERAL CHOICES: Vehicle platform, sensors, camera
--Jason

We really face some problems while trying to use the RTL8181 SOC. Therefore, we reconsider the choice of our MCU and Wifi Transceiver Module. We are using a router with Atheros SoC as our web server and wifi module. A web server program will run in this router, it will work like this: press the button on the web page >> server will run a cgi script >> output the serial data >> MCU. We are planning to add a webcam for video streaming on the website.

More information about the router and Openwrt OS. Fonera Router It cost about 14USD in China. Our MCU choice is 16-bit Freescale Microcontroller S12XS128. Thanks --Tan Pin Siang

Tan Pin,
Is the camera going to be mounted on the vehicle or near the vehicle connected to your router?

--Jason

The camera and the router will be on the vehicle. The router act as a client and receive Wifi signal from a wireless access point(another router).
--Tan Pin Siang


We have decided on a tank vehicle platform. It has a lot of space to mount boards without being visible. Our plan is to use our PCB to communicate with a wireless transceiver to connect to the site. The camera will be connected to another development board that converts raw data to compressed data to transmit. This means we will have two connections, two IP numbers, one for the control data and one for the video feed. The video feed will be in a web-friendly format to easily stream (mpeg,mjpeg,etc.). What we need to do is come up with a protocol for vehicle control. We have a tank, so forward is two motors going forward, turning is one going forward and one going backward, backward is both going backward. If we do not have a PWM controlling the motors this means that forward is all forward (but it really isn't fast), turning is only turning - meaning when you are going forward and hit right you will stop going forward and start spinning to the right, etc. We can change this if your vehicle choice is a rear wheel drive with servo steering. Either way, we need to come up with a system of control data, whether it be hex values sent to the vehicle or whatever. I would love to hear your opinions on this before the next video conference.

--Jason

We have 16-bit to sent, I will split it into BYTE1 and BYTE2

For BYTE1

1st - 4th bit is camera mount angle.

left          mid          right

0             127          255

5th - 8th bit is I/O control

For BYTE2

1st - 4th bit is vehicle speed.

reverse      stop          straight
0              127            255

5th bit is turn Left       0=don't turn; 1=turn

6th bit is turn Right     0=don't turn;  1=turn

7th-8th bit is turning speed (difference in speed of left and right wheel)

0 turn slowly -4 turn fast


any suggestion?

--Tan



Hey everyone,

We liked your protocol but we would like to revise the first byte so that we may incorporate more detailed commands to peripherals.

Here is what we came up with:
Protocol proposal.jpg

Opcodes.jpg


We think that this way we can leave more room for future peripheral additions that may require more that just turning them on and turning them off. Any comments or suggestions?

In terms of peripheral data being sent to the host site, a simple protocol that utilizes the two bytes could be one byte which identifies the sensor and the other byte sending the value of the sensor in an 8 bit resolution. For instance, a proximity sensor could be given the identity 00000001 and the micro could continue sending its value captured by the ADC to the controller to be displayed to the user.
Thanks

--Scott and Jason




Back to LRVC Discussions

Alumni Liaison

Correspondence Chess Grandmaster and Purdue Alumni

Prof. Dan Fleetwood